Limit dual insertion in Line and Polygon table to "boundary=administrative" #4549
Conversation
…rative" Hi Paul, this is a proposal for a minor change to the relation function. Currently, if a relation is tagged as either "type=boundary" or "type=multipolygon" with a boundary tag, then the feature will end up as both a geometry in the Line as well as Polygon table. While this is the desired behavior for administrative boundary relations to allow sophisticated Line symbology and de-duplication of administrative boundary lines of different "admin_level", other "boundary" relation types like "type=boundary and boundary=protected_area", should likely only end up in the Polygon table, not the Line table, as they usually do not represent contiguous topological connected structures, but are usually "stand-alone". This change now limits dual insertion in Line and Polygon table to "boundary=administrative" tagged features only.
There was a problem hiding this comment.
This needs to be accompanied by changes to the tests.
I'm not sure this is the right change to make, as admin geometries are in the planet_osm_admin table, and I don't see a need for any boundary or multipolygon relations to go into the line or roads table anymore.
@pnorman , Yes, I guess you may be right on this one... I hadn't yet really given that enough thought. So simply deleting the code lines involving the add_line and add_roads functions in the process_relation function would be the logical solution to this? |
|
It can be simplified further because it's then the same as the code in the next elseif block. And many tests will no longer apply. |
|
On the other hand: wasn't this about a kind of "soft" backwards compatibility with existing openstreetmap-carto derived styles, to allow a more gradual transition to the new schema including the new transport and admin tables? Did the old 'pgsql' output of osm2pgsql insert line versions of admin boundaries in the "planet_osm_roads" and "planet_osm_line" table? If so, it might be better to maintain this, unless you want to deliberately break the backwards compatibility and remove the "planet_osm_roads" table entirely from the style definition, which would force users to switch over to the new "planet_osm_transport_line" table. |
Preserving backwards compatibility isn't a hard requirement.
osm2pgsql doesn't define that, the transforms you give it do. For the current OpenStreetMap Carto ones, it has the same logic as flex does right now. |
If that is the case, then I'd suggest ripping out the entire 'planet_osm_roads' table definition from the flex style. With the new 'planet_osm_transport_line' table, it no longer really has a function. Other option is to make the creation of this specific table configurable, as I did in my variant of your style where simply switching a boolean determines which tables are created. But that only complicates the code, so ripping it out, is probably the better option. But this is getting slightly off topic regarding the specific issue of all types of boundary relations ending up in both the 'planet_osm_line' and 'planet_osm_polygon' tables, that this pull request attempted to address. |
This PR would break backwards compatibility. |
Yes, I understand that now based on your reference to the old 'pgsql' LUA style, thanks for referencing it. That said, there is the interesting thing that I cannot remember seeing some of the same issues with duplicated labels I experienced now (based on Line and Polygon geometries), when I still used the old 'pgsql' style and older versions of osm2pgsql... But maybe, or likely, I overlooked it, despite having extensively reviewed maps created with the 'old' and 'new' osm2pgsql and styles. |
Hi Paul, this is a proposal for a minor change to the relation function of the osm2pgsql flex version of the style.
Currently, if a relation is tagged as either "type=boundary" or "type=multipolygon" with a boundary tag, then the feature will end up as both a geometry in the Line as well as Polygon table.
While this is the desired behavior for administrative boundary relations to allow sophisticated Line symbology and de-duplication of administrative boundary lines of different "admin_level", other "boundary" relation types like "type=boundary and boundary=protected_area", should likely only end up in the Polygon table, not the Line table, as they usually do not represent contiguous topological connected structures, but are usually "stand-alone".
This change now limits dual insertion in Line and Polygon table to "boundary=administrative" tagged features only.