QS Fernwegenetz

Hab heute die Zahl meiner Changesets mehr als verdoppelt…

Anlass war, dass ich beim Test von Auto-Routing immer wieder zufällig auf Connectity-Fehler stosse, und zwar fast immer nach einem simplen Muster:

  • oneway-dead-ends: kurzes falsches oneway-stück zerschneidet eine Fernstrasse

  • no-access-nodes auf Fernstrassen statt wie gewollt für die abzweigende Strasse

Dann hab ich mir gedacht, nach solchen simplen Muster kann man auch mit dem Treibnetz fischen, und tatsächlich hat mein Scanner nur etwa 70% false-positives gebracht, 30% waren also echte Issues.

Das ist soviel, dass ich das erstmal auf das Autobahn- und Bundesstrassen-Netz beschränken musste.

Wenn man da runter geht auf secondary, tertiary, … dann werden das ziemlich viele suspects, und wenn man dann noch über Deutschland hinausgehen will, dann ist das ohne einen spezialisierten Issue-Tracker garnicht mehr machbar.

Jetzt hab’ ich schon angefangen, selbst einen Issue-Tracker dafür zu bauen, was zwar garnicht so abwegig ist, aber irgendwie wahrscheinlich auch Unsinn, weil gibt ja schon solche Issue Tracker (MapRoulette,…)

Ich weiss aber nicht, ob man da automatisch generierte Suspects reinkippen darf, oder ob das manuell bestätige Issues sein müssen. Wer hat Rat und kann mich von der Idee eines spezialisierten Issue-Trackers speziell für diese Connectivity Bugs abbringen?

Danke und Gruss, Arndt

Hallo Arndt,

kannst du mal bitte ein paar Beispiele für die von dir genannten Fehler nennen? Wenn ich wüsste, wonach man suchen müsste, könnte ich die QA-Tools, an denen ich mitarbeite, ggf. erweitern.

Ich denke, dass Martijn van Exel als eine der Personen hinter Maproulette die Frage am Besten beantworten kann. Die Aufgaben in Maproulette sind automatisch erzeugt, jedoch weiß ich nicht, ob sie eine niedrige False-Positive-Quote haben oder nicht.

Viele Grüße

Michael

Im Prinzip reicht für MapRoulette eine GeoJSON.
Wenn das Projekt richtig beschrieben wird, muss der Benutzer false positive erkennen oder Fehler beheben.

Hab’ meinen Poor-Mans tracker jetzt online und kann Dir jetzt über tausend Beispiele nennen:

http://brouter.de:443/brouter/suspects

(Ja, http auf Port 443…)

(Ja ich weiss, die Liste muss eine Karte sein, aber das krieg ich auf die Schnelle nicht hin…)

Die Suchregel hab’ ich jetzt noch verallgemeinert: Jedes “tote Ende” auf einer Fernstrasse (>= secondary) ist ein suspect.

Also immer dann, wenn man auf einer Fernstrasse zu einem Node routen kann, an dem es dann nicht mehr weiter geht. Ob das jetzt durch Einbahnstrassen, Sperrknoten, Abbiegebeschränkungen, echte Sackgassen, Sperrungen an Wegen etc. passiert unterscheide ich nicht mehr.

Als echte Issue sehe ich dann aber nur die, wo tatsächlich das Routing gestört ist. Also wenn der suspect durch eine Unsauberkeit getriggert wurde, z.B. one-way nicht auf dem gesamten betroffenen Abschnitt, dann ist das false-positive, auch wenn man es theoretisch bereinigen könnte.

Da geht natürlich auch die Logik des Routing-Profils ein. Z.B. sperrt bei BRouter ein barrier=lift_gate für Autos auch implizit (ohne access=no). Wenn jetzt jemand einen Bahnübergang so tagged (das tun die!), dann ist die Strasse gesperrt. Oder ich hatte access=military nodes aufder A73 bei Bamberg gefunden, und das stand da seit Jahren. Wahrscheinlich haben andere Router es einfach nicht beachtet.

Aber die meisten Issues sind so verbastelte Einbahn-Strassen oder Abbiege-Beschränkungen. Aber es sind natürlich auch echte, gewollte Sperrungen dabei, dann steht’s ja aber hoffentlich als note in der OSM Datebank.

Mein Poor-Man tracker benutzt jetzt noch den Zwischenstatus “confirmed”. Weil nach meiner Erfahrung sind es zwei getrennte Arbeitsschritte (ggf auch verschiedene Personen)

  • die suspects sichten, um die echten Issues zu finden
  • die echten issue bearbeiten

Drückt man auf “confirmed” bei einem Issue, dann steht das Alter der confirmationin der Liste. Sieht man da also einefrische confirmation, dann kann man davon ausgehen, dass es sich jemand anders gerade anschaut.

Bei “mark as confirmed” und “mark as false-positives” mache ich eine Gegenprüfung, ob tatsächlich für genau dieser Gegend (± paar hunderd Meter) kürzlich mehrere routing requests am BRouter-Web Server ankamen. Damit hoffe ich, dass die false-positives dann auch wirkich stimmen, es sich jemand also wirklich angeschaut hat, also den Kreisel von jeder in jede Richtung geprüft hat.

Ich hab’ die Liste geographisch sortiert (ja, ich weiss, das muss eine Karte sein…) , um es bisscchen einfacher zu machen, gezielt eine Gegend zu bearbeiten. Primär ist das nach 1*1 Grad Quadraten sortiert, und innerhalb der Quadrate dann von west nach ost.

Innerhalb eines solchen Qudrates sind es dann nurnoch wenige Dutzend Issues, also genau die Richtige Menge für einen verregneten Nachmittag…

Maproulette schau ich mir an, vielleicht passt das da rein. Aber ich hab auch OSMSuspects gesehen und auch das Ding von der Geofabrik, das ist ja auch eigentlich genau für sowas gemacht.

Hallo,

ich habe mir die “Fehler” in meiner direkten Umgebung angeschaut und wollte diese als “falsche Fehler” melden. Das funktionierte aber nicht.
Es handelt sich um folgende Straßen / 'Stellen:
1.) http://brouter.de/brouter-web/#zoom=16&lat=48.185&lon=9.52727&layer=OpenStreetMap&lonlats=9.526804,48.181774&profile=car-eco
2a.) http://brouter.de/brouter-web/#zoom=15&lat=48.06765&lon=9.62672&layer=OpenStreetMap&lonlats=9.646019,48.068594&profile=car-eco
2b.) http://brouter.de/brouter-web/#zoom=15&lat=48.06716&lon=9.62406&layer=OpenStreetMap&lonlats=9.615293,48.066405&profile=car-eco

Bei beiden Straßen handelt es sich um Sperrungen wegen Baustellen / Neubau.
Den Stummel der alten B 311 (1.)) habe ich heute noch auf vehicle=destination bzw. vehicle=no gesetzt.

Grüße aus Oberschwaben
Peter

Wird sowas nicht schon durch OSMI abgedeckt?
http://tools.geofabrik.de/osmi/?view=areas&lon=8.95517&lat=48.66815&zoom=11&opacity=0.80&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags

Was ?

Nächste Runde…

weil der osm-planet seit 2 Wochen klemmt, habe ich die Liste der “suspects” (im Sinne von offenen Enden für >= secondary) auf Basis des germany-extracts (geofabrik) refreshed.

Das auf einem extrakt zu rechnen hat den Nachteil, dass dabei zusätzlich offene Enden entstehen an der Grenze des extrakt-polygons. Die liegen aber alle im Ausland.

Also in der folgenden Liste die ausländischen suspects nicht weiter betrachten:

http://brouter.de:443/brouter/suspects

da ist ein Rechteck im Westen Deutschlands (von 48/7 bis 55/10 ) flächendeckend bearbeitet. Der wilde Osten fängt aber schon am 10. Längengrad an. Und im äussersten Süden <48 Grad sind auch noch issues.

Es gab in der Vorgängerliste eine Klasse von Fehlern mit Turn-Restrictions, bei dem das from-Member den via-Node bicht beinhaltet - das war ein Fehler in brouter, weil diese TRs sind ja definitiv kaputt - solche DInger sollten jetzt nicht mehr dabei sein.

Was noch bisschen blöd ist, dass Knoten-Fehler oft 3-mal erscheinen, für den Knoten selbst und die beidern blockierten Wege.

Beim Thema cycle_barrier oder lift_gate auf >=secondary glaube ich mittlerweile auch, dass man diesen Krieg nicht gewinnen kann, ujnd ich die Routing-Regel anpassen muss. Noch sind diese Dinger aber in der Liste.

Also, wer will noch mal, wer hat nich nicht? Mit paar Mitmachern ist die Liste bald leer.

Wie beschrieben ist da eine Abfrage drin, ob vor “mark as false positive” mindestens 5 Routing Requests in der Gegend gemacht wurden. War es das?

Danke an alle Mitkämpfer

o.k. geht besser, jetzt mit der administrativen Grenze für Deutschland gefiltert.

http://brouter.de:443/brouter/suspects

Und auch nurnoch 300 suspects übrig…

Hallo,

Zwei kleine, einfach zu implementierende Usability-Verbesserungsvorschläge hätte ich noch:

  1. Bei den Links zu osm.org kannst du auch einen Marker setzen, hier ein Beispiel: http://www.openstreetmap.org/?mlat=49.86300&mlon=7.80429#map=19/49.86300/7.80429&layers=N

  2. Du könntest einen Link ergänzen, der die Stelle im JOSM (über Remote-Control) öffnet. Das wäre dann z.B. http://osmose.openstreetmap.fr/de/josm_proxy?load_and_zoom?left=8.394656699999999&bottom=48.7741227&right=8.3986567&top=48.778122700000004&select=node1268354443,way111295201
    Den Parameter select kannst du weglassen, wenn du keine Node-ID zur Verfügung hast.

Viele Grüße

Michael

Soll man die nach Korrektur confirmen? Ging da irgendwie nicht … Da habe ich bissele gesucht, bis ich die Ursache fand in einer restriction: no statt only bei straight_on …

Das sieht nach Unfall bei Inspector-Korrektur aus, aber das sollte sich ein chroniklesegewandterer anschauen, was da hingehört …

ja bitte. “mark as confirmed” und dann “mark as fixed”

fuer “mark as a confirmed issue” fordert er nur einen Routing-Request in der Gegend, aber ganz ohne da Routing-Versuche gemacht zu haben, kommt eine Fehlermeldung.

Das soll ein Spamschutz sein, oder auch ein Schutz vor Such-Index-Robotern, die ja theoreitsch bei so einer einfachen HTML-ANwendung alle suspects verschwinden lassen können…

Erledigt ( siehe http://brouter.de:443/brouter/suspects )

Mit JOSM hast Du mich fast erwischt, hab’ JOSM bisher nicht verwendet, aber ich hab’s hingekriegt und es funktioniert tatsächlich mit remote control. Hab versucht, den Zoom ähnlich einzustellen wie in dem BRouter-Web view.

Danke für die Tipps,

Gruss, Arndt

Hi Peter!

Deine 1) ist definitiv ein Fehler!
Wie ich die Situation deute ist die alte B311 einer Umgehung gewichen. Damit vierliert sie aber auch die Eigenschaft als highway=primary! Und das ref=B 311 dürfte auch nicht mehr korrekt sein. Wenn du diese beiden Punkte korrigierst, wird der Fehler auch aus der Liste verschwinden.

Zur 2) hätte ich die Frage, wie lange diese Baustelle existiert, und wer sich um die aktualität der Daten in dem Bereich kümmert!

Viele Grüße,

hsimpson

Zu 1.) Die Ortsumgehung von Unlingen (neue B 311) ist seit einigen Wochen auf einer Teilstrecke in Betrieb. Der Rest soll Mitte kommender Woche fertiggestellt und freigegeben werden. Dann wird auch die alte B 311 auf 3,5 m verschmälert und als Feldweg dienen. Ich werde mir das mal in den nächsten Tagen vor Ort ansehen und danach OSM aktualisieren.
Zu 2.) Die L 280 ist (fast) fertig und soll am kommenden Montag für den Verkehr freigegeben werden. Das schaue ich mit vorraussichtlich am Sonntag mal an.

Grüße aus Oberschwaben
Peter

Geht nicht.
*marking confirmed requires at least 2 recent nearby waypoints from BRouter-Web, found: 0 *

Bei mir gleicher Fehler.

Die Liste ist jetzt erstmal leer (bis auf so einen TR-verkorsten Anschluss in Pirna, der mir zu schwierig ist)

Lessons learned:

BRouter macht bei den access-tags für die Autoprofile eine positive Prüfung (access ?= |yes|permissive|designated|destination )

Das ist deswegen gut, weil ein Routingfehler, der in eine Sackgasse führt als sehr viel schwerwiegender empfunden wird als einer, der einfach nur nicht den besten Weg gefunden hat (und nur darum gehts ja hier in diesem Thread)

Es ist aber auch schwierig, von access=Kraftverkehr, allowed, yes|no|yes, request, etc war alles dabei.

Speziell die falschen lane-taggings (access=yes|no|yes) sind von der Menge her ein echtes Problem.

Die impliziten Sperren speziell bei barrier=lift_gate|cycle_barrier auch.

Ansonsten waren es (nach meiner Fehler-Korrektur in BRouter) nur relativ wenig TR-Fehler.

Relativ viele unvollständig zurueckgebaute Sperren. Irgendwo ein Ministueck wird da übersehen. Ich hab den Eindruck gewonnen, dass die visuelle Prüfung von temporären Sperren ziemlich gut funktioniert. Also wenn da eine Baustelle auf der Karte klar ersichtlich ist, dann ist die auch fast immer richtig. Wenn aber jemand eine Baustelle irgendwo nur funktional abgebildet hat, durch einen Sperrknoten oder eine unsichtbare Wegsperre (z.B. vehicle=no), dann setzt die schnell mal Staub an.

3 Fälle hatte ich, wo Landesstrassen nur für Land- oder Forstwirtschaft freigegeben sind,

In einem Fall war das aus Medienberichten als Sperre wegen Strassenzustand ersichtlich. In zwei Fällen habe ich das korrigiert: Beim Flugplatz Finow und bei der L2055 von Ascherode nach Wulfingerode. Bei letzterem gab’s Protest und Revert. Das Sperr-Schild in Ascherode ist in Mappilary zu sehen, in den Esri-Bildern aber auch mehrere Kfz auf dem angeblichen Feldweg. Und die Kollegen bei Guugel interessieren sich auch nicht für die Sperre. Würde ja gerne mal vorbeifahren um das zu verstehen…

Der Scanner läuft jetzt cron-gesteuert immer Sonntag morgens auf dem Geofabrik-Gemrnay-Extrakt, der eine erstaunlich kurze Latenz zu haben scheint. So kann man relativ zeitnah noch Korrekturen machen, bevor am Montag Morgen der Snapshot für den Planet-Dump gemacht wird (der dann Donnerstags bei BRouter ankommt).

PS: @geofabrik: ihr habt bestimmt auch einen Planet-Dump mit kürzerer Latenz und weniger Störungen als den offiziellen :slight_smile:

was aber wohl nur heisst, dass dieses Sieb dafür nicht geeignet ist.

Hab’ einen anderen Test gebaut, der nach TR-Fehlern fischen soll. Was er tatsächlich macht ist, die TRs zu suchen, die tatsächlich eine Wirkung haben. Dass sind natürlich die guten. Aber keine Wirkung ohne Nebenwirkung, also vermutet man in dieser Liste eben auch die Fehler.

Allerdings muss man viele Kreuzungen testen, um einen Fehler zu finden, die false-positive-Rate ist also ziemlich hoch (>95%)

Was man aber dann findet ist sowas hier (die hab ich aber alle schon bearbeitet!):

http://brouter.de/brouter-web/#zoom=18&lat=50.314299&lon=8.408588&layer=OpenStreetMap&lonlats=8.408173,50.313486|8.408398,50.31501&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=16&lat=50.21639&lon=8.86644&layer=OpenStreetMap&lonlats=8.868713,50.218491|8.868327,50.213904&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=17&lat=49.559596&lon=8.84601&layer=OpenStreetMap&lonlats=8.846676,49.559119|8.846945,49.561444&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=16&lat=51.64897&lon=8.71043&layer=OpenStreetMap&lonlats=8.717759,51.64564|8.720012,51.651924&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=17&lat=51.741011&lon=8.73222&layer=OpenStreetMap&lonlats=8.730805,51.739194|8.73471,51.740125&nogos=&alternativeidx=0&format=geojson&profile=car-eco

Nicht immer ist die angezeigte TR dann auch der Fehler. Gibt da auch komplexere Wechselwirkungen.

hab diese Liste der TR-Kanditaten jetzt einfach mal in die “suspect” Liste eingespeist, auch wenn der Name “suapect” hier eigentlich nicht passt. Sollte eher heissen: “wirksame TR, die es sich lohnt zu testen”

Zurück zu den Sackgassen-Fehlern, jetzt mit mehr Länder-Poygonen, und mit einer “Max-Prio Logik”

http://brouter.de:443/brouter/suspects

Die funktioniert so: solange es noch suspects gibt bzgl. motorway, dann werden nur diese angezeigt.

Dann trunk, dann primary … bis runter zu tertiary.

Die Liste für Deutschland ist zwar eigentlich leer, aber jetzt werden tertiary-suspects angezeigt. MAcht aber nicht wirklich SPass, die durchzuschauen, weil da ist die false-positive Rate viel höher als bei secondary.

Ich werde die Länder-Liste noch ergänzen - mich aber nicht inhaltlich mit den !=germany suspects beschäftigen.

Die Prüfung auf Routing-Versuche in BRouter-Web als Vorraussetzung für die Markierung als false-positive und confirmed habe ich beibehalten, auch wenn es hier mehrere Nachfragen gab, die zeigten, dass das nicht immer verständlich ist. Es ist einfach ein gewisser Aufwand, siede suspects zu gewinnen, also muss es auch ein gewisser Aufwand sein, sie weg-zu-kicken. Denn eine false-positive-Markierung bleibt für immer stehen, da sollte die Stelle eben auch wirkich geprüft sein.