On Tue, Jun 04, 2019 at 12:33:06AM +0200, Florian Lohoff wrote:

Ich habe auf der Osningstraße 2 kleinigkeiten repariert. Zum einen waren turn:lanes kaputt - zum anderen gab es da eine turn restriction bei der die beiden from/to sich in mehreren punkten trafen. Also quasi ein ring bildeten. Bin mir nicht sicher ob das gut ist.

Kann aber alles nicht für dieses Problem sorgen. Da ist was mehr kaputt.

Jetzt ist es auch im OSRM auf der Hauptseite kaputt: https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike&route=52.0... Niemand eine idee? Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

On Wed, Jun 05, 2019 at 09:20:24PM +0200, Florian Lohoff wrote:

On Tue, Jun 04, 2019 at 09:52:01PM +0200, tabris wrote:

...

On 04.06.19 00:02, Florian Lohoff wrote:

...

Hi, scheinbar ist eben die Kreuzung Otto-Brenner-Straße, Osningstraße, Detmolder Straße kaputt gegangen

https://osm.zz.de/routeqa/?rid=133189,135822#52.00439,8.56012,17z

Es sind massiv routen geschwenkt.

Ich gucke mal was ich finde.

...

Hi,

auf vier Nodes war ein barrier=kerb was sich offensichtlich auf die Gehwege bezog. Da die Nodes aber auch zu den Straßen gehörten hat das vmtl. das Routing kaputt gemacht. Ich habe das jetzt erstmal gelöscht. Wenn die Routen wieder zurückschwenken sollte das barrier=kerb da auf eigenen Nodes auf dem Gehweg wieder eingefügt werden. Werde ich zumindest heute nicht mehr zu kommen.

Danke - Was ein geiler fuck up. Und ja - viele Routen sind zurückgeschwenkt. Nord-Süd verbindung Osningstraße Otto-Brenner gehen scheinbar noch nicht - Zumindest haben meine Stichproben da nichts gefunden.

Geht doch - Hier ein Beispiel das zurück geschwenkt ist: https://osm.zz.de/routeqa/?rid=135867,136380 Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

Hola Uwe, On Wed, Jun 05, 2019 at 10:45:50PM +0200, Uwe Steinmann wrote:

On Wed, Jun 05, 2019 at 09:20:24PM +0200, Florian Lohoff wrote:

...

On Tue, Jun 04, 2019 at 09:52:01PM +0200, tabris wrote: [...]

Ach ja - das mit dem Routing kann jeder interessierte hier selber verfolgen. Ist scheinbar in Vergessenheit geraten. Für die routingänderungen in owl gibt es eine eigene Mailingliste (Weil das nicht jeder sehen will). Sollte man auch nicht abonnieren wenn man keine möglichkeit zum Filtern hat. Flo, gibt es eine Übersicht der Routen, die du prüfst?

Aeh ja - Sekunde https://osm.zz.de/routeqa/?#51.99883,8.57397,14z Ist dieselbe URL wie die Ergebnislinks aus den Mails - nur ohne den rid=X parameter (rid -> routeid -> sql id aus der datenbank in der die geometrie der route liegt) Da siehst du alle routen die Berechnet werden (Blaue linien) und die Knoten zwischen denen das passiert (Punkte) Wenn du die Fähnchen anklickst siehst du den namen den ich Manuell diesem Punkt gegeben habe und den Cluster (Nummer und Name) an dem der Teil hat. Der Name taucht auch in den Mails auf. Subject: Bielefeld Route: A2 AS Sennestadt Süd->Gehring changed Bielefeld ist der Cluster und A2 AS Sennestadt Süd ist der Knoten A und Gehring der Knoten B. Im moment mache ich die Knoten manuell via QGis in eine Datenbank. Könnte man bestimmt auch anders machen. Im Prinzip habe ich so Cluster - Bielefeld ist einer. Eigentlich für viele Kommunen so in der Umgebung. Diese Cluster haben Punkte von/zu denen Geprüft wird. Ziel ist es wirklich das "höherklassige" Straßennetz komplett abzudecken. Wobei höherklassig nicht tertiary und besser meint sondern wirklich Straßen mit zubringer oder verbindungscharacter. Alle 2 Stunden Rechne ich dann "any to any" d.h. jeweils in den Clustern jeder zu jedem. Wenn sich die Routen länge ändert dann gibts ne mail mit einem Link mit dem man sich die alte und neue Route ansehen kann. Wenn wirklich so wie hier was kaputt geht sind das schnell 1-200 Mails die da kommen. Und dann fängt die Sucherei an warum das kaputt gegangen ist. Der Punkt weshalb ich da so hinterher bin ist das wenn jetzt jemand in den letzten 4 Tagen einen Snapshot der Daten genommen hat und wohlmöglich damit jetzt 2 Jahre durch die Gegend fährt der sich immer über die OSM Daten ärgert weil die kaputt sind auf der Detmolder. D.h. es geht darum die OSM Daten dauerhaft in einem benutzbaren Zustand zu halten und die Zeitfenster in denen was kaputt ist klein zu halten. Ist aber echt auch Syssiphus Arbeit. Und das routing ist strukturell einfach komplex. Die Attribute die Ausgewertet werden und die Berechnung ist eben nicht immer so eindeutig. Daher bin ich ja auch seit langem dabei strukturell so dinge wie lanes, surface zu taggen. Und wenn ich dabei bin gleich noch lit, sidewalk, cycleway, shoulder und priority_road. Und als Knoten noch traffic signs wie give_way oder stop. lanes und surface sind so die signifikanten tags neben maxspeed die in die Kostenberechnung für routen eingehen. Zumindest ist das OSRM so. Und lanes=1 bzw keine lanes Angabe "halbiert" halt die durchschnittliche Geschwindigkeit bzw verdoppelt die Zeit. Und wenn man dann auf den höherklassigen Straßen die tags hat aber sonst nirgends dann kommt da ganz schnell ein ungleichgewicht bzw falsche Priorität rein. Heute hatten wir einen zweiten Schwung routingänderungen. Da hat jemand die Maxspeeds auf der A33 zwischen Ikea und Ende in Halle getagged. Schon sind deutlich routen geschwenkt die jetzt die A33 bevorzugen. Die Änderung habe ich mir nur ganz kurz angesehen. Ich meine da ist jetzt ein maxspeed=none drauf - Ist zumindest erstmal unverdächtig. Hier sieht man wie lange ich das schon laufen habe: routeqa=# select count(*),min(dbtime),max(dbtime) from route; count | min | max -------+---------------------+--------------------- 98255 | 2013-05-28 08:00:00 | 2019-06-05 08:05:03 routeqa=# select count(*) from cluster; count ------- 15 (1 row) routeqa=# select count(*) from node; count ------- 544 (1 row) Das skaliert relativ gut. Im moment brauche der da alle 2 Stunden mal 2-3 Minuten für das routen berechnen. Das Konvertieren der Daten aus dem osm.pbf in das osrm file dauert am längsten. Aber es muss sich eben jemand um die Behebung der Fehler kümmern und das ist manchmal echt kniffelig - Und wenn das jetzt weit über den Kreis Gütersloh oder Bielefeld hinaus geht dann fasse ich da auch große dinge nicht an. Das müssen mapper vor Ort klären. Ich fange da jetzt nicht an in Höxter großflächig Land oder Bundesstraßen zu taggen. Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

Hola, On Thu, Jun 06, 2019 at 09:51:50AM +0200, Uwe Steinmann wrote:

...

D.h. es geht darum die OSM Daten dauerhaft in einem benutzbaren Zustand zu halten und die Zeitfenster in denen was kaputt ist klein zu halten. Ich kann das gut nachvollziehen. Das was du da machst, ist schon klasse und genau die richtige Rangehensweise, um Fehler zu finden. Man braucht halt viele unterschiedliche Sichten auf solche Datenmengen, um Auffälligkeiten und Fehler überhaupt noch zu finden.

Es gibt so viele dinge - Ich bin ja auch immer wieder am gucken wie man das OSM Datenmaterial so angucken kann das man Inkonsistenzen findet. Ist manchmal recht schwer ohne nicht einfach mal 1-5% Sonderfälle zu ignorieren oder false-negatives hinzunehmen.

...

lanes und surface sind so die signifikanten tags neben maxspeed die in die Kostenberechnung für routen eingehen. Zumindest ist das OSRM so. Ist das irgendwo dokumentiert? Oder schaut man dazu in den Sourcecode von OSRM? Oder anders gefragt, woher weißt du, dass lanes und surface entscheidend sind?

Aeh ja :) Also bei OSRM ist das schön nachvollziehbar wie der das bewertet. Die berechnung der "Kosten" bzw Geschwindigkeiten findet im preprozessieren der Daten statt und ist bei OSRM in eine Script Sprache ausgegliedert. D.h. es gibt profile die dann in einer Script Sprache sind. Da ist z.b. das car profile in Lua - Wenn man mal 20 zeilen basic gemacht hat dann kann man dem folgen: https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua D.h. hier z.b. für surfaces: -- max speed for surfaces surface_speeds = { asphalt = nil, -- nil mean no limit. removing the line has the same effect concrete = nil, [ ... ] D.h. auf Gravel geht halt kein maxspeed=100 - genau so finden sich da auch tabellen für tracktypes, smoothness und andere Annahmen. Und in der way_handler library findet sich dann sowas: if width <= 3 or (lanes <= 1 and is_bidirectional) then width_penalty = 0.5 end D.h. wenn die Straßenbreite (im width tag) weniger als 3m ist oder die lanes <= 1 und der weg keine Einbahnstraße ist ist die width_penalty = 0.5 - Ist ja auch klar - Wenn autos nicht einfach im Begegnungsverkehr aneinander vorbei können sondern auf die Bankette müssen dann ist Durchschnittsgeschwindkeit kleiner. D.h. tags wie surface, width, lanes, side_road gehen da mit ein und am Ende wir ein minimum gesucht. D.h. es gibt verschiedene gründe warum man da nicht maxspeed fahren kann und da wird eben das minimum genommen. Bei OSMAnd ist ja die preprozessierung IIRC nicht öffentlich/open source zumindest bin ich da noch nicht drüber gestolpert. Am Ende machen das alle routingengines/navigationsengines ähnlich aber nicht gleich. Gewichtungen und tags unterscheiden sich. Aber lanes/width/surface zu taggen macht ja in jedem fall sinn. Je mehr "Faktische" informationen wir über eine Straße haben desto genauer/besser werden die routen die berechnet werden.

...

Das skaliert relativ gut. Im moment brauche der da alle 2 Stunden mal 2-3 Minuten für das routen berechnen. Das Konvertieren der Daten aus dem osm.pbf in das osrm file dauert am längsten. Hast du die Software/Skripte dafür eigentlich mal veröffentlicht?

Aeh - grundsätzlich ja http://pax.zz.de/gitweb/?p=routeqa.git;a=summary Müsste ich mal mit einem bisschen Doku versehen und auch auf github pushen. Das meiste ist Perl serverseitig. Am ende - osmupdate/osmconvert um alle 2 Stunden ein neues "pbf" zu bekommen und dann osrm convert um da ein osrm file draus zu machen. Dann den osrm starten und die routen berechnen. Ich vermute im git repo liegt auch ein postgres schema - Muss ich mal daraufhin durchsuchen ob da alles dabei ist damit das jeder mal eben aufsetzen kann.

Appropo Höxter. Zumindest für den Bereich Beverungen Richtung Paderborn wäre ich auch an einer Auswertung interessiert, da ich dort häufiger unterwegs bin. Würdest du dort Routen aufnehmen?

Ich habe für Beverungen mal einen neuen Cluster aufgemacht und mal ein paar Knoten mit reingeworfen. Muss ein bisschen aufpassen mit der "Landesgrenze" weil ich nur OWL bzw NRW prozessiere. Aber die ersten sind drin - und ein paar Routen sind zwischendurch schon berechnet worden. Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

On Thu, Jun 06, 2019 at 12:55:14PM +0200, Florian Lohoff wrote:

Hola Uwe,

On Thu, Jun 06, 2019 at 10:46:21AM +0200, Florian Lohoff wrote:

...

Ich habe für Beverungen mal einen neuen Cluster aufgemacht und mal ein paar Knoten mit reingeworfen. Muss ein bisschen aufpassen mit der "Landesgrenze" weil ich nur OWL bzw NRW prozessiere.

Aber die ersten sind drin - und ein paar Routen sind zwischendurch schon berechnet worden.

Ich habe Brakel, Beverungen und Willebasessen mal hinzugefügt - So in jedem Dorf mal einen Knoten - und jeweils in den Nachbarorten der Gemeinde so das die Anschlüsse an die Nachbarcluster jeweils geprüft wird.

Das ist das erste mal gerechnet worden. Hab dann durchgesehen und 2-3 Sachen noch hinzugefügt - Aber eine Nummer habe ich sofort entdeckt die komisch ist.

Zwischen Gehrder und Siddessen wird L 953 und B 252 genommen obwohl es nach meinem dafürhalten eine Tangente über die K 43 gibt die erstmal so vom draufgucken schneller sein sollte. Wird aber nicht benutzt.

Auf dem Mittelstück der K 43 sind die Tags motor_vehicle=destination und ein einsames tracktype=grade1 (aber kein highway=track, sondern nachvollziehbar ein highway=tertiary) gesetzt. Möglicherweise sind beide Tags ziemlich über, das tracktype auf jeden Fall. Auf den Satelitenbildern könnte man Verkehrszeichen vermuten, die die Durchfahrt regeln. Für eine Kreisstraße aber irgendwie seltsam. Die Straßenbreite ist mit ca 4 m auch nicht sonderlich groß, spricht also eher gegen eine Durchfahrtstraße. Das Stück war tatsächlich vor 8 Jahren noch ein track, zwischenzeitlich auch mal residential und tertiary, bis es vor 4 Jahren entgültig zu tertiary wurde. Der tracktype ist vermutlich immer stehen geblieben. Ein explizites lanes=1 scheint angebracht. Dieses Stück *nicht* in die Route einzubeziehen halte ich aber für richtig.

Ich habe mal schnell einen export aus meinem QGis angehängt als Übersicht in OWL was ich an routen überwache. Super. Danke.

Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen Uwe.Steinmann@mmk-hagen.de Tel: 02331 840446 Fax: 02331 843920

On Fri, Jun 07, 2019 at 08:24:43AM +0200, Uwe Steinmann wrote:

Hallo Flo,

ich habe noch einen Fall gefunden, den ich mir nicht erklären kann. Möglicherweise ein gutes Beispiel, um noch etwas die Vorgehenѕweise beim Finden der Routingprobleme zu verbessern.

https://osm.zz.de/routeqa/?#51.57269,9.16835,16z

zeigt durch Eissen zwei Routen. Screenshot hängt auch an der Mail. Die Route quer durch den Ort (im Screenshot "1") scheint mir nicht sinnvoll zu sein. Es gibt aber auch Routen über die K22 (im Screenshot "2"). Die erscheinen mir grundsätzlich sinnvoller.

Mir stellt sich die Frage, warum zumindest in einem Fall die Route durch den Ort gewählt wurde? Welche Route ist das? Kann ich das irgendwie rausfinden?

Genau - Wir haben ja nur "transit" routen - d.h. routen die durch den Ort gehen. Damit sollten die auf den "Fernstraßen" oder Straßen mit Sammelfunktion bleiben. Hier wird der Liboriweg benutzt - bei die die 1. - Das ist definitiv schon beim Anblick der Karte kein Sammler oder für den Durchgangsvekehr. Der Liboriweg wird aktuell benutzt weil er mit dem derzeitigen tagging "Schneller" ist - Das ist natürlich quatsch. Ich habe mal gerade in die Daten geguckt. Ich würde auf der K22 jetzt lanes=2 taggen - Die ist breit und für Begegnungsverkehr. Der Liboriweg hingegen ist wirklich eine schmale Gasse laut Luftbild. D.h. da würde ich ein "lanes=1" taggen. Damit sollte sich das schon erledigt haben. Ich habe ein paar solche fixes gestern schon verteilt daraufhin sind so 2-300 Mails gekommen mit routingänderungen. Die gehe ich jetzt nochmal durch. Ansonsten ist da wirklich alles miteinander verklebt - Sehr unschön - Also aufpassen das du die lanes=1/2 nicht auf irgendwelche landuses packst :( Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

On Fri, Jun 07, 2019 at 09:35:37AM +0200, Uwe Steinmann wrote:

...

Der Liboriweg hingegen ist wirklich eine schmale Gasse laut Luftbild. D.h. da würde ich ein "lanes=1" taggen. Damit sollte sich das schon erledigt haben. lanes=1 wird wohl passen. Ich habe mich allerdings nicht getraut auf Basis des Luftbildes (auch wenn das bei ESRI recht ordentlich ist) das Tagging zu machen.

...

Ich habe ein paar solche fixes gestern schon verteilt daraufhin sind so 2-300 Mails gekommen mit routingänderungen. Die gehe ich jetzt nochmal durch. Habe ich gesehen. Da waren viele genau dieser Art und die neuen Routen waren aus meiner Sicht immer besser, auch wenn sie mitunter etwas länger waren, aber dafür nicht mehr quer durch die Wohngebiete verliefen.

Ich habe gerade in Brakel Altstadt auch noch einiges gemacht. Da gehen Durchgangsrouten wirklich MITTEN durch, durch irgendwelche kleinen Gassen. Länger ist ja kein Argument - Es ist immer Zeit das entscheiden. Und abbiegen kostet halt richtig zeit. Und nur weil ich "formal" 300m spare muss ich 2 mal abbiegen. Schon ist die route "länger". Und du willst nicht im Ort wenn du nur durch fährst von der Landstraße runter, 300m durchs Wohngebiet und dann wieder auf die Landstraße. Wenn wir DIE Daten dann nehmen und jede Menge Leute damit navigieren lassen stehen die Anwohner mit Mistforken bei der OSM Foundation ;) Und am Ende wird das wer korrigieren. Die großen wie Facebook, Apple und Microsoft machen sowas ja schon international und das im großen Stil. Die trauen sich im moment nicht an Deutschland ran. War einhelliger Tenor bei der State of the Map letztes Jahr. Wenn die dann mal anfangen sowas zu fixen dann geht das ganz schnell. Die Frage ist ob man denen das überlassen will. So haben wir ein eigenes instrument uns das anzusehen und können mit dem lokalen wissen da einiges fixen. Nur mal um die Größenordnung mal klarzumachen - Das sind die Tasks die Apple bearbeitet und wie - Jedes Ticket in etwa ein Land - Aktuell 144 Tickets https://github.com/osmlab/appledata/issues Die waren auf der SoTM sehr verschwiegen - Der Talk durfte auch nicht gefilmt werden. Aber die sind gefühlt GANZ GROß unterwegs. Apple maps besteht in einigen/vielen Ländern schon aus OSM. Microsoft und Facebook kannst du dir selber ansehen. Videos der State of the Map 2018 in Mailand. Die sind massiv mit Machine Learning und optical recognition aus Luftbildern dabei. Klassifikation der Straßen in Australen war ein Thema bei Microsoft - Facebook hat von Thailand erzählt und deren Luftbildauswertung. Früher oder später hast du 200 Mapper die in Deutschland bezahlt Zeugs heile machen. Ich habe da so für den Bereich in dem ich unterwegs ist keine Sorge - Aber wenn das Bereiche mit desolatem Zustand sind bleibt da kein Stein auf dem anderen. Die Daten sind hinterher bestimmt besser, aber ob sie dann noch dem ästhetischen Bedürfniss des mappers vor Ort entsprechen wage ich zu bezweifeln. Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

On Wed, Jun 05, 2019 at 11:46:40PM +0200, Florian Lohoff wrote:

Hola Uwe,

On Wed, Jun 05, 2019 at 10:45:50PM +0200, Uwe Steinmann wrote:

...

On Wed, Jun 05, 2019 at 09:20:24PM +0200, Florian Lohoff wrote:

...

On Tue, Jun 04, 2019 at 09:52:01PM +0200, tabris wrote: [...]

Ach ja - das mit dem Routing kann jeder interessierte hier selber verfolgen. Ist scheinbar in Vergessenheit geraten. Für die routingänderungen in owl gibt es eine eigene Mailingliste (Weil das nicht jeder sehen will). Sollte man auch nicht abonnieren wenn man keine möglichkeit zum Filtern hat. Flo, gibt es eine Übersicht der Routen, die du prüfst?

Aeh ja - Sekunde

https://osm.zz.de/routeqa/?#51.99883,8.57397,14z

Ich muss hier nochmal nachfragen. Die obige URL liefert viele blaue Routen. Wenn ich davon gezielt eine rausgreifen möchte, kann ich den Parameter rid in der URL übergeben. Aber wie komme ich auf die notwendige Id der Route? Uwe -- MMK GmbH, Fleyer Str. 196, 58097 Hagen Uwe.Steinmann@mmk-hagen.de Tel: 02331 840446 Fax: 02331 843920