On Fri, May 03, 2019 at 11:56:17AM +0200, Rainer wrote: > Hallo Florian, > > wie Navigationssysteme das handhaben, ist eine Sache. Mein altes Navigon > sagt immer "das Ziel liegt in einem beschränkt befahrbaren Bereich" in > Fällen wie Anlieger frei, Fußgängerzone, Waldweg. Das wäre m.E. im > Router handhabbar.
Das ist nicht so einfach wie sich das anhört. Einfaches A*/Dijkstra geht da eben nicht. Viele/Alle? Router machen schon den Fehler bei access=destination das die Kosten für die Strecke steigt - Das ist falsch. Wenn ich Anlieger bin darf ich da rein - Das erzeugt keine "Kosten" in der Path suche sondern das ist ein Attribut das die Route am Anfang oder Ende eben in einer Destination ist aber nicht im transit. Dazu kommt das diese Entscheidung ein Übergang von einem weg access=yes -> access=destination am Ende sein darf und am Anfang ein access=destination -> access=yes - Aber eben nicht umgekehrt oder sogar mittendrin. Es darf aber am ende ein access=destination -> access=destination sein. Erzeugt auch keine weiteren kosten. Stand heute würden dich alle router durch eine access=destination schicken wenn nur die Ersparnis an Route/Zeit drumherum hoch genug ist. Ich habe da wo ich wohne aber das Problem das die allermeisten Routing engines mich sofort verzweifelt versuchen von meiner Anliegerstraße auf dem kürzesten Weg runterzuschicken. Und das auch von einer Asphaltierten Straße auf einen track grade2 oder grade3. Der ist immer noch besser als die access=destination an der sogar mein Ziel oder Start liegt. Da sieht man wie kaputt sich so access tags auswirken können und wie blauäugig im moment so routing funktioniert. 98% funktioniert super, die letzten 2% sind halt totaler murks. > Interessanter finde ich die Fälle, in denen ein Weg existiert, aber > nicht in OSM eingezeichnet ist. > Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du > die Abfrage bekanntgeben? > Ich würde in meiner Gegend mal nach solchen Fällen schauen. Das ist mehrstufig. Erstmal exportiere ich alle Adressen: https://github.com/flohoff/addressextract Der baut admin boundary polygone und plz polygone etc und versucht dann Adressen zu finden und ggfs über die Polygone zu vervollständigen. Da plumpst dann ein json bei raus das für NRW alleine -rw-r--r-- 1 flo flo 916M May 1 08:00 nrw.json 900MByte hat. Das läuft leider relativ lange deshalb mache ich das nicht in meinem normalen batch. Da extrahiere ich nur Ostwestfalen-Lippe alle 2 Stunden. Jede Adresse sieht dann so aus: { "lat" : "50.915591", "geomsuburb" : "Zollstock", "id" : "359460", "lon" : "6.941247", "geompostcode" : "50969", "geomcounty" : "Köln", "errors" : [ "No city", "No postcode" ], "housenumber" : "107", "source" : "node", "street" : "Höninger Weg" } Dann prozessiere ich einen NRW Extract für OSRM und starte den mit dem Extrakt. Und dann habe ich ein kleines perl script das die Adressen alle einzeln in den OSRM rein wirft mit der "nearest" Funktion und aus dem resultat die distance und die lat/lon des waypoints mit der Adresse zusammen raus schreibt. Das braucht dann auch so ein paar Stunden (Ja - OSRM kann batches - war mir erstmal egal - erstmal brute forcen - CPUs sind auch bei stupider Tätigkeit genügsam) Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
signature.asc
Description: PGP signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
