OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#26 2019-05-15 10:12:42

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

der OSMI zeigt jetzt auch Routinginseln für Radfahrer und Pkws an. http://tools.geofabrik.de/osmi/?view=ro … slands_all

Bei Fahrrädern und Pkw werden Access-Beschränkungen ausgewertet. Beim Layer für alle Fahrzeuge passiert das nicht, dort werden nur gänzlich unverbundene Straßen ausgegeben. Daher erlauben der Fahrrad- und Pkw-Layer einen Blick in die Access-Logik von GraphHopper.

Ein großer Teil der Fahrrad-Inseln in Städten kommt daher, dass GraphHopper highway/public_transport=platform nicht akzeptiert. Dazu gibt es (unabhängig von meinen Aktivitäten) ein Pull-Request, das solche als Schiebestrecken einstufen möchte.

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#27 2019-05-15 14:14:56

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

Hi Nakaner,

unter dem OSMI steht "Data from 2019-05-06 22:58 (UTC)". Das stimmt nicht, oder?

Die Anzeige der Inseln find ich auch gut, allerdings machen die Bahnhaltestellen doch viel false positives. Kannst Du die ausschließen oder den Patch in deine Graphhopper-Instanz reinpatchen? Oder sollen wir einfach abwarten bis GH upstream den pull request approved (Denglisch level 11 ;-) )?



Viele Grüße,
gormo


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#28 2019-05-15 16:12:34

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

gormo wrote:

unter dem OSMI steht "Data from 2019-05-06 22:58 (UTC)". Das stimmt nicht, oder?

Ganz genau sagen, wann der aktuelle Datenstand ist, kann ich nicht, weil das Planetfile, aus dem ich das erzeugt habe (Job gestern gegen 18:30 MESZ gestartet), jeden Tag aktualisiert wird. Ein geschätztes Datum habe ich jetzt eingetragen.

gormo wrote:

Die Anzeige der Inseln find ich auch gut, allerdings machen die Bahnhaltestellen doch viel false positives. Kannst Du die ausschließen oder den Patch in deine Graphhopper-Instanz reinpatchen? Oder sollen wir einfach abwarten bis GH upstream den pull request approved (Denglisch level 11 ;-) )?

Ich würde gerne abwarten, bis die Änderungen upstream akzeptiert sind. Danach muss ich dann den aktuellen GraphHopper wieder mit meinem Fork zusammenführen (der ist kein 3-Zeilen-Patch mehr).

Ich möchte bei den Routingprofilen, so weit es geht, beim Original bleiben.

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#29 2019-05-17 11:01:27

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

Hi,

ich hab noch einen false positive: Bergstraße matcht mit Tunnel untendrunter: http://tools.geofabrik.de/osmi/?view=ro … pen_ends_6 .

...und bei Brücken auch: http://tools.geofabrik.de/osmi/?view=ro … pen_ends_6

Viele Grüße,
gormo

Last edited by gormo (2019-05-17 11:06:29)


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#30 2019-05-17 11:30:24

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

Nakaner wrote:
gormo wrote:

Mir ist allerdings ein "leeres" QA tool auch nicht wichtig. Wenn ich da permanent 10 Marker sehe, von denen ich aber weiß das ich sie ignorieren kann weils false positive ist, dann ignorier ich die. Ob das alle so machen, d.h. ob man das nötige Augenmaß bei Mappern vorraussetzen kann kann ich nicht beurteilen.

Ich fürchte, dass es selbst unter den Nutzern des OSM Inspectors, die i.d.R. keine unkundigen Anfänger sind, sicherlich zu viele sind, um den OSM Inspector mit False Positives zuzumüllen. Es dürfte genug Nutzer geben, die ein Bedürfnis haben, die Karte ihrer Gegend weiß zu bekommen.

Nicht nur "ihrer Gegend": https://forum.openstreetmap.org/viewtopic.php?id=66258 . Deine Befürchtung bestätigt sich...


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#31 2019-05-22 14:48:46

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

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

Das Tool ist nützlich. Ich habe damit mir damit Kiel angesehen und einige Fehler sowie diverse kleine Unstimmigkeiten (z.B. wenn "access" einer Schranke und des dahinterliegenden Wegs nicht passten) gefunden.

Es werden leider zu viele falsch positive Treffer angezeigt.
- Eine Straße, die am Endpunkt ein "highway=turning_circle" hat, sollte nicht (oder allenfalls mit geringster Priorität) als Treffer angezeigt werden.
- "service=driveway" und "service=parking_aisle" werden weit überwiegend als falsch positive Treffer angezeigt. Es wäre unschön, wenn jetzt überall "noexit" nachgetragen wird.
- Wenn ein Weg kürzer als die Lücke am Wegende ist, liegt meist kein Fehler vor. Das tritt insbesondere auf Wegstummel zu Hauseingängen auf.
- Wenn eine Straße endet und in der Nähe nur ein "highway=service" liegt, sollte dies nur als möglicher Fehler mit geringer Priorität angezeigt werden. In Gewerbegebieten findet man oft Straßen, die erst wenige Meter hinter der letzten Firmenzufahrt enden.
- "man_made=pier" wird fast immer als Insel angezeigt. Das ist sinnlos.
  Überwiegend wird "pier" für kleine Holzstege verwendet, ohne eine öffentliche Nutzung zu implizieren.

Die Prioritätsstufen im Tool widersprechen dem Sprachgebrauch (1 als höchste, 5 als niedrigste Priorität)

Offline

#32 2019-05-22 16:30:02

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

ich habe die Daten gerade aktualisiert.

seawolff wrote:

Das Tool ist nützlich. Ich habe damit mir damit Kiel angesehen und einige Fehler sowie diverse kleine Unstimmigkeiten (z.B. wenn "access" einer Schranke und des dahinterliegenden Wegs nicht passten) gefunden.

Es werden leider zu viele falsch positive Treffer angezeigt.
- Eine Straße, die am Endpunkt ein "highway=turning_circle" hat, sollte nicht (oder allenfalls mit geringster Priorität) als Treffer angezeigt werden.

Kannst du da bitte ein Beispiel nennen? So schlimm ist es mir bislang nicht ins Auge gestochen.

seawolff wrote:

- "service=driveway" und "service=parking_aisle" werden weit überwiegend als falsch positive Treffer angezeigt. Es wäre unschön, wenn jetzt überall "noexit" nachgetragen wird.

In vielen Fällen dürfte es helfen, Zäune, Hecken, Böschungen, Mauern oder Stützmauern zu ergänzen. Die Software schließt aus, dass keine bemängelte fehlende Verbindung eine solche linienförmige Barriere kreuzt.

seawolff wrote:

- Wenn ein Weg kürzer als die Lücke am Wegende ist, liegt meist kein Fehler vor. Das tritt insbesondere auf Wegstummel zu Hauseingängen auf.

Wenn die Wege bis an die Haustür führen, kannst du die Tür mit entrance=* taggen. Dann wird der Punkt nicht mehr als Fehler ausgegeben werden und die Daten werden nützlicher, ohne dass es reines Tagging für den OSMI ist.

seawolff wrote:

- Wenn eine Straße endet und in der Nähe nur ein "highway=service" liegt, sollte dies nur als möglicher Fehler mit geringer Priorität angezeigt werden. In Gewerbegebieten findet man oft Straßen, die erst wenige Meter hinter der letzten Firmenzufahrt enden.

Da müsste ich ein konkretes Beispiel sehen.

seawolff wrote:

- "man_made=pier" wird fast immer als Insel angezeigt. Das ist sinnlos.
  Überwiegend wird "pier" für kleine Holzstege verwendet, ohne eine öffentliche Nutzung zu implizieren.

Die Insel-Layer für Pkw und Fahrrad sind gedacht, die Welt so zu zeigen, wie GraphHopper sie sieht. Nur der Insel-Layer, der alle Wege beachtet, hat weniger Einträge, dafür aber echte Inseln.

seawolff wrote:

Die Prioritätsstufen im Tool widersprechen dem Sprachgebrauch (1 als höchste, 5 als niedrigste Priorität)

Ich habe die Bezeichnungen angepasst.

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#33 2019-05-22 17:56:24

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

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

Nakaner wrote:
seawolff wrote:

Es werden leider zu viele falsch positive Treffer angezeigt.
- Eine Straße, die am Endpunkt ein "highway=turning_circle" hat, sollte nicht (oder allenfalls mit geringster Priorität) als Treffer angezeigt werden.

Kannst du da bitte ein Beispiel nennen? So schlimm ist es mir bislang nicht ins Auge gestochen.

Hier sind zwei.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

seawolff wrote:

- "service=driveway" und "service=parking_aisle" werden weit überwiegend als falsch positive Treffer angezeigt. Es wäre unschön, wenn jetzt überall "noexit" nachgetragen wird.

In vielen Fällen dürfte es helfen, Zäune, Hecken, Böschungen, Mauern oder Stützmauern zu ergänzen. Die Software schließt aus, dass keine bemängelte fehlende Verbindung eine solche linienförmige Barriere kreuzt.

Das trifft nicht immer zu. Oft laufen mehrere Parkreihen parallel und werden untereinander als Nachbarn erkannt.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

Einige Meter östlich in der Straße Kesselschmied werden die Enden trotz des Zauns als Fehler erkannt.

seawolff wrote:

- Wenn ein Weg kürzer als die Lücke am Wegende ist, liegt meist kein Fehler vor. Das tritt insbesondere auf Wegstummel zu Hauseingängen auf.

Wenn die Wege bis an die Haustür führen, kannst du die Tür mit entrance=* taggen. Dann wird der Punkt nicht mehr als Fehler ausgegeben werden und die Daten werden nützlicher, ohne dass es reines Tagging für den OSMI ist.

Das wäre eine Lösung. Aber auch ohne entrance könnte man hier die meisten Fehleranzeigen unterlassen.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

seawolff wrote:

- Wenn eine Straße endet und in der Nähe nur ein "highway=service" liegt, sollte dies nur als möglicher Fehler mit geringer Priorität angezeigt werden. In Gewerbegebieten findet man oft Straßen, die erst wenige Meter hinter der letzten Firmenzufahrt enden.

Da müsste ich ein konkretes Beispiel sehen.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

seawolff wrote:

- "man_made=pier" wird fast immer als Insel angezeigt. Das ist sinnlos.
  Überwiegend wird "pier" für kleine Holzstege verwendet, ohne eine öffentliche Nutzung zu implizieren.

Die Insel-Layer für Pkw und Fahrrad sind gedacht, die Welt so zu zeigen, wie GraphHopper sie sieht. Nur der Insel-Layer, der alle Wege beachtet, hat weniger Einträge, dafür aber echte Inseln.

Dann ist die Annahme von GraphHopper falsch, dass alle Stege für Radfahrer geeignet sind.

seawolff wrote:

Die Prioritätsstufen im Tool widersprechen dem Sprachgebrauch (1 als höchste, 5 als niedrigste Priorität)

Ich habe die Bezeichnungen angepasst.

Danke.

PS: Die Links sind zu lang. ;-)

Offline

#34 2019-05-23 17:14:11

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,402
Website

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

Nakaner wrote:

die vielen Fehlermeldungen an (U-)Bahnhöfe kommen daher, dass die Bahnsteige oft als Multipolygone gemappt sind und GraphHopper sie gar nicht auswertet.

Ist Nicht-Auswertung von Multipolygonen auch der Grund dafür, dass diese Linie hier als Routinginsel bemängelt wird? Oder liegt das eventuell an fehlender Unterstützung für Flächen mit highway=footway? Die Linie ist an beiden Enden mit dieser Fußwegfläche verbunden. Es gibt dort auch Warnungen über vermeintlich unverbundene Knoten, etwa diesen Node.

Hier noch der zugehörige Link: http://tools.geofabrik.de/osmi/?view=ro … acity=0.52

Offline

#35 2019-05-24 14:45:14

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

seawolff wrote:
Nakaner wrote:
seawolff wrote:

Es werden leider zu viele falsch positive Treffer angezeigt.
- Eine Straße, die am Endpunkt ein "highway=turning_circle" hat, sollte nicht (oder allenfalls mit geringster Priorität) als Treffer angezeigt werden.

Kannst du da bitte ein Beispiel nennen? So schlimm ist es mir bislang nicht ins Auge gestochen.

Hier sind zwei.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

Wendeplatten sind nicht zwangsläufig am Ende einer Straße. Oft zweigt ein Feldweg ab. Ich habe letzte Woche genügend Feldwege in Rheinland-Pfalz gesehen, die Fortsetzungen innerörtlicher Wohnstraßen sind, die am Ortsrand mit einer Wendeplatte enden.

Das intensive Mapping von Fußwegen als separate Ways schafft von Natur aus unzählige Routingefehler, weil sich damit nicht alle Verbindungen praktikabel abbilden lassen. Manchmal wären sie sogar praktikabel mappbar, werden aber nicht gemappt, wie in San Jose, wo seit 1 1/2 Jahren ein unvollständiger Bürgersteigimport vor sich hin gammelt.

seawolff wrote:

- "service=driveway" und "service=parking_aisle" werden weit überwiegend als falsch positive Treffer angezeigt. Es wäre unschön, wenn jetzt überall "noexit" nachgetragen wird.

In vielen Fällen dürfte es helfen, Zäune, Hecken, Böschungen, Mauern oder Stützmauern zu ergänzen. Die Software schließt aus, dass keine bemängelte fehlende Verbindung eine solche linienförmige Barriere kreuzt.

Das trifft nicht immer zu. Oft laufen mehrere Parkreihen parallel und werden untereinander als Nachbarn erkannt.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

Einige Meter östlich in der Straße Kesselschmied werden die Enden trotz des Zauns als Fehler erkannt.

Ich habe eine Parallelitätsprüfung für service=driveway und service=parking_aisle ergänzt. Auf typischen Supermarktparkplätzen werden Fehlermeldungen jetzt unterdrückt weden.

Der Anzeige des Fehlers östlich der Straße Kesselschmid liegt ein Bug in meinem Code zu Grunde, den ich behoben habe.

seawolff wrote:

- Wenn ein Weg kürzer als die Lücke am Wegende ist, liegt meist kein Fehler vor. Das tritt insbesondere auf Wegstummel zu Hauseingängen auf.

Wenn die Wege bis an die Haustür führen, kannst du die Tür mit entrance=* taggen. Dann wird der Punkt nicht mehr als Fehler ausgegeben werden und die Daten werden nützlicher, ohne dass es reines Tagging für den OSMI ist.

Das wäre eine Lösung. Aber auch ohne entrance könnte man hier die meisten Fehleranzeigen unterlassen.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

Ich bin nicht so begeistert, dafür eine Extraregel einzuführen. Wenn man Mikromapping macht (Abzweige von der Reihenhauszuwegung zur Haustür), sollte man es bitte richtig machen und gleich noch entrance=yes/main ergänzen. Ich habe bei Fußwegen (footway, path, steps) eine Prüfung eingebaut, die Meldungen um 1 Relevanzstufe abstuft, wenn die Distanz der zwei Punkte über den Graphen nur zwei- bis sechsmal so lang ist wie die die Luftlinie. Wenn die Distanz über den Graphen maximal doppelt so lang ist wie die Luftlinie, wird der Fehler gar nicht mehr ausgegeben.

seawolff wrote:

- Wenn eine Straße endet und in der Nähe nur ein "highway=service" liegt, sollte dies nur als möglicher Fehler mit geringer Priorität angezeigt werden. In Gewerbegebieten findet man oft Straßen, die erst wenige Meter hinter der letzten Firmenzufahrt enden.

Da müsste ich ein konkretes Beispiel sehen.

http://tools.geofabrik.de/osmi/?view=ro … pen_ends_5

Wenn da kein weitere Weg, auch kein Trampelpfad  weitergeht, kann man da noexit=yes taggen, ohne dass man sich als Für-den-OSMI-Mapper fühlen muss.

Tordanik wrote:
Nakaner wrote:

die vielen Fehlermeldungen an (U-)Bahnhöfe kommen daher, dass die Bahnsteige oft als Multipolygone gemappt sind und GraphHopper sie gar nicht auswertet.

Ist Nicht-Auswertung von Multipolygonen auch der Grund dafür, dass diese Linie hier als Routinginsel bemängelt wird? Oder liegt das eventuell an fehlender Unterstützung für Flächen mit highway=footway? Die Linie ist an beiden Enden mit dieser Fußwegfläche verbunden. Es gibt dort auch Warnungen über vermeintlich unverbundene Knoten, etwa diesen Node.

Hier noch der zugehörige Link: http://tools.geofabrik.de/osmi/?view=ro … acity=0.52

Ja, GraphHopper hat nicht mal einen rudimentären Multipolygon-Support. Das fällt auch bei Bahnhöfen auf. Das einzubauen würde den Rahmen des Projekts OSMI-Routing-View sprengen.

Wir werden in den nächsten Tagen den alten Routing-View im OSMI durch den neuen ersetzen, weil der alte mittlerweile nicht einmal mehr tägliche Updates schafft (es beschweren sich schon Stammnutzer per E-Mail).

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#36 2019-05-28 23:10:12

asdf2
Member
Registered: 2018-01-06
Posts: 6

Re: 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!

Offline

#37 2019-05-29 17:14:15

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

asdf2 wrote:

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.

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.

asdf2 wrote:

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.

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.

asdf2 wrote:

Noch dazu kann man nicht mehr so weit herauszoomen, was für eine schlechtere Übersicht sorgt.

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


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#38 2019-05-31 10:48:13

asdf2
Member
Registered: 2018-01-06
Posts: 6

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

Danke! Werde es mir gerne anschauen...

Offline

#39 2019-05-31 10:55:06

asdf2
Member
Registered: 2018-01-06
Posts: 6

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

Wo ist bei folgendem der Fehler?:
https://tools.geofabrik.de/osmi/?view=r … pen_ends_1

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

Offline

#40 2019-05-31 12:55:25

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

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)?

Last edited by gormo (2019-05-31 13:37:27)


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#41 2019-06-14 09:55:26

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

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


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#42 2019-06-17 05:16:36

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 1,121

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

Offline

#43 2019-06-17 05:35:53

Wulf4096
Member
From: Hamburg
Registered: 2018-10-23
Posts: 329

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

Vielleicht kann OSMI mit "motor_vehicle" oder "customers" nicht umgehen.

Offline

#44 2019-06-17 12:39:38

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

"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


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#45 2019-06-18 09:07:57

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

Hi,

ich hab hier noch was: http://tools.geofabrik.de/osmi/?view=ro … pen_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=ro … pen_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!

Last edited by gormo (2019-06-18 09:09:16)


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#46 2019-06-18 09:55:58

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

Hallo,

gormo wrote:

ich hab hier noch was: http://tools.geofabrik.de/osmi/?view=ro … pen_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?

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. :-)

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

gormo wrote:

Gleiche Art hier http://tools.geofabrik.de/osmi/?view=ro … pen_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?

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


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#47 2019-06-18 12:31:52

gormo
Member
Registered: 2013-08-01
Posts: 1,986
Website

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

Nakaner wrote:

Hallo,

gormo wrote:

ich hab hier noch was: http://tools.geofabrik.de/osmi/?view=ro … pen_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?

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. :-)

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

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.

gormo wrote:

Gleiche Art hier http://tools.geofabrik.de/osmi/?view=ro … pen_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?

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.

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.


OSM hat nicht das Ziel bis Ende des Monats einen vollständigen Datensatz der Welt zu enthalten.
(nach S.W.) - Aber weil die Welt vielfältig ist, weil sie auch im Detail interessant ist, mag ich genaue Karten (nach C.)

Offline

#48 2019-06-19 12:36:11

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 1,121

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

Was soll hier http://tools.geofabrik.de/osmi/?view=ro … slands_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?

Offline

#49 2019-06-19 13:12:55

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,564
Website

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

PT-53 wrote:

Was soll hier http://tools.geofabrik.de/osmi/?view=ro … slands_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.


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#50 2019-06-25 16:11:50

asdf2
Member
Registered: 2018-01-06
Posts: 6

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

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?

Offline

Board footer

Powered by FluxBB