Gibt es ein Tool, mit dem mal systematisch (!) und automatisiert fehlenden Daten in OSM, die das Routing extrem verschlechtern, finden kann? Hier z.B. ist der straßenbegleitende path nicht an die Querstraße angebunden, was einen irren Umweg (in allen 3 OSM-Routern) verursacht.
Und BITTE nicht gleich draufstürzen und diesen einen Fall fixen, das könnte ich natürlich auch selbst.
Der Umweg wird übrigens nicht wegen der fehlenden Verbindung zur Querstraße erzeugt sondern aufgrund des foot=no auf der L 862. Der rote Abschnitt ist für Fußgänger verboten, also muss der Router solange einen Umweg suchen, bis die Verbindung erlaubt ist.
Woher soll nun ein QS-Tool wissen, ob das foot=no korrekt ist oder nicht? Es wäre ein Abgleich mit “offiziellen” Daten bzw. Referenzdaten notwendig, welche immer zu 100 % stimmen. Solche Daten gibt es nicht. Du könntest dir mit overpass turbo eine Abfrage erstellen, welche die gängigen “Fehler” im Tagging erkennt, aber woher soll nun ein Tool wissen, dass dort eine Verbindung fehlt? Gerade bei straßenbegleitenden Wegen - soll das Tool alle 5cm vorschlagen, dass hier eine Verbindung eingezeichnet werden soll?
Bilderkennung mit KI könnte ein Thema sein, aber die Fehleranfälligkeit ist (noch) viel zu hoch.
Nebenbei: Ist dort wirklich auf allen Bundes-, Landes- und Kreisstraßen ein Fußgängerverbot? Das scheint mir sehr unglaubwürdig, aber ich habe bisher erst selten Urlaub soweit oben gemacht 
Es gibt schon Tools die auf ähnliche Fehler angesetzt sind. Für höherrangige Straßen (bis highway=tertiary) eignet sich die Seite BRouter Suspects gut. Entweder über die Kartenansicht oder über die Länderliste. Die Länderliste kann man auch einfach automatisiert überwachen auf neue Fälle bzw. bei einer Änderung des Inhalts der Seite. Suspects können dabei fehlerhafte Verbindungen, falsche oder unvollständige Turn Restrictions sein oder ungewöhnliche Zugangsbeschränkungen.
Mit dem OSM Inspector lassen sich Routing Islands sowie Unconnected Roads erkennen. Letzteres wäre der Fall wenn ein Weg nicht mit einen naheliegenden Weg verknüpft wurde (engl. “Stub End”)
Mit Osmose lassen sich auch unverbundene Wege erkennen. Auch hier gibt es eine Listenansicht pro Fall, welche sich mit gängigen Tools (bspw. RSS) automatisiert auslesen lässt.
Entschuldige bitte, dass ich so dumme Fragen stelle.
Es geht doch nicht darum, ob das foot=no korrekt ist oder nicht. Und es geht auch nicht um diesen einen Einzelfall.
Bisschen polemisch drauf heute? Natürlich nicht. Das Tool könnte aber vorschlagen, (im Beispiel) den highway service nicht nur mit der secondary, sondern auch mit dem path nebendran zu verbinden. Denn offensichtlich fehlt ja diese Verbindung und solche Fehler machen das Fußgängerrouting kaputt.
Wenn es so ein Tool nicht gibt, würde statt einer ellenlangen Antwort ein einfaches “nein, gibt es nicht” reichen.
OSMI > nix
Osmose > nix
BRouter > nix
Entschuldige bitte den Versuch, etwas ausführlicher meine Sicht zu erklären. Das war nicht angebracht.
Du hast Recht, die Antwort hätte sein müssen: Nein, gibt es nicht.
Sowas ist schwer zu finden… weil was für Regeln müsste man aufstellen um diese Fehlerstellung herauszufiltern…
Ich habe solche Probleme auch schon oft erlebt… und auch gelöst. Das ist ja der Vorteil bei OSM das man das hier selbst fixen kann.
Wie man das findet… mit Routing… viel Routing.
Man könnte nur mal überörtlich Wege suchen… dann schauen wie gut die verbunden sind… und eventuell mit Luftbild da noch Wege zu finden…
Aus diesem Grunde suche ich ja ein Tool dafür, mit dem man regelmäßig und systematisch solche Fehler finden kann. Das über eine eine Routingengine lösen zu wollen, wäre wahrscheinlich schon möglich. Von Adresse zu Adresse routen und wenn die Strecke um einen gewissen Faktor höher ist wie die Luftlinie… Das Problem ist, dass wir keinen Supercomputer zur Verfügung haben, der das in absehbarer Zeit hinbekommt. Nichtmal für Deutschland.
Die Overpass-Abfrage schön, aber nutzlos für diese Problemstellung. Genau die Fehler werden ja nicht angezeigt 
ja… manchmal gibt es aber keine Verbindungen… oder Hindernisse die die Überquerung verhindern… da braucht man dann schon örtliche Kenntnis…
Das mit einer hohen Trefferquote… schwierig…
Betroffen ist Fuß, Rad routing… die auf langen schlecht verbundenen Fuß-/Radwegen routen als Start/Ziel…
Also suchen wir lange Wege die neben meist größeren Wegen laufen…
Update nur lange Wege >50m
https://overpass-turbo.eu/s/1DLa
Hier (https://archive.is/qpgCO) ist es nun archiviert, falls dort später die Stelle verbunden wird…
Der OSM Inspector hat ein Tool (OSM Inspector | Geofabrik Tools) das im Prinzip bei sowas helfen kann, aber nur für Auto-/Rad-Navigation, nicht für Fussgängerrouting. Als das Tool entstand war das wahrscheinlich noch nicht so ein Thema. Aber vielleicht ließe sich das ja erweitern. Ich weiss auch von Firmen/Leuten, die Auswertungen gemacht haben oder machen mit Routing-Engines. Dazu kann man entweder wie oben schon angeregt ganz viele Routen checken und Luftlinie mit Route vergleichen. Oder man schaut, ob sich geroutete Entfernungen deutlich ändern von einem Tag auf den anderen, weil jemand vielleicht einen Fehler eingebaut hat. Da ist aufwändig, aber mit modernen Routing Engines, die tausende Routen in der Sekunde generieren können, gar nicht mal so schlimm, solange man die Gebiete nicht zu gross wählt. Ich weiss aber nicht, ob das bisher nur mit Auto-Routen passiert oder auch für Fussgänger. Und öffentlich sind die meines Wissens nach auch nicht.
Den OSMI hatte ich ja schon probiert, Fußgänger-Routing wird da nicht angeboten. Ich kann mir auch vorstellen, weshalb. Die “Fuß”-Graphen sind um einiges umfangreicher als die “KFZ”-Graphen, sehe ich ja bei uns auch.
Ich rechne auf meinem mittelschweren Rechner (24 Threads, 126 GB RAM, NVME4) so alle halbe Jahre alle PLZ-Centroid - PLZ-Centroid Entfernungen (Deutschland) durch. Das sind bei ca. 8200 PLZ-Zentroiden über 67 Millionen Berechnungen. Das dauert dann schon mal die eine oder andere Stunde. Da kann ich mir vorstellen, wie lange ca. 19 Millionen deutsche Adressen brauchen. Das ist IMHO in endlicher Zeit nicht machbar.
@flohoff hatte auf der State of the Map ein Tool vorgestellt, das in diese Richtung ging. Vielleicht postet er hier wenn er es veröffentlicht. Ansonsten entsprechende Ankündigungen im Auge behalten.
Ich mache etwas anderes - Ich nehme alle Adressen und mache im OSRM ein ->nearest call und gucke wie weit die Addresse von der Straße weg ist.
Das ist ein guter indikator ob jemand durch exzessives access=no/private tagging oder durch nutzung von track oder path die erreichbarkeit der Addresse eingeschränkt hat:
https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.45213,6.83384,13z
Für andere Bundesländer oben auf “Back to database list”
Der Marker ist die Addresse - der faden zeigt auf die Stelle im Routeable network wo dich OSRM hinschicken wird und dir sagt “Sie haben das Ziel erreicht” …
Gibt schöne Fehler da drin. Das zeigt wie notwendig wir sowas wie die navaid relation haben. Jede Fußgängerzone, jeder Schrebergarten mit Addressen, Jeder Campingplatz etc …
Sowas sind dann Highlights - Steht man auf der anderen seite des Kanals “Sie haben das Ziel erreicht” und man kann durchs Fernglas das ziel sehen.
Flo
Ich kenne keines - Das Thema ist auch reichlich komplex und das routing ist ja immer ein “defekt” im Graph der aber auch gewollt sein kann.
Und nur weil etwas nicht angeschlossen ist heisst eben nichts. Auch tagging kann routing zerstören, kaputte turn restrictions, falsche access tags die massiv overblocken.
Ich untersuche nur teilaspekte. Entfernung von Addressen vom Routeable network, temporale änderung der routen in dem ich dieselbe route alle 30 Minuten berechne und gucke ob sie sich verändert.
IMHO ist die temporale änderung + manuelle inspektion das einzige was funktioniert.
Flo
Nein, natürlich nicht. Die vorliegende Straße hab ich per mapillary gecheckt, kein Zeichen 259 zu sehen.
Danke! Immer wieder interessant, dass sich zehn Jahre lang niemand daran stört: Changeset: 15402525 | OpenStreetMap
Joo, ist leider ein Indiz für die mangelnde QS bei OSM.
Ich hab ich mir beim ersten Beispiel gedacht… warum routet er nicht über die Straße… das tagging ist schuld:
*=separate und *=use_sidepath veranlasst einen Router das hier die Straßen nicht zu nutzen werden… Hier müsste überall neben der Straße ein extra Weg gemappt sein… in insgesamt gleicher länge und überall… auch entsprechend verbunden sein… was die Nutzung des tagging problematisch macht… 
Hab da mal die Overpass angepasst… diese fördert auch so nicht richtiges Tagging hervor… (kann man farblich noch erweitern )
Natürlich sollte ein Router bicycle/foot=use_sidepath nicht so streng behandeln wie bicycle/foot=no. Oft sind die Verbindungen Radweg zu einer Einmündung in der Realität etwas versetzt, so dass die Straße ein stückweit genommen werden muss.
