Switch to Lua transforms and change database schema #2533

Merged
merged 101 commits into from May 10, 2017

Conversation

Projects
None yet
@pnorman
Collaborator

pnorman commented Jan 3, 2017

Not yet ready for merge

What this does

This PR accomplishes four main tasks

Lua transforms

It switches to Lua transforms, which allows pre-processing of tags like layer. This allows SQL like

ORDER BY COALESCE(layer,0), way_area DESC

Instead of the longer

ORDER BY CASE WHEN layer~E'^-?\\d+$' AND length(layer)<10 THEN layer::integer ELSE 0 END, way_area DESC

There are also more significant changes for z_order, but that can be done post-merge

Disjoint areas

It uses -G, so disjoint areas are imported as PostGIS MULTIPOLYGONs instead of multiple rows as POLYGONs. These are often found on administrative boundary relations where islands are disjoint.

Tag columns

It uses --hstore, so tags that don't have a column end up in a special tags column. This allows for more flexability, and the number of columns has been significantly reduced

Multipolygon handling

The multipolygon handling is in the transforms, so instead of the C transforms, we are responsible for defining the handling.

For the purposes of this PR and the transforms, a multipolygon is either new-style or old-style. A new-style multipolygon has a tag other than type=multipolygon on the relation, and tags on its members are ignored. An old-style multipolygon is one with only a type=multipolygon and all the member ways have the same tags, or a member may be untagged. For technical reasons, deleted tags (e.g. source=*) are ignored.

There is also implicitly the definition of an invalid multipolygon, which is a type=multipolygon relation which doesn't meet the above criteria.

Some properties of MPs as defined like this are

  • Any new-style MP will never change to an old-style MP by only changing tags on its member ways, nor will it become invalid. Sudden changes to interpretation were possible with the C transform logic, where adding building=yes to a small object would set the building column to yes for a large object generated by a relation.

  • Any old-style MP will never change to an new-style MP by only changing tags on its member ways, but may become invalid if the tags become conflicting

  • type=multipolygon relations are always areas

  • Processing mulitpolygons does not require any knowledge of tagging semantics like is required for area formation from polygons. For technical reasons, deleted keys are ignored, which does involve tagging semantics.

Area handling

We can now determine if a way corresponds to an area feature or a linear feature however we want, instead of just based on tag keys. We want to avoid the interpretation of a correctly mapped feature depending on if a way is closed or not.

Open issues

  • Add comments to openstreetmap-carto.style pointing to INSTALL.md

  • Add something on using hstore to the code style guide (tags->'foo' instead of tags -> 'foo', etc) (#2552)

  • The interim need to backport PRs against both master and 3.x needs documenting in CONTRIBUTING.md

  • Define more precisely how long we will maintain 3.x and 4.x compatibility

  • Better document MPs somewhere

Pre-merge changes

The changelog and README.md version information need changing

A new git branch for 3.x.x work needs creating

Post-merge changes

Mark database layout milestone as finished

Fixes #101, #1362, #1504

Preview

I have a demo at https://lua.osm-carto.paulnorman.ca/. It is not consuming OSM updates. Before reporting a bug please

  • See if it's covered already in the discussion
  • See if it's an expected change
  • Check the OSM tagging so you can report what it is, if relevant
  • Check if the OSM data has recently changed

matthijsmelissen and others added some commits May 16, 2016

Database reload
**This is a pull-request against the lua branch**

This PR proposes a database-reload. It changes the documentation on the use of
osm2pgsql, and adds a .lua file for preprocessing.

This database import aims to be backwards compatible with older versions of
the style.

This resolves (at least part of) #1504.

 #Hstore
Adding the hstore option to osm2pgsql allows the database to use all keys.

This PR proposes using hstore for new keys, and using traditional columns for
old keys. This allows us to stay compatible with old versions of the style.

According to [@pnorman's benchmarks](http://www.paulnorman.ca/blog/2014/03/osm2pgsql-and-hstore/),
using hstore without dropping columns would lead to a 9% size increase and a
0.38% speed decrease. Given the benefits of having all columns available, I
would consider this acceptable.

 # Make polygon/linestring decision based on value
This is based on the following unmerged PR to osm2pgsql:
openstreetmap/osm2pgsql#346

It makes the polygon/linestring decision based on the tag value, in addition to
the tag key. In particular, highway=services and junction=yes are now treated as
polygon, while leisure=track, man_made=embankment, man_made=breakwater,
man_made=groyne, natural=cliff, natural=tree_row, historic=citywalls,
waterway=derelict_canal, waterway=ditch, waterway=drain, waterway=river,
waterway=stream, waterway=wadi, waterway=weir, power=line, and power=minor_line
are now treated as linestring.

This resolves #1362, resolves #137, resolves #268, and resolves #892.

 # Rendering order
The new .lua file creates a osmcarto_z_order value in the database, which stores
the rendering order we use. This will allow us to simplify the road queries.

 # Recommend -G flag for multipolygons
This resolves #59.

 # Import ele on buildings
This resolves #101.

 # Delete more meta-tags from imports
The .lua file drops some more meta-information from imports that is of no
need for rendering.

This is based on the following unmerged PR to osm2pgsql:
* openstreetmap/osm2pgsql#532
Convet layer to integer and user layer instead of z_order
* Convert layer to integer and use it in queries
* Use layer instead of z_order in queries where possible
Merge remote-tracking branch 'math1985/lua_changes' into lua
Conflicts:
	openstreetmap-carto.style
	project.mml
Merge tag 'v2.41.0' into lua
Tag v2.41.0

Conflicts:
	project.mml
Merge tag 'v2.42.0' into lua
Tag 2.42.0

Conflicts:
	project.mml
Drop sport from polygon_keys
Sport is a non-physical key, so it should always be combined with
another, physical key. That physical key should define whether the
object is a polygon or line. Since an object with a polygon key
and a line key will be treated as polygon, treating sport as line
by default is the sane default.

For example:
* sport=running, highway=footway should be treated as line. The
  current PR accomplishes this, before it would be a polygon.
* sport=soccer, leisure=pitch should be treated as polygon. Nothing
  changes here.

This resolves ... #854 but only after it gets merged into master.
Merge tag 'v2.43.0' into lua
Tag v2.43.0

Conflicts:
	project.mml
	project.yaml
Merge tag 'v2.44.0' into lua
Tag v2.44.0

Conflicts:
	project.mml
Merge tag 'v2.44.1' into lua
Tag v2.44.1

Conflicts:
	project.mml
@rory

This comment has been minimized.

Show comment
Hide comment
@rory

rory Feb 1, 2017

That's a strange one. Probably related to https://www.openstreetmap.org/relation/3697817. That relation makes me scratch my head a bit.

That relation is clearly trying to be an "apartment block complex". I'm not sure how to tag that properly. place=locality, or landuse=residential might make sense, but seems sub-par. Regardless, to me, a human, the relation makes sense, however I will probably try to improve it.

I wonder why it's not appearing on the map, and why some of the buildings are appearing, and others not.

rory commented Feb 1, 2017

That's a strange one. Probably related to https://www.openstreetmap.org/relation/3697817. That relation makes me scratch my head a bit.

That relation is clearly trying to be an "apartment block complex". I'm not sure how to tag that properly. place=locality, or landuse=residential might make sense, but seems sub-par. Regardless, to me, a human, the relation makes sense, however I will probably try to improve it.

I wonder why it's not appearing on the map, and why some of the buildings are appearing, and others not.

@jojo4u

This comment has been minimized.

Show comment
Hide comment
@jojo4u

jojo4u Feb 1, 2017

That relation is clearly trying to be an "apartment block complex". I'm not sure how to tag that properly. place=locality, or landuse=residential might make sense, but seems sub-par. Regardless, to me, a human, the relation makes sense, however I will probably try to improve it.

Use place=city_block (more formal), or place=neighborhood (more informal) or landuse=* as polygon, not relation. That relation is clearly really wrong tagging (boundary with buildings as member), so if no general problem can be extracted there is probably not no worth discussing.

jojo4u commented Feb 1, 2017

That relation is clearly trying to be an "apartment block complex". I'm not sure how to tag that properly. place=locality, or landuse=residential might make sense, but seems sub-par. Regardless, to me, a human, the relation makes sense, however I will probably try to improve it.

Use place=city_block (more formal), or place=neighborhood (more informal) or landuse=* as polygon, not relation. That relation is clearly really wrong tagging (boundary with buildings as member), so if no general problem can be extracted there is probably not no worth discussing.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Feb 5, 2017

Collaborator

Locality multipolygon (without layer=*) covers natural water:
https://lua.osm-carto.paulnorman.ca/#16/44.6720/-63.5527

Not a bug, http://www.openstreetmap.org/relation/1247705 had building=house.


Ignoring it in the sense of not rendering it would be fine.

Ignoring in the sense of not considering its behavior.


Both buildings haven't been touched in ~2 years, both are simple closed ways. (way 48,898,702 and way 48,898,703):

48898703 is not simple, it self intersects in the top left. 48898702 appears to be simple. It is a member of relation 4573941, which is an old-style MP with conflicting tags on members. This should hit the "This is an invalid old-style MP with conflicting tags" branch of logic. Given the bad geometry of the other way, I suspect a geometry problem I missed, but will need to recheck in the morning.

Fwiw, the geometry being formed for 3697817 is probably close to that of the pedestrian area minus the buildings.

Collaborator

pnorman commented Feb 5, 2017

Locality multipolygon (without layer=*) covers natural water:
https://lua.osm-carto.paulnorman.ca/#16/44.6720/-63.5527

Not a bug, http://www.openstreetmap.org/relation/1247705 had building=house.


Ignoring it in the sense of not rendering it would be fine.

Ignoring in the sense of not considering its behavior.


Both buildings haven't been touched in ~2 years, both are simple closed ways. (way 48,898,702 and way 48,898,703):

48898703 is not simple, it self intersects in the top left. 48898702 appears to be simple. It is a member of relation 4573941, which is an old-style MP with conflicting tags on members. This should hit the "This is an invalid old-style MP with conflicting tags" branch of logic. Given the bad geometry of the other way, I suspect a geometry problem I missed, but will need to recheck in the morning.

Fwiw, the geometry being formed for 3697817 is probably close to that of the pedestrian area minus the buildings.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Feb 5, 2017

Collaborator

Ignoring in the sense of not considering its behavior.

That is an understandable approach but i am a bit worried that while the mapper sees something is wrong it is not really understandable for him/her what exactly the problem is and how to fix it. What happens is that we wrongly interpret the tag on the inner ring to apply to the whole MP, i.e. we try to be smart and we fail with that. The logic behind this is difficult to communicate to the mapper.

I think the approach ignoring tags on members with role inner when interpreting tags for old style MPs might be worth considering. Even if this also includes ways that are not closed I don't have a scenario right now where this would make things substantially worse.

Collaborator

imagico commented Feb 5, 2017

Ignoring in the sense of not considering its behavior.

That is an understandable approach but i am a bit worried that while the mapper sees something is wrong it is not really understandable for him/her what exactly the problem is and how to fix it. What happens is that we wrongly interpret the tag on the inner ring to apply to the whole MP, i.e. we try to be smart and we fail with that. The logic behind this is difficult to communicate to the mapper.

I think the approach ignoring tags on members with role inner when interpreting tags for old style MPs might be worth considering. Even if this also includes ways that are not closed I don't have a scenario right now where this would make things substantially worse.

@daganzdaanda

This comment has been minimized.

Show comment
Hide comment
@daganzdaanda

daganzdaanda Feb 14, 2017

A new-style multipolygon has a tag other than type=multipolygon on the relation, and tags on its members are ignored

Does this affect the rendering of the member ways? I'm thinking of something like a way with barrier=* as an outer of some kind of landuse. Or some highway might be re-used as an outer or inner way. I would like to check this with your side-by-side comparison but I don't know how to find such MPs with overpass.

A new-style multipolygon has a tag other than type=multipolygon on the relation, and tags on its members are ignored

Does this affect the rendering of the member ways? I'm thinking of something like a way with barrier=* as an outer of some kind of landuse. Or some highway might be re-used as an outer or inner way. I would like to check this with your side-by-side comparison but I don't know how to find such MPs with overpass.

@pnorman pnorman removed their assignment Feb 22, 2017

+assert(isarea({leisure = "track"}) == 0, "test failed: leisure=track")
+assert(isarea({area = "yes", leisure = "track"}) == 1, "test failed: leisure=track with area tag")
+assert(isarea({waterway = "river"}) == 0, "test failed: river")
+assert(isarea({waterway = "riverbank"}) == 1, "test failed: river")

This comment has been minimized.

@pnorman

pnorman Feb 22, 2017

Collaborator

wrong test name

@pnorman

pnorman Feb 22, 2017

Collaborator

wrong test name

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Mar 22, 2017

Collaborator

@pnorman What is the status of this PR? Do you need anything, like help or reviews?

Collaborator

matthijsmelissen commented Mar 22, 2017

@pnorman What is the status of this PR? Do you need anything, like help or reviews?

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Mar 22, 2017

Collaborator

@pnorman What is the status of this PR? Do you need anything, like help or reviews?

Help addressing the comments raised, particularly the MP ones.

You can either push directly to this branch, or do a PR against it.

Collaborator

pnorman commented Mar 22, 2017

@pnorman What is the status of this PR? Do you need anything, like help or reviews?

Help addressing the comments raised, particularly the MP ones.

You can either push directly to this branch, or do a PR against it.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Apr 13, 2017

Collaborator

I haven't had a chance to look at this lately, and it doesn't look like anyone else has. Working on a different style for a job reduces the motivation to work on osm-carto for fun.

With the progress on old-style MP cleanup the number of old-style MPs has dropped from 8% mid-march to 3% mid-April. With osm2pgsql we're considering dropping old-style support by default and if we did the same here, it would avoid all the questions on how to handle old-style MPs.

Collaborator

pnorman commented Apr 13, 2017

I haven't had a chance to look at this lately, and it doesn't look like anyone else has. Working on a different style for a job reduces the motivation to work on osm-carto for fun.

With the progress on old-style MP cleanup the number of old-style MPs has dropped from 8% mid-march to 3% mid-April. With osm2pgsql we're considering dropping old-style support by default and if we did the same here, it would avoid all the questions on how to handle old-style MPs.

@nebulon42

This comment has been minimized.

Show comment
Hide comment
@nebulon42

nebulon42 Apr 14, 2017

Contributor

Regarding old-style MPs I would be much in favour of that. I'm sure that the cleanup will progress to a point where this is no problem anymore.

Contributor

nebulon42 commented Apr 14, 2017

Regarding old-style MPs I would be much in favour of that. I'm sure that the cleanup will progress to a point where this is no problem anymore.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Apr 14, 2017

Collaborator

That's great news. I would also be strongly in favour of dropping support for old-style multipolygons.

Collaborator

matthijsmelissen commented Apr 14, 2017

That's great news. I would also be strongly in favour of dropping support for old-style multipolygons.

pnorman added some commits Apr 16, 2017

Merge pull request #2610 from pnorman/lua/no_old_style_mps
Remove support for old-style multipolygons

@pnorman pnorman self-assigned this Apr 17, 2017

pnorman added some commits Apr 17, 2017

@pnorman pnorman referenced this pull request in ClearTables/ClearTables Apr 19, 2017

Closed

Drop old-style multipolygons #111

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Apr 20, 2017

Collaborator

I'm not sure why this showed up in the diff.

Collaborator

pnorman commented on scripts/lua/test.lua in cb23299 Apr 20, 2017

I'm not sure why this showed up in the diff.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Apr 20, 2017

Collaborator

This is now ready. Before merging we want to

  • clean out the PR backlog,
  • do another full planet demo,
  • release 3.3.0, and
  • impose a feature freeze for cartographic changes after 3.3.0 until 4.0.0 is released

I'd also like to move religion to hstore, but if that doesn't get done it won't hold up the release.

Collaborator

pnorman commented Apr 20, 2017

This is now ready. Before merging we want to

  • clean out the PR backlog,
  • do another full planet demo,
  • release 3.3.0, and
  • impose a feature freeze for cartographic changes after 3.3.0 until 4.0.0 is released

I'd also like to move religion to hstore, but if that doesn't get done it won't hold up the release.

@nebulon42 nebulon42 referenced this pull request Apr 30, 2017

Closed

Add rendering for golf=* #661

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 5, 2017

Collaborator

I squeezed some more disk space out of one of my servers, so it looks like I can do a test over the weekend, then we can proceed.

Collaborator

pnorman commented May 5, 2017

I squeezed some more disk space out of one of my servers, so it looks like I can do a test over the weekend, then we can proceed.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 8, 2017

Collaborator

https://lua.osm-carto.paulnorman.ca is running with the latest code, I'm looking to tag 3.3.0 and freeze in a couple days.

Collaborator

pnorman commented May 8, 2017

https://lua.osm-carto.paulnorman.ca is running with the latest code, I'm looking to tag 3.3.0 and freeze in a couple days.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico May 8, 2017

Collaborator

Nice. Comparison is somewhat difficult since the style version is different in the standard map at the moment and the low zoom tiles are also very old there right now.

Am i right to assume that this does not yet use libosmium for geometry building (openstreetmap/osm2pgsql#684)?

Collaborator

imagico commented May 8, 2017

Nice. Comparison is somewhat difficult since the style version is different in the standard map at the moment and the low zoom tiles are also very old there right now.

Am i right to assume that this does not yet use libosmium for geometry building (openstreetmap/osm2pgsql#684)?

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen May 8, 2017

Collaborator

Looks good!

I had no time to analyse this yet, but here is a difference:
https://lua.osm-carto.paulnorman.ca/#18/49.58117/6.12971

Collaborator

matthijsmelissen commented May 8, 2017

Looks good!

I had no time to analyse this yet, but here is a difference:
https://lua.osm-carto.paulnorman.ca/#18/49.58117/6.12971

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 8, 2017

Collaborator

Am i right to assume that this does not yet use libosmium for geometry building

No, it's using released osm2pgsql.

Collaborator

pnorman commented May 8, 2017

Am i right to assume that this does not yet use libosmium for geometry building

No, it's using released osm2pgsql.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 9, 2017

Collaborator

I had no time to analyse this yet, but here is a difference:
https://lua.osm-carto.paulnorman.ca/#18/49.58117/6.12971

Object in question is http://www.openstreetmap.org/way/77686091 with leisure=track, so this is an expected difference, and, as it happens, a tagging error.

Collaborator

pnorman commented May 9, 2017

I had no time to analyse this yet, but here is a difference:
https://lua.osm-carto.paulnorman.ca/#18/49.58117/6.12971

Object in question is http://www.openstreetmap.org/way/77686091 with leisure=track, so this is an expected difference, and, as it happens, a tagging error.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen May 9, 2017

Collaborator

Object in question is http://www.openstreetmap.org/way/77686091 with leisure=track, so this is an expected difference, and, as it happens, a tagging error.

We might want to add a rendering rule though. We could render it equal to racetracks for now, so there is at least something.

Collaborator

matthijsmelissen commented May 9, 2017

Object in question is http://www.openstreetmap.org/way/77686091 with leisure=track, so this is an expected difference, and, as it happens, a tagging error.

We might want to add a rendering rule though. We could render it equal to racetracks for now, so there is at least something.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico May 9, 2017

Collaborator

Yes, we should render leisure=track on lines but no, not like racetracks. The latter is for motor sports, the former for running sports, very different things we also render very differently.

Ideally i think leisure=track on lines should be the same as on areas, i.e. line with thin casing. And preferably in a way that combines with areas, i.e. render casings below and fills above areas.

Collaborator

imagico commented May 9, 2017

Yes, we should render leisure=track on lines but no, not like racetracks. The latter is for motor sports, the former for running sports, very different things we also render very differently.

Ideally i think leisure=track on lines should be the same as on areas, i.e. line with thin casing. And preferably in a way that combines with areas, i.e. render casings below and fills above areas.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico May 9, 2017

Collaborator

Ok, i inspected the map a bit more and it seems to me most of the differences that are not either due to the style version difference or due to data changes are

  • the vanishing of independently labeled multipolygon components and the resulting duplicate labels which is mostly a very positive effect (see #59).
  • the different interpretation of closed ways with leisure=track as @math1985 already spotted.
  • the lack of transfer of member way tags to multipolygon relations due to the removal of support for old style MPs. Like for example here:

http://www.openstreetmap.org/way/100827142

This water area tag is now interpreted while previously it was ignored because it was redundant with the relation tag so the islands in the river vanish. I expected this effect to be much more widespread, especially for water areas since in the past it had been common practice to simply add waterway=riverbank to all outer ways of a a river polygon and if a water area tag was added to the relation it was not removed from the ways. But it is less frequent than i thought although still pretty visible in some areas, in particular India and China. Since this particular kind of faulty double tagging is not covered by OSMI and Osmose and this is kind of connected to the elimination of old style multipolygons because it only matters if you ignore old style tagging it might be useful to think about including these in the multipolygon cleanup effort - cc @joto.

Collaborator

imagico commented May 9, 2017

Ok, i inspected the map a bit more and it seems to me most of the differences that are not either due to the style version difference or due to data changes are

  • the vanishing of independently labeled multipolygon components and the resulting duplicate labels which is mostly a very positive effect (see #59).
  • the different interpretation of closed ways with leisure=track as @math1985 already spotted.
  • the lack of transfer of member way tags to multipolygon relations due to the removal of support for old style MPs. Like for example here:

http://www.openstreetmap.org/way/100827142

This water area tag is now interpreted while previously it was ignored because it was redundant with the relation tag so the islands in the river vanish. I expected this effect to be much more widespread, especially for water areas since in the past it had been common practice to simply add waterway=riverbank to all outer ways of a a river polygon and if a water area tag was added to the relation it was not removed from the ways. But it is less frequent than i thought although still pretty visible in some areas, in particular India and China. Since this particular kind of faulty double tagging is not covered by OSMI and Osmose and this is kind of connected to the elimination of old style multipolygons because it only matters if you ignore old style tagging it might be useful to think about including these in the multipolygon cleanup effort - cc @joto.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 9, 2017

Collaborator

I guess the question is, do we want to hold up 3.3.0/4.0.0 to make any of these changes?

Collaborator

pnorman commented May 9, 2017

I guess the question is, do we want to hold up 3.3.0/4.0.0 to make any of these changes?

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico May 9, 2017

Collaborator

I don't think so. If anyone wants to add rendering of leisure=track as lines that would be most welcome but it does not really matter much if this happens before or after the release. It is not that anything that has been rendered correctly before is rendered incorrectly with this change and would be rendered exactly right if we add new support for this. We drop support for rendering closed ways with leisure=track and without area=yes as areas and we would in the future like to add support for rendering them as lines.

And the faulty double tagging can be fixed as easily after the change than before - in fact if the change is rolled out the motivation for fixing is probably higher since it would fix a visible error while right now it would be an invisible change.

Collaborator

imagico commented May 9, 2017

I don't think so. If anyone wants to add rendering of leisure=track as lines that would be most welcome but it does not really matter much if this happens before or after the release. It is not that anything that has been rendered correctly before is rendered incorrectly with this change and would be rendered exactly right if we add new support for this. We drop support for rendering closed ways with leisure=track and without area=yes as areas and we would in the future like to add support for rendering them as lines.

And the faulty double tagging can be fixed as easily after the change than before - in fact if the change is rolled out the motivation for fixing is probably higher since it would fix a visible error while right now it would be an invisible change.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen May 9, 2017

Collaborator

I guess the question is, do we want to hold up 3.3.0/4.0.0 to make any of these changes?

As far as I'm concerned, no.

Collaborator

matthijsmelissen commented May 9, 2017

I guess the question is, do we want to hold up 3.3.0/4.0.0 to make any of these changes?

As far as I'm concerned, no.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman May 9, 2017

Collaborator

I'll look at tagging 3.3.0 tonight, which will also involve a feature freeze until 4.0.0.

Collaborator

pnorman commented May 9, 2017

I'll look at tagging 3.3.0 tonight, which will also involve a feature freeze until 4.0.0.

@pnorman pnorman merged commit a002f47 into master May 10, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@joto joto referenced this pull request in osmlab/fixing-polygons-in-osm May 10, 2017

Open

Ways with same tags as mp relation #36

@sommerluk

This comment has been minimized.

Show comment
Hide comment
@sommerluk

sommerluk May 10, 2017

Collaborator

A big “thanks” for making this working!

Collaborator

sommerluk commented May 10, 2017

A big “thanks” for making this working!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment