Bielefeld - Routing Detmolder kaputt

[Florian Lohoff]

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 at zz.de
        UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away