Ghost ways from rendering

[gvghia]

Hi, someone pointed met to this list for indicating following problem as in these examples: https://www.openstreetmap.org/#map=19/45.11380/-85.60905&layers=D and https://www.openstreetmap.org/way/254310728/history . You see a strait ghost line crossing the boundary surface and which is not aligned in blue as data or can we selected, by 'what is here'
It seems there is a dependency for making boundary (or even polygon) relations, when they consist of 2 ways. When there are 3 or more ways, the direction of the ways does not matter. When there are only 2 and they have the same starting and end point, then to assemble the points for making the drawing, one way get inserted between the first and second point of the other way. This results in a ghost line from this second point to the endpoint. Solution is to eliminate this wrong behaviour in the renderer.
Workaround is to reverse one of the two ways, so their points will be consecutive as a ring. Probably splitting one way in 2, could also do the trick. This boundary is solved: https://www.openstreetmap.org/note/1948614#map=17/50.79530/4.60589&layers=N https://www.openstreetmap.org/note/1948614#map=17/50.79530/4.60589&layers=N The main and humanitarian layer exhibits this problem. Öpvn seems to have a better algorithm and is not having ghost ways. Background info is also in Help https://help.openstreetmap.org/questions/78014/deleting-a-ghost-way

[joto]

This is not the place to talk about rendering. Why are you reporting this here? Is there something wrong with osm2pgsql? Do you have a specific example of an OSM data file that will result in wrong data in the database when imported with osm2pgsql?

[gvghia]

I'm sorry if I bothered the wrong people with this. Please kindly suggest where to post.
I posted here as a result of the comments of ikonor, (see last link) who was able to recreate the problem with Docker and thus assuming the problem is in osm2pgsql. As I understand it, somewhere the 2 ways with points a b c z and a x y z from a boundary relation are joined to draw. Expected result is a b c z y x a , but a x y z b c z is the actual result (second way is inserted between first and second point of first way) and this is creating a ghost line b z .
I do not know at which processing stage this joining of the 2 ways is done. There are 2 examples where the phenomena still exists, so you could verify.

[nrenner]

A historic version of relation: ‪Loonbeek‬ (‪4099160‬):

[date:"2021-01-09T00:00:00Z"];
(
  relation(4099160);
);
(._;>;);
out meta;

http://overpass-turbo.eu/s/12bp

ends up in the rendering database like this:

Therefore I suspect an issue with osm2pgsql. For more details see my answer on help (and comment).

[lonvia]

Thanks for the example, I can reproduce it. The ghost line shows up in the planet_osm_line table.

[mmd-osm]

NB: as of today, about 4839 type=boundary relations having 2 outer ways (or roughly 0.7% of all type=boundary relations) qualify for this bug. This should be seen as an upper limit. Depending on the relation geometry, the ghost line may not be visible at all.

Fixing relations by reversing the direction of some ways might trigger the same bug in adjacent relations as long as osm2pgsql 1.4.1 hasn't been deployed yet.

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