Administrative boundary is not rendering consistently

[seav]

Expected behavior

All boundary ways should be rendered for all role=outer and inner way members of a type=boundary + boundary=administrative + admin_level=10 relation.

Actual behavior

One outer member way is not rendered with the usual dotted line, while adjacent member ways have their dotted lines rendered. Weirdly, the administrative boundary name label is rendered along the unrendered boundary way (see attached screenshot) which implies that there is no geometry problem in the boundary relation itself.

Links and screenshots illustrating the problem

The outer boundary member way that is not rendered with dotted lines (but labels are rendered): https://www.openstreetmap.org/way/704324668

Screenshot (missing boundary is near the bottom of the image):

[jeisenbe]

I've downloaded the data and tested it with the current master branch, with the same rendering result.

The high-zoom level administrative boundary lines are rendered based on type=boundary and multipolgyon relations imported into planet_osm_roads and tagged with boundary=administrative' plus admin_level=<1 to 10>. There appears to be a properly constructed type=boundary` relation with this tags which includes the missing way as a member with role "outer". So I'm not sure what is happening here. The way is also tagged individually with boundary=administrative and admin_level=10, but this isn't used for rendering the lines, as far as I can tell. Deleting this tags did not change the (lack of) rendering of this way.

The name label may still rendering because the administrative boundary labels are rendered from both relations and ways, but I'm not sure.

Does anyone understand the cause of this behavior?

The relation is Mampio (9794046) and the way is 704324668

[pnorman]

The next step is to load that data and then examine it in the DB with qgis or similar

[jeisenbe]

Walter left a comment which I received in email, though it seems to have disappeared here on github:

"This is quite simple: Because this way a) is not a member of an admin relation and b) is not closed (it has to be closed to be a polygon), it is not rendered.
"Fortunately, because we still have a lot of this junk in the DB.
"Regards walter"

The rendering is now fixed, so it appears that the relation was broken previously. I'm not sure why I missed the problem in JOSM.

It's a bit of a mystery to me why the text label was still rendering above, when the line wasn't.

The only difference current difference between admin-high-zoom and admin-text layers are that admin-high-zoom is from planet_osm_roads and admin-text is from planet_osm_polygon. Both selection the same features with osm_id < 0 (only relations) now - but before 96c64fa admin-text was rendered from the ways, not just the boundary relations, so that's the source of the difference

[seav]

I think this issue should be reopened because the bug is not resolved and has become slightly crazier. As you can see from the screenshot below, previously no border line was rendered but now two borders lines are rendered (the upper border is incorrect based on the stored data in OSM), and a segment of the coastline that is part of the admin relation (between the 2 duplicated borders) is not rendering as a border.

[jeisenbe]

You are right. I tried downloading the new data and rendering again on my setup, and I get the same error:

z17 current test rendering

z19 current test

I guessed that it might be caused by an error in the line-simplify algorithm, but tests with this removed did not fix the problem:

Test without line-simplify:

z19 after

I downloaded the full relation in JOSM and there are no validator errors now.

[jeisenbe]

I fixed the rendering by reversing the direction of way 704324668 so that it's the same as the direction of the coastline:

I'm not certain why this makes a difference. Other areas such as multipolygons seem to be imported without problems when not all of the ways are aligned end-to-end.

Is it an error in osm2pgsql, @pnorman?

[seav]

I think the way direction should not make any difference. I think this edge case reveals a bug somewhere in the toolchain.

[jeisenbe]

Weirdly, the administrative boundary name label is rendered along the unrendered boundary way (see attached screenshot) which implies that there is no geometry problem in the boundary relation itself.

That is probably due to #2234 - admin line are rendered from planet_osm_roads which contains linestrings (if I understand correctly), but the text labels are rendered from planet_osm_polygon.

It is possible that switching the admin lines to render from planet_osm_polygon will also resolve this issue.

But I am still curious if there is something in osm2pgsql that is causing this error.

[matkoniecz]

Ghost ways may be caused by a osm2pgsql bug osm2pgsql-dev/osm2pgsql#1394

https://lists.openstreetmap.org/pipermail/dev/2021-February/031048.html

The error happens when there is a boundary relation containing exactly
two ways forming a closed ring and the ways are oriented against each
other. So they both have the same first and last nodes. The bug does
not appear when the last node of one of the ways is the first node of
the other. (Most likely the bug will also happen if there are four
ways of which two create one ring and two another etc.)

It is also possible to fix at least some of these cases by simply
turning around one of the member ways. You can do this without the
software having been updated. Just take care that turning around the
way doesn't create other problems.

Once new osm2pgsql is deployed on OSM servers this bug will also disappear as boundaries are edited in general.

[matkoniecz]

As original issue is fixed and phantom line is caused by a known bug I will close it. Thanks to @joto for a fix in osm2pgsql-dev/osm2pgsql#1396 !

Note that OSM servers will be fixed once it gets deployed and relevant boundaries are edited.

See also https://wiki.openstreetmap.org/wiki/User:Mmd/Overpass_API_-_experimental_corner#osm2pgsql_relation_issue