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