Hola, On Wed, Oct 11, 2023 at 08:45:08PM +0200, Ökkel wrote:

Am 11.10.2023 um 12:00 schrieb osm-request@gt.owl.de:

...

Herford https://osm.zz.de/routeqa/#52.1191,8.6774,13z

Die blauen Pinne sind die Punkte zwischen denen ich routen errechne.

Das ganze wird aktuell alle ~2 Stunden neu gerechnet und bei änderungen gibts mails.

In Herford gefallen mir noch nicht "Ortsieks Weg", "An der None", "Am Hundebach", "Waldfriedenstraße", "Kirschengarten", "Karlstraße", "Deichkamp", "Schnatweg", "Eimterstraße", "Finnebachstraße"

Eimterstraße und Ortsieker Weg sind m.M.n. auf jeden Fall ok, Karlstraße auf keinen Fall, der Rest irgendwo dazwischen.

Die Karlstraße ist auf dem Stück quasi nur eine bessere Hauszufahrt (aber öffentlich), bis vor ein paar Jahren waren da auch Poller in der Mitte. Ich hab gerade noch ein paar Tags ergänzt um die unattraktiver zu machen.

Ich hab gesehen das du einiges gemacht hast :)

Aber was sind das v. a. zwischen Innenstadt und Elverdissen für Stumpfrouten? Direkt da ist ja kein Marker, wendet der Router da mal völlig random?

Das kann sein - Evtl ist das auch ein Fehler in OSRM - Das ich ja mache ist das ich die geometrieen aller routen dieses durchgangs splitte an allen nodes - D.h. ich erzeuge ein paar hundertausende 2 node ways. Die dedupliziere ich dann und schreibe die als "grid" in die Datenbank damit man das visualiseren kann. Ausserdem merke ich mir ob die nur in eine oder in beide richtungen durchfahren werden. Wenn ich das nicht mache müsste die Webseite (Oder bei mir QGIS) ~50K a 10km und 2000 nodes laden um irgendwas darzustellen. Es könnte sein das OSRM irgendwo Schnipsel zurückliefert die gar nicht wirklich zur route gehören. Ich müsste das mal irgendwo debuggen und mir die route raussuchen die das verursacht. Hab das aber schon gesehen. Das webinterface oder das ganze braucht eigentlich ganz viel Liebe. Ich hätte das ja gerne so das das für jedermann "consumable" ist - D.h. jedermann kann nodes setzen und sich subscriben auf nodes. Und alle Nachbarnodes werden dann jeweils überprüft oder so. Naja - für ein anderes leben. Das ganze läuft mittlerweile 10 Jahre und ich hab da immer mal wieder dran rumgeschraubt und hier und da verbessert. Als nächstes steht erstmal das Thema mail notification an. Da kommt viel zu viel. Das muss auf eine Mail/Cluster runter Und da stehen dann alle routingänderungen sortiert nach länge oder so. Da könnte man noch so viel machen. Z.b. die geometrieen der beiden routen vergleichen und nachsehen wieviel "abweichung" d.h. wieviele Meter ist die route wirklich von der anderen runter. Damit könnte man kleine geometrieänderungen an kreuzungen viel leichter identifizieren. Ausserdem könnte man die BBOX der Änderung berechnen und gleich da hin zoomen. Oder man könnte errechnen ob die rausgefallenenen teilschnipsel der geometrieen GAR NICHT mehr durchfahren werden oder nur von einigen routen. Damit könnte man direkt "defekte" ausschliessen. Und wenn man die BBOX und den änderungszeitraum hat könnte man vermutlich gleich die changesets identifizieren die damit überlappen. Würde es bei der identifikation der changesets viel einfacher machen. Oder man könnte in die Mail notification eine Heat map anhängen des clusters wo sich am meisten geändert hat. Manchmal kriegt man 200 mails und das sind aber 3 änderungen. Das das wiederzufinden ist manchmal echt haarig. So viele Ideen - so wenig zeit. Flo -- Florian Lohoff f@zz.de Any sufficiently advanced technology is indistinguishable from magic.