Google sued over collapsed bridge death

All I know is there is the river, and now it has magically grown a perfect looking bridge as one zooms out.

I didn’t think of „the“ river here, but all rivers on OSM Carto, which disappear depending on the zoom level.

So who in the real world uses OSM Carto to plan and navigate routes? There’s a gap in the way, there is now the noexit tags on the dead end stubs I hope (If the ends are closer than 15 meters Osmose/OSMI will whine there’s unconnected ways needing fixing or noexit tagging), If the banks are steep, add a cliff, no 3rd party router would ever jump the river, is that not the function of the router in/on your vehicle?

3 Likes

The map style is for eyeballs. Some of us still look at maps. The maps should not create a bridge across a river, like some divine act.

2 Likes

Hopefully you’re keeping the eyes on the road after eyeballing your route on a zoom level that might simplify some geometry.

It’s perhaps worth mentioning that the OSM “standard” map tiles never did this for me - even when I zoomed right in on a z14 or z15 tile, there was always a “clear blue gap” (even before this changeset moved the road ends further apart). This is different from your exmple above - I can only assume that I was looking at a different render server to you.

When I first followed the link posted above to the very location, the casing of the residential roads on either side did not show any interruption at location of the demolished bridge. Not, browsing there again, looked the same, a continuous line. I had to shift-reload, bypassing browser cache, to see them separate. @Mateusz_Konieczny Perhaps, if butt-ends overlap, casing is dropped, regardless of lines joined or not?

From technical point of view, in this case, casing is drawn by drawing slightly wider, darker line, then drawing another line that is slightly smaller.

So yes, if lines are close to each other (on the same road where it is desirable, on close but not linked road where it leads to poor display) then casing will be missing.

That’s what I do sometimes when we are on trip. I don’t set route on the application, I just look at the map and judge by the appearance the suitable route, on last moment :stuck_out_tongue:. Of course another person drives. It feels like WRC sometimes :stuck_out_tongue:

Seems like we need a donor of about 640 acres of land as a
test bed for various rendering tests, on real live OSM website render
servers
 The whole thing real except for the actual groves in the
ground, which would be various widths of canals and bridges and golf
courses and anything else people need to test with the actual live
chain
 Hmmm, in a corner could be a date etched into a cornfield
with the current date or something. The donor idea is a farmer who
wouldn’t mind their land looking odd on the map.

Anyway, then “do you see what I see” could be better pinned down,
even beyond what screenshots can achieve. Also maybe rendering engines
could leave a watermark or something in the tiles they make,
helping track down those that are running older versions, even if
no HTTP log was made, and all that is left is a screenshot (not even a tile.)

Also note my above screenshot: I zoomed the map way out, and blew up the screenshot way up (I forgot the details), “to reveal the truth.”

Managed to get a screenshot with the new tracestack layer, that is based on Carto and not refreshed yet - this at Z15; right side magnified ×3.

Casing-overlaps

A hard problem indeed to fix in the renderer. Likely needs tagging support.

1 Like

It’s pretty straightforward to set up a rendering server to exactly match what you see on osm.org’s “standard” map and load it with fake data. The parts of the osm.org infrastructure that you wouldn’t see are (a) the effect of the CDN on cache and (b) the tile dirtying algorithm (the osm.org one is somewhat custom and something of a “lighter touch” than e.g. what you get out of the box with a modern osm2pgsql). You’ll see all the effects discussed above though, including the cache effects.

If you look at the issues in the OSM Carto repository you’ll see people doing this all the time.

In case it isn’t clear from what @Mateusz_Konieczny and others have said previously, @Hungerburg’s post above makes it even more obvious - the road fill is drawn above the road casing - which absolutely is something that you’d normally want to happen - you’ll get all sorts of rendering anomalies** otherwise.

To reiterate a point from above, if you are just “looking at a map” with an online map and not explicitly checking routing you are Doing It Wrong. No single on-paper or on-screen representation can show all of the intricacies of what may be recorded in OSM at a particular location.

** if you tinker with line-cap and line-join effects in OSM Carto you can mediate that to some extent, but you do get some oddities. A map style that I look after does just that, and you can see an example of such an oddity here.

I would expect that even with some extra tagging it requires changes in software.

Note similar case: parallel road close to each other and not joining. (it may be dual carriageway, it may be not a dual carriageway, it may be case of curves on steep ascending road)

Though in theory one can represent topology by intentionally departing from geometry matching actual roads. For example, by depicting gap between roads as larger than in reality and making it noticeable on map.

Well done maps are not obligated to be accurate representation of geometries. But doing it automatically is horrifically hard. Even doing it manually is not easy at all.

1 Like

Roads and waterways are often depicted different than reality aren’t they? I know Dutch polders with lots of small waterways between meadows are depicted overly green at high zoom levels and overly blue at lower zoomlevels. And roads on dykes often overlap the embankment lines until I zoom in far enough.

I guess two roads ending at both sides of a waterway, without connection, could be rendered as not interrupting the water. I see tunnel entrances rendered, so I can imagine rendering a road’s end in some way. As long as the water is rendered, the water should be rendered between the road’s ends.
Maybe some end-of-the-road tag could help, but I think a tag would not add information to the geometry already present.

yes, but depicting road line as larger than road would be at given scale is easy

rearranging geometry to show topology rather than geometry, without catastrophic damage to geometry, is really hard

It would not, identifying ends of roads is an easy part.

Note that it is only one case - they can be split by rail, trench, no access section and so on.

And even water case is tricky to achieve.

I was thinking of tagging the demolished bridge as a kind of barrier, pondering the case, maybe mapping the barriers erected on either side might be good enough - still, if vandals removed them from the site, would that make the mapper removing them from the data a vandal too or an acute mapper?

I think it would be the mapper’s responsibility – and our responsibility collectively – to ensure that routers continue to recognize that the road is impassable. There are other ways to prevent automatic routing along a road, such as leaving a gap, marking as no access, etc. I would only characterize it as vandalism if the mapper intentionally avoided adding this alternative detail in order to cause mischief – a sin of omission, so to speak.

If we’re at a loss for how to describe an obstacle, routers such as OSRM will even avoid passing a bare node tagged with access=no and nothing else, though combining it with barrier=yes would be less surprising to other mappers. (Fun fact: Tagging a way with maxspeed=0 mph has the same effect, by making it take infinitely longer to take that road than some other road.)

1 Like
  1. mapper mapping accurate state would leave gap in road as bridge is gone, so routing would be still valid

  2. there would be tiny chance that someone would not be mislead by presence of nonexisting barriers being mapped

  3. I would also notify local authorities about dangerous road location

Such dilemma may exist, but this case seems clear. Not sure how accurate mapping would make things worse here.

Managed to get a screenshot with the new tracestack layer, that is based on Carto and not refreshed

Well all I know is my z=15 screenshot above showed it much worse, indeed like
a normal looking bridge,

20230927T042930

and the houses are already showing, meaning that any old caches weren’t
that old.

I wonder if a judge in a court of law would accept that


But then why did Google rip out the road entirely?

Certainly in the UK people who had tried to “blame the satnav” have been prosecuted. See also here.

1 Like