Do we have tools for detecting new gaps in major roads?

For example in Poland motorway was broken for 2 months.

Is there any already existing tool detecting such changes? Or motorways leading nowhere?

Without listing thousands of other lower-priority issues listed as the same priority?

Ideally - is there RSS or some ability to subscribe for other notifications?

5 Likes

I can’t look at the linked issue right now, but doesn’t Osmose have a similar check?
item 1210
class 2

Hi Mateusz,

do you mean almost unconnected roads (gaps of less than 10 m) or dead-end major roads (sinks and sources)? The first case (unconnected) should be handled by OSM Inspector Routing View.

Best regards

Michael

2 Likes

I am running QA for Routing but on a very low scale - Parts of Germany. Basically i am running OSRM every couple of hours and process routes between a given (manual) set of nodes. I then compare differences over time - So when travel time in-/decreases i get mails. So i detect broken roads within a couple of hours.

I do that by “city” level. Setting nodes on the urban entry on the neighbouring city. I calculate routes by “cluster”. I maintain the nodes via QGIS in a postgis database which also holds the route geometries from OSRM over time. (I basically store the whole json response + a linestring)

I do have clusters for parts of the Motorway A2, A44, A33, A30 and parts of Primarys B64, B66, B55, B61

I then get mails like this:


Subject: Salzkotten Route: Verne Hauptstraße->B1 - Fr Paderborn changed

Route compare: https://osm.zz.de/routeqa/?rid=410254,440466

Old route: 8721.3m (587.4s)
New route: 8951.5m (647.0s)

The resulting links shows old and new route as a comparison:

https://osm.zz.de/routeqa/?rid=410254,440466

Here somebody put in a broken turn restriction.

I could potentially write some documentation on how to set this up. I was also thinking how to make this more “user friendly” but letting people put in points themselves, and let people subscribe to route changes to certain points.

Currently all these mails go to a mailinglist where people interested may subscribe. Sometimes its a lot. So somebody breaks a motorway and you get like 150-200 mails (Per route) - I am in the process of bringing this down to a mail per cluster and run which also contains more information on where to look for a problem/change.

(If times decrease its on the new route, if time decreases its on the old route etc)

So this is basically a part of the grid i am monitoring. (Screenshot from QGIS)

Flo

8 Likes

Did you checked the BRouter Suspects for Poland?
https://brouter.de/brouter/suspects/Poland/all

It’s also possible to dive deeper with sub-regions.

It will detect almost every routing issue like construction, access issues, barriers, wrong TRs, wrong one-way…
And the suspects are prioritized by highway class. For Poland, first motorways are listed, after you cleaned the list, primary will shown. And so on down to tertiary.

There is also a map linked here:
https://brouter.de/brouter/suspect_manager_help.html

1 Like

I want to detect also new large gaps (say, someone deleting 5km of motorway)

I thought exactly about something like this

Yes, and I have absolutely no idea what specifically is detected as bad data there. I looked at multiple reports and not even in one case I able to found mistake or detect what triggered report

1 Like

In my experience (since 2013 i am running this QA) “gaps” are not a problem or a pretty rare one. We had the discussion 10 years back that “the only thing missing for routing in OSM is turn restrictions” so people started to sprinkle turn restrictions EVERYWHERE and they are hard to make in editors so they tend to go wrong a lot of times.

I see these issues:

  • reverse oneways in long stretches of roads. Splitting roads for a bridge and then accidentially reversing it. Happens a lot less since josm has a popup in case of directional tags.
  • turn restrictions “only_*” is the ONLY way you can traverse - direction e.g “_left”, “_right” “_straight” does not matter. Its not a geometry issue. The “to” object is the only to be able to travel to. Mappers tend to not understand this.
  • Left over access tags from construction works (access=no, highway=construction, construction=*) any one of them prohibits osrm use that road. This is a hard to detect process issue. So i ALWAYS put a note on the stretches of road “To be checked regularly”
  • With the latest StreetComplete additions or ARCore (Augumented Reality Street Width measurements) i saw streets width=1.6m so streets are “impassable” for car profile in OSRM. Issue open. IIRC Security popup is coming.
  • Excessive “access=private” spill onto all kinds of roads.
  • Misuse and misunderstanding of access tags. (access=no, car=yes on roads and the like)
4 Likes

Disclaimer: They are only “suspects” and not every issue is also an error. Arndt writes this quite well on the help page. Each detection can be marked as false-positive, so that it does not appear again.
Edit: Here is a more technical description of the tests: http://brouter.de/brouter/suspect_scanning_readme.txt

I have just clicked one:
There is a turn-restriction where the members are not connected to the via node. The from member is the distant curve in the north.

Here is a turn-restriction relation with only one member. Not a fatal error, but probably the members were deleted here and one would have to repair the TR.

These are all not gross errors but hints. But the gap you describe should actually be displayed there as “dead-end” as well as “dead-start”. This is usually the case in Austria.

Otherwise, you could probably also run an atlas check for Poland. See atlas-checks/roadLinkCheck.md at dev · osmlab/atlas-checks · GitHub or atlas-checks/tutorial3-SinkIslandCheck.md at dev · osmlab/atlas-checks · GitHub

2 Likes

Those turn restrictions will basically be ignored. Which may result in a “non optimal” route but most turn restrictions are obsolete anyway as the only restrict rare taken interconnects.

Turn restrictions break when from, via, to are set - and the restriction is “only_straight_on” and the to is the “left leading road”.

Kaboom.

People tend to not see this. And for them “only_straight_on” is a geometric issue/command whereas OSM interprets only “only_*” + “to”. Geometry is a non issue here.

Flo

Are ignored by whom? By users or BRouter suspects? In the case of the latter, they are displayed. And I also try to fix them (at least within Austria).
But I agree with you. Turn restrictions are not easy to maintain and require a certain amount of knowledge.

Incomplete turn restrictions can not be evaluated to change routing. So when an element is missing is basically non existant.

Flo

1 Like

I’d add to @flohoff’s excellent list that barrier breakages are moderately common. Sometimes people will put (say) a stile, which should be on a highway=footway, on the junction between the road and the footway. Or they might make up a new barrier=something_entirely_new which can confuse routers (the default OSRM profile was broken in London for a couple of years because of this).

2 Likes

Barrier breakage happens for me mostly for bicycle routing. People tend to map lowered sidewalk kerbs as “barrier=kerb” - This cycleway/paths are not usable by bicycle anymore.

Flo

Yep - cycle.travel only filters known barrier types for exactly that reason.

1 Like