Kritische Tester für den neuen OSMI-Routing-View gesucht

Hallo,

Ich kontrollierte bis vor kurzem beinahe täglich die Unconnected mayor roads <1m im westlichen Europa und mehr, welche praktisch immer true positive’s waren und sich schnell fixen liessen. Diese Fehler-Kategorie hat meiner Meinung nach einen grossen Impact auf die Routingqualität, weshalb ich es motiviert zu verbessern versuchte.

Seit dem Stoppen der Datenaktualisierung des “alten” Routing-Views, gab ich dem neuen Routing-View eine Chance und konzentrierte mich auf die Unconnected nodes (urgent/very high likely errors). Leider bin ich sehr entäuscht. Neben den vernachlässigbaren false positives durch vermutlich alte Daten, gab es sehr viele andere Dinge, die für einen false positive sorgten oder für einen Sesselmapper nicht zu fixen waren. Alles in allem eine jeweils kleine Ausbeute an gefixten Fehlern. Noch dazu kann man nicht mehr so weit herauszoomen, was für eine schlechtere Übersicht sorgt.

Schade um die gut funktionierende alte Lösung. Falls die Rechenleistung nicht reichen sollte, könnte man meiner Meinung nach einfach mal die höheren Distanzen weglassen oder die Daten nur noch alle x Tage aktualisieren.

Vielleicht bessert es sich noch, aber im jetzigen Zustand werde ich vermutlich in Zukunft die Zeit für effizientere QA’s einsetzen.

Just my two cents… trotzdem Danke für Eure Arbeit!

Hallo,

Ich habe jetzt eine Sonderregel eingebaut (Effekt ab dem nächsten Datenupdate sichtbar), bei die Distanzen bis 1 m den Fehler bis zu 2 Relevanzstufen hochstuft (z.B. Parkplatzweg und Fußweg von eigentlich 4 auf 2), bei Distanzen bis 2 m eine Stufe.

Die False Positives, die durch Baustellen kommen, werden mit dem nächsten Update verschwinden, weil Baustellen dann als befahrebare Straßen gelten.

Nichtsesselmapper dürfen den neuen Routing-View als Anregung verstehen, wo etwas Mikromapping in Form von Zäunen und Mauern nützlich wäre. Damit lässt sich sicherlich der ein oder andere Fehler in den Kategorien 4 oder 5 beseitigen.

Ich habe bei den beiden wichtigsten Kategorien die Mindestzoomstufe etwas abgesenkt. Ganz absenken kann ich sie nicht, weil irgendwann auch die Performance zuschlägt.

Viele Grüße

Michael

Danke! Werde es mir gerne anschauen…

Wo ist bei folgendem der Fehler?:
https://tools.geofabrik.de/osmi/?view=routing_beta&lon=9.48424&lat=47.65094&zoom=18&overlays=unconnected_open_ends_1

Strasse zu Fähr-Route gibt es an einigen Stellen.

Hi,
ich hab noch einen Bug: dieses ist eine (L-förmige) Hecke die der direkten Verbindung m.E. im Weg steht, der entsprechende False Positive.
Viele Grüße!

…oder ist das der “Kesselschmid”-Bug den du oben schon gefixt hast (fürs nächste Update)?

Hallo,

der neue Routing-View ist jetzt im Produktivbetrieb (siehe dazu auch unseren Blog) und erhält täglich Updates (Datenstand gegen 20:00 Uhr, die Verarbeitung ist am Morgen darauf fertig).

Hinzugekommen sind jetzt noch zwei Layer zu “Duplicated Edges”. Der eine enthält nur Fälle, bei denen keine Flächen involviert sind, der andere die Fälle, bei denen mindestens eine Kante zu einer Fläche gehört. Das sind v.a. Fußgängerzonen, die sich die Nodes mit einer Straße teilen. Da dieses Thema meiner Meinung nach nicht endgültig ausdiskutiert ist (das bitte in einem separaten Thread tun, danke), habe ich ihnen einen separaten Layer und eine höhere Mindestzoomstufe spendiert. Im Regelfall sind die Fälle, bei denen keine Flächen involviert sind, echte Fehler und bedürfen einer Behebung.

Bei der Auswertung von layer-Tags hatte sich ein Bug eingeschlichen, der jetzt behoben ist.

Viele Grüße

Michael

Diesen Hinweis http://tools.geofabrik.de/osmi/?view=routing&lon=9.60891&lat=48.06649&zoom=18&opacity=0.37&overlays=islands_car verstehe ich nicht.

Straße: https://www.openstreetmap.org/way/496486992#map=19/48.06657/9.60875
Schranke: https://www.openstreetmap.org/node/4881883519

Was ist da falsch?

Fragende Grüße

Vielleicht kann OSMI mit “motor_vehicle” oder “customers” nicht umgehen.

“customers” wird als Wert von GraphHopper nicht unterstützt. Lesenswert zu dem Thema ist die Diskussion des folgenden Pull-Requests: https://github.com/graphhopper/graphhopper/pull/1272

Hi,

ich hab hier noch was: http://tools.geofabrik.de/osmi/?view=routing&lon=9.71270&lat=52.39711&zoom=18&opacity=0.74&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3 . Da wird auf eine bridge=yes gesnappt, von einem nicht-bridge-way.
Ist da das Tagging falsch, d.h. muss die Brücke zwingend layer=1 kriegen, auch wenn darunter nichts gemappt ist (da ist Firmengelände), oder ist es ein false positive?

Gleiche Art hier http://tools.geofabrik.de/osmi/?view=routing&lon=9.68416&lat=52.39205&zoom=18&opacity=0.74&overlays=snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3 bei tunnel=yes ohne level/layer. Da im konkreten Fall tendiere ich aber zum Setzen von layer-Tags, weil es oben ein Parkdeck und darunter irgendwas anderes (ggf. auch Parkdeck, muss ich OTG vorbei). Trotzdem bleibt das grundlegende Problem bestehen.

Die OSMI-Meldung ist aber gut, um solche Taggingprobleme zu finden, auch wenn man nach reiflicher Überlegung zum Schluss kommt, das alles OK getaggt ist. Wenn wir aber die Tendenz der Mapper betrachten, das QS-Tool leer zu machen (hätte ich vorher auch nicht erwartet, ich dachte die Leute seien verantwortungsvoller), dann muss man sich eben sicher sein, das das vom Tool bemängelte tagging auch unerwünscht (soweit man das bei OSM sagen kann) ist.

Vielleicht sollte man diese OSMI-Fehler soweit abstufen, das sie nicht mehr rot sind?

Viele Grüße!

Hallo,

Es ist ein False Positive. Hätte die Brücke layer=1, würde keine Meldung erscheinen. Da unter der Brücke aber keine Straße in OSM gibt, ist das Tag momentan unnötig. Du kannst die Meldung loswerden, indem du hinter dem Tor noch ein Stück Straße mappst. :slight_smile:

Ich habe entschieden, bridge=yes und tunnel=yes nicht als layer-Ersatz bei fehlendem layer-Tag zu verwenden, damit diese gesetzt werden.

Dann müsste ich noch ein Bit mehr pro Kante speichern (ob die Layer-Angabe implizit oder explizit ist), das ich aber nicht kann, weil ich dann von 32 auf 64 Bit pro Kante wechseln müsste.

Gegen unsorgfältig arbeitende Mapper ist kein Kraut gewachsen. Da hilft nur An-/Ermahnen und Aufklären. Im Zweifelsfall bekommt der OSMI einen Splashscreen, der die Benutzer zu verantwortungsvoller Nutzung auffordert.

Viele Grüße

Michael

Bei näherer Ansicht der aktuellen Mapillary-Bilder stellte sich raus, das es ein Förderband/Rohrbrücke und keine Fußgängerbrücke ist. https://pewu.github.io/osm-history/#/way/193286983 . Gefixt.

Ja, mal sehen wieviele Probleme durch den verbesserten Routing-View auftreten. Man könnte ja mal diese taghistory-Graphen nach noexit=yes auswerten und gucken obs nen Sprung gibt.

Was soll hier http://tools.geofabrik.de/osmi/?view=routing&lon=9.45822&lat=48.16999&zoom=18&opacity=0.34&overlays=islands,islands_car,islands_bicycle,islands_all falsch sein?

Es sind keine Access-Merkmale eingetragen. Bei den monierten Tracks fehlt lediglich das Merkmal tracktype, während bei den anschließenden Tracks das Merkmal tracktype vorhanden ist.
https://www.openstreetmap.org/way/208440362/history
https://www.openstreetmap.org/way/208440347/history
https://www.openstreetmap.org/way/619860976/history
https://www.openstreetmap.org/way/30882574/history

Führt hier das fehlende Merkmal tracktype zu einem Routing-Hinweis?

Bei GraphHopper sind nur highway=track mit tracktype=grade1/grade2/grade3 oder ohne tracktype=* befahrbar. Da die Feldwege nur über grade4-Wege erreichbar sind, gibt es keine Kante im Graphen, die die betreffenden Kanten mit anderen Kanten verbindet. Falsch würde ich das Mapping nicht nennen, nur unvollständig.

Mit der vorhergehenden Version konnte ich schnell alle ‘major unconnected highways <1m’ flicken und das Europaweit, was wie gesagt meines Erachtens einen grossen Nutzen fürs Routing mit sich bringt. Leider ist dies jetzt überhaupt nicht mehr möglich. Wenn man bei den Urgent schaut, hat es einen riesigen Überfluss mit vielen false positives. Schade.

Gibt es nachwievor keine Möglichkeit, den ‘major unconnected highways <1m’ von früher irgendwie vernünftig abzubilden?

Hallo,

Ich habe nach deinem Hinweis alle Fälle mit einer Distanz kleiner als 1 Meter pauschal um 2 Stufen hochgestuft und alle mit einer Distanz kleiner 2 Meter um eine Stufe hochgestuft. Da sind eine ganze Reihe kleiner Straßen und Wege aufgetaucht, die echte Fehler sind und auch einer Korrektur bedürfen. Es sind oft die Fälle, die zwar nicht wirklich weh tun, da die Umwege gering sind, die dennoch nicht gut für OSM sind. Ich gebe zu, dass da auch False Positives dabei sind. Dabei handelt es sich jedoch meist um Fälle, wo man das Tagging verbessern sollte, z.B. fehlende layer=*-Tags ergänzen.

Ein Großteil des Straßennetzes ändert sich sowie nicht so oft in OSM. Wenn man die Fälle in der wichtigsten Kategorie einmal durchgeht, sollten danach das regelmäßige Putzen mit geringerem Aufwand von statten gehen.

Viele Grüße

Michael

Du redest Dich um Kopf und Kragen…

Jeder Fall, wo jemand die OSM Datenbank als False Positive Datenbank missbraucht ist ein Unfall. Bei dem no_exit Thema wolltest Du es ja auch nicht schönreden.

Immer besser die Tools den Prozessen anzupassen als andersrum

Hallo,

ich bin heute Morgen mal die Meldungen der höchsten Stufe im Gebiet zwischen Karlsruhe, Calw, Stuttgart und Heilbronn durchgegangen:

Node-ID Kommentar
899149705 Parkplatzweg, eher False Positive, Ortskenntnis erforderlich
2906708408 False Positive, public_transport=platform nicht unterstützt
1149201078 Fehler, aber nur mit Ortskenntnis lösbar (1,7 m)
310695040 Parkplatzweg, eher False Positive, Ortskenntnis erforderlich
6389167376 und 6389166966 Parkplatzweg mehrgeschossig, bedürfte besonderer Behandlung
4232101829 Waldweg nicht mit Landstraße verbunden
6439633354 Fußweg nicht mit Wohnstraße verbunden
5171763081 Treppe ins Nichts, ggf. Böschung mappen
6486636881 Treppe ins Nichts, Ortskenntnis erforderlich
618649416 Tiefgarageneinfahrt als amenity=parking statt amenity=parking_entrance, Ortskenntnis erforderlich
6138667060 sich überkreuzende Wege, von denen einer kurz danach endet; Mappingfehler, Änderungssatz kommentiert
3760440237 Zufahrt nicht mit Hauptstraße verbunden, vermutlich Überbleibsel von Straßenumbauarbeiten, korrigiert
3864632473 Multipolygon-False-Positive
3036982158 Fußweg kreuzt Rand des Bahnsteigs ohne gemeinsamen Node, korrigiert
2454642884 In einer früheren Version (vor Änderungssatz 62325737) hatte der Parkplatzweg schon fast die Form einer liegenden Sechs. Seitdem hat sich der Abstand vergrößert, sodass der Mappingfehler aus grauer Vorzeit nicht mehr so auffällig war. Korrigiert.
2326711353 offenes Ende eines Zufahrtsweges, nur mit Ortskenntnis korrigierbar
5895650600 offenes Ende eines linienförmigen Bussteigs, False Positive (man könnte es mit Ortskenntnis aber auch besser mappen)
4023857685 Minifußweg, der an public_transport=platform endet, welches nicht im Routinggraphen enthalten ist, False Positive (man könnte es mit Ortskenntnis aber auch besser mappen)
1454717988 unverbundener Bahnsteigzugang, offensichtlicher Mappingfehler, korrigiert
3755136516 offenes Ende eines linienförmigen Bahnsteigs einer Standseilbahn
1659738189 offenes, unverbundenes Ende eines linienförmigen Bahnsteigs einer Straßenbahnhaltestelle
2300170114 Zugangstreppe zu einer Wasserrutsche in einem Freibad (echter False Positive)
847581096 unverbundene Fußwege (3 cm Abstand), korrigiert
4980707534 unverbundene Fußwege (51 cm Abstand), korrigiert
3814717350 offenes Ende eines linienförmigen Bahnsteigs, verbesserungswürdiges Fußwegmapping an der Haltestelle mit meiner Ortskenntnis verbessert
6280833513 Wege nicht verbunden, Abstand 0 cm, korrigiert
4810448930 Zufahrtsweg nicht mit Straße verbunden, korrigiert
28839254 Parkplatzweg endet an der Rückseite eines Bahnsteigs, Ortskenntnis erforderlich
4870555626 Zugangsrampe zu einem Gebäude, die im Nichts endet, Ortskenntnis erforderlich

Ich habe aufgrund dieser Erfahrungen alle Fälle, bei denen unwichtige Straßen (service=driveway, service=parking_aisle, footway, path, cycleway, platform) weniger als 2 Meter von einer anderen Straße entfernt sind, aus der höchsten Kategorie in die zweithöchste verbannt. Die Änderungen kommen mit dem nächsten Durchlauf heute Nacht zum Tragen.

Viele Grüße

Michael

Sehr gut. Danke dir! Mit dieser Änderung reift es förmlich wieder zu einem brauchbaren Tool heran. Super!

Hallo,
für diese Linie https://www.openstreetmap.org/way/703449680/history wird im OSM-Inspector View Routing ein Hinweis no_feature_tag_ways angezeigt:
http://tools.geofabrik.de/osmi/?view=tagging&lon=9.80048&lat=48.03928&zoom=18&opacity=0.34&overlays=no_feature_tag_nodes,no_feature_tag_ways

Warum?
Müssen - abgesehen von removed:highway=* - alle anderen Merkmale raus?