Deleting a ghost way

Question

There is a way on the map, that has to be deleted, but it can not be identified on the map, nor does it show up in the ID or JOSM editors.

It seems a kind of artefact or a partial delete, which is still displayed by the renderer, but has no handles for identifying or editing. I tought it was an issue for smeone that had access to the underlying database and so I have sent ths question to operations, but they pointed me to thhs list.

You can see it in the Margijsbos of Loonbeek aside of this remark.

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

It seems to stretch from this point

https://www.openstreetmap.org/node/3120383135#map=17/50.81316/4.58758&layers=N https://www.openstreetmap.org/node/3120383135#map=17/50.81316/4.58758&layers=N

(left line going south) to this point

https://www.openstreetmap.org/node/8244031909 https://www.openstreetmap.org/node/8244031909

As you can see in the attached way list of the first point, the ghost way is not there.

In an attempt to cut it down, I deleted the last point and recreated it, and also the neighbourhood point on the Nijvelsebaan, but to no avail.

So,how to get rid of and delete that ghost way?

Kind Regards,

Answer 1

3

The ghost line can be reproduced by rendering a current¹ extract with the openstreetmap-carto docker setup.

Inspecting the line in QGIS or selecting it by intersection ² shows a broken geometry in the rendering database for the admin boundary of Loonbeek (relation 4099160):

See the selected GeoJSON geometry here.

The ghost line appears because way 306997188 is connected to the wrong end of 306997189 for some reason.

Reversing the way direction of 306997189 solves the issue, so the problem seems to be the opposing directions of the two ways in the admin relation.

Is it a known requirement for ways in an admin boundary relation to have the same direction (I'm not aware of it and haven't found anything in the wiki) or is this rather an osm2pgsql issue?

¹ as of 09 Jan 2021, fixed in the OSM DB in the meantime

²

SELECT osm_id, admin_level, ST_AsGeoJSON(ST_Transform(way,4326), 7) 
  FROM planet_osm_roads 
 WHERE ST_Intersects(ST_Transform(way,4326), 
         'SRID=4326;LINESTRING(4.6049880 50.7947191, 4.6066188 50.7952887)');

permanent link

answered 09 Jan '21, 13:07

ikonor
1.3k●2●11●19
accept rate: 18%

edited 15 Jan '21, 07:37

1

Given the result above, the rendering and fix can be reproduced by just exporting relation 4099160 with http://overpass-turbo.eu/s/12bp and converting it to PBF (and fixing it) in JOSM.

For faster import, I also disabled importing external data by commenting this line: https://github.com/gravitystorm/openstreetmap-carto/blob/b10aef3866bacf387581b8fea4eec265010b0d14/scripts/docker-startup.sh#L55.

(09 Jan '21, 13:19) ikonor

Hi, thanks for your answer. I tried to recreate with QGIS the problem, but I did not succeed. I downloaded the Lookbeek.osm.pbf I can extract the 2 ways, but they are identical as on OSM. Also with the overpass query, the points in the ways are with good succession. In the result is also a collection of all nodes in use, but seemingly in some sorted order, but at many places not in the right succession. If I export from QGIS these two ways to GeoJson and compare these with the raw geojson of your result with the broken relation example, then I see that there is the first node of way 306997189, followed by all nodes of way 306997188, then followed by the rest of the nodes. So, it seems for having the complete border, your result has inserted the second way, between the first and second node of the first way. Your result has also an opening, which is not on the map. I can not imagine that the direction of the ways could be of importance. As this village is between 2 others bordering each other at north and south, there will be always a border in the 'wrong' direction. I do not understand how this blending happens and even less what I'm supposed to do in JOSM to prevent it.

(09 Jan '21, 19:49) ghia

My comments with QGIS and JOSM both refer to setting up a local rendering database by following the Docker installation instructions for the OpenStreetMap Carto map stylesheet (for both a complete extract and just the relation).

But I don't expect you to do that. My answer is just a very technical description how I found out what the ghost line is and is probably more for developers.

I suspect this might be a bug in the software osm2pgsql, that imports raw OSM data into a separate rendering database. For that, it resolves node references of all ways in the relation and converts those into a single linestring geometry - something is going wrong there.

I will open an osm2pgsql issue, just wanted to know if there is a way direction requirement that I don't know of.

What you could try is reversing the direction of way 306997189 in OSM and see if the ghost line disappears.

(09 Jan '21, 22:27) ikonor

I have removed my testbox and shifted way 1 down to the second position in the relation. Now the fault exposes on node 2 of the other way (Huldenberg side). https://www.openstreetmap.org/node/3120383839 It exposes on main layer and humanitarian. On ÖPNV it does not. Apparently they have a better algoritme to join the ways. I can reverse once a way, but I hope the problem does not displace to the neighborough village.

(10 Jan '21, 17:49) ghia

I have set the order of ways back and also reversed the direction of the boundary way of Neerijse. Both ways are now clockwise. I checked the 2 other known cases and they are also with 2 ways in a relation and one way is clockwise and the other is anti-clockwise, meaning first and last waypoints are the same in both ways. Also the ghost border starts at the second point. I suspect many more examples could be found on the map. We will see tomorrow as rendering catches up for the result.

(10 Jan '21, 20:21) ghia

Answer 2

0

I expect someone was editing the Loonbeek and adjoining admin boundary recently and saved their work with the line you refer to being part of the boundary. The boundary appears correct now and takes a different course in the database and with more time the rendering will eventually catch up with the changes.
https://www.openstreetmap.org/relation/4099160#map=15/50.8004/4.6016

Edit: i should add that I have no info on where the actual border should lie.

The WhoDidIt tool would have been great to check the recent edits in the area and display in archavi but has not worked few a few months now. I find it odd that tiles seem out of date, but noticed it is only out dated on the main osm page and the humanitarian layer. The others are not updated as often and don’t show the way.

permanent link

answered 20 Dec '20, 23:40

nevw
9.8k●26●90●178
accept rate: 9%

edited 21 Dec '20, 02:58

The last modification was 10 months ago. The remark dates from a year ago. How long to catch up??? Normally you see effects after some minutes. Did you change something? Or even noticed the fine border line in the wood aside the remark?

(21 Dec '20, 02:35) ghia

Maybe better to see in the fields: https://www.openstreetmap.org/note/1948614#map=19/50.79974/4.60101&layers=N

(21 Dec '20, 02:39) ghia

I'm out of ideas. Maybe there have been no further modifications of the tiles between the 2 points connecting that line in that period and the renderer hasn't needed to update them . It can be seen on all levels from zoom 13.

(21 Dec '20, 03:45) nevw

1

I've encountered a similar rendering issue, for example https://www.openstreetmap.org/#map=19/45.11380/-85.60905&layers=D

I think I looked around a fair amount when it came up a year ago and didn't find much. But it's certainly in the rendering system and not in the data.

(21 Dec '20, 03:59) maxerickson

Another example is the France/Newfoundland border at https://www.openstreetmap.org/way/254310728/history - whatever that straight line is, it's not in the data now.

(21 Dec '20, 08:42) SomeoneElse ♦

If it is a render problem, then you could solve it, by drawing a temporary border as a small rectangle around it. But for the moment the ghost way is being in a rerendering process and i have 2 screenshots where you can see at zoom 17 that the feature is now aside this point https://www.openstreetmap.org/node/249780862#map=19/50.79257/4.60822&layers=N on the west side in the wood, and before it was at the east and crossing the tip of the field. I remarked it because there was a tile split in the gray residential zone. It moved a few m. So, i don't think it is an old tile issue.

(21 Dec '20, 12:09) ghia

Sorry mixed up east and west. You can see the displacement by looking at this point in humanitarian layer https://www.openstreetmap.org/node/2619617941#map=19/50.80021/4.60049&layers=HN where the gost border nearly goes trough and in standard it is clearly away.

(21 Dec '20, 12:28) ghia

The ghost border seems continue 'on the move'. Now it seems again to reposition on the place of humanitarian and in the field there is now a tile split and the upper part is running nearly through the corner again, while before it was clearly apart.

(25 Dec '20, 11:13) ghia

I added as test a surrounding border and i am waiting for its rendering and will see of the ghost border disappears or not.

(01 Jan '21, 12:44) ghia

A day later, and the box is not yet showing on the main OSM layer. In Transport the box is shown, without the ghost border, but it was not there before either. On humanitarian, the box is showing on some levels, but the ghost border is still there. https://www.openstreetmap.org/#map=19/50.79196/4.60891&layers=HN (partial) https://www.openstreetmap.org/#map=19/50.80027/4.60018&layers=HN See in main layer partial redraw of the ghost (tile split) https://www.openstreetmap.org/#map=19/50.80027/4.60018&layers=N Should the ghost also stay, when the box appears? What is to conclude about this? And what will be the final resolution? Has someone to delete some tiles to force a clean redraw?

(02 Jan '21, 21:22) ghia

3 days after edit and not yet to see on the main layer. Altough the ghost border itself seems still moving. In all zooms it is now going through the corner, except for 17. In 18 some tiles are making progress to that location. https://www.openstreetmap.org/#map=19/50.79985/4.60089 Because last edits are dated a few years ago, must I now expect to see the ghost border to disappear in 2025 or 2030? As the other layers, in contradiction to common belief, were quicker to add the test border, i'm wondering about the update policies for the main layer.

(05 Jan '21, 11:15) ghia

Your box is mapped as way, but main style only renders relations as boundary.

Ghost line moved because of your node replacement (https://www.openstreetmap.org/node/8244031909) in CS https://www.openstreetmap.org/changeset/96126872.

Partial redraw (tile split) is because tiles are mixed from different rendering servers and server "ysera" has still some old tiles before your node replacement.

(09 Jan '21, 13:12) ikonor

showing 5 of 12 show 7 more comments

Answer 3

0

Thanks to the help of ikonor, who unravelled the mechanisme, this lasting for years problem of the ghost way is finally solved. So 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. @ikonor Were you able to find a place and / or to file a report about this problem? Or is there a suggestion were i could file this? 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.

permanent link

answered 14 Jan '21, 09:46

ghia
136●2●3●7
accept rate: 0%

If you can find an example of a "problem polygon" in the UK I'd be happy to investigate.

More generally, trying to investigate a rendering bug using the servers at OpenStreetMap.org seems overly complicated, since there are many different servers involved - much better (and more reproducible) to create your own map using similar software.

(14 Jan '21, 10:13) SomeoneElse ♦

There are 2 more examples in the comments. I don't know one in the UK. Maybe it is possible to search Overpass or something for relations with two ways. But if you will test it at your own map, simply create a way a b c z and a x y z. Then use these two to create a boundary relation. A ghost line b z should emerge. To give a headstart, öpvn map layer seems not to be affected and may have a better rendering algorithm.

(14 Jan '21, 10:37) ghia

Busy right now, maybe next week.

Would report to https://github.com/openstreetmap/osm2pgsql/issues/new

(14 Jan '21, 10:39) ikonor

Ok, I did it already https://github.com/openstreetmap/osm2pgsql/issues/1395 Thanks again!

(14 Jan '21, 11:14) ghia

Deleting a ghost way

Follow this question

Related questions