Can stage 2 flex processing dissolve line geometries?

[mboeringa]

Hi,

I have recently been exploring the possibilities of the new flex output based on Paul's development work for creating a "flex version" of 'openstreetmap-carto' (gravitystorm/openstreetmap-carto#4431).

As one nice enhancement to the original 'openstreetmap-carto' style, the new "flex version" of that style uses a Lua script that creates a new 'planet-osm-admin' table containing de-duplicated line geometries for OpenStreetMap admin_level boundaries, where the geometries of the lines always represent the highest rank admin_level that is present on a border line.

E.g. an "admin_level=2 " boundary line that is also an "admin_level=4" and "admin_level=8" boundary, will end up in the 'planet-osm-admin' table as "admin_level=2".

This allows symbolizing the lines in a more cartographically advanced way, e.g. by using open stippled lines like in true topographic maps, instead of having to properly stack solid lines for different admin_levels to "hide" less important border lines as is needed with polygon outline symbology.

While nice, the current implementation of the Lua style has one issue: common boundaries of the same admin_level between e.g. two bordering countries, are not being dissolved into a single line. E.g. see the attached image, where the boundary between Liechtenstein and Austria consists of multiple segments, as highlighted by a selected light blue segment. This may subsequently cause symbolization discontinuities between individual segments of a single border, a problem which is hardly noticeable at large scales (e.g. > 1:50k), but gets worse with smaller scales (e.g. 1:1M).

This raises a question for me:

Would it potentially be technically possible to use osm2pgsql's stage 1/2 flex processing to merge all the segments of a single boundary line, where the segments are all of the same admin_level, e.g. "admin_level=2", and the "admin_level=2" relations associated with them are the same?

Or is this outside of the capabilities of current flex processing?

[joto]

No this isn't possible with current osm2pgsql flex processing, altough I am sure you can figure something out with triggers or so to do this after osm2pgsql runs just in the database.

[mboeringa]

Hi @joto,

Thanks. After re-reading the documentation, I realized this as well.

I have now been able though, using the information of the osm2pgsql manual, to adjust the osm2pgsql Lua flex style file, to have osm2pgsql output an extra column in the 'planet_osm_admin' table, that now includes the OSM IDs of the two boundary relations making up a border line. See the attached image, where the column highlighted in red contains a semi-colon concatenated list of the corresponding OSM IDs. This actually makes the multiple_relations boolean column, that Paul initially added, superfluous, and I will probably drop it in favor of the new more informative column.

The blue highlighted section, shows the ways conforming to the Liechtenstein (OSM ID '1155955') and Switzerland (OSM ID '51701') border, also see the second image for the selection displayed spatially.

This means it should now be a breeze to dissolve the lines by simply selecting the relation_ids and admin_level columns as input for the dissolve process.

It actually cost me two days to figure out how to do it, as I was initially mis-interpreting the documentation and how osm2psql processes the data and Lua file, and the Lua flex style code, thinking it would require adjustments to the osm2pgsql.process_relation() function, while in the end, it turned out to only require minimal changes to Paul's well structured work, and the addition of just a few lines of code in a few specific places.

[mboeringa]

Success,

The entire Belgium / Netherlands border reduced to just a single line (ignoring the border mess of Baarle-Nassau/Baarle-Hertog), based on a dissolve on the 'admin_level' and 'relation_ids' fields. Took me a while to figure out how to most efficiently do this with PostGIS and integrate it with some other code, but this now works like a charm.