"(motor_)vehicle=agricultural;forestry" funktioniert in verbreiteten Routern und Navis nicht: Lösungsvorschlag

Dann liegt halt (wahrscheinlich) ein Tagging-Fehler vor und es gilt: garbage-in, garbage-out.

2 Likes

Ich verstehe auch nicht, was die Beispiele bringen sollten. Willst Du sagen, dass die Hierarchie nicht immer gilt, sondern die Interpretation auch noch vom Top-Level-Tag abhängig sein soll? Dann wird die ganze Tag-Suppe ja noch undefinierter.

Nein, es geht nicht um die Routing-Kosten. Es geht darum, dass Start und Ziel außerhalb von “agricultural;forestry” in nicht eingeschränkten Straßen liegen sollen. Ich habe lange gesucht, um ein halbwegs vernünftiges Beispiel zu finden. Wenn ich in den grade2-track übergehe, bin ich nicht mehr in einem nicht eingeschränkten Bereich, Standardwert in Deutschland wäre für motor_vehicle=destination, siehe OSM tags for routing/Access restrictions - OpenStreetMap Wiki

Und 8 Minuten außenrum gegenüber 3 Minuten über grade2-track plus “agricultural;forestry”-grade1-track ist deutlich. Wie @Langlaeufer gesagt hat: für einen richtigen Test müssen Start und Ziel außerhalb einer Einschränkung sein, sonst kann man keine Aussage treffen, außer man schaut wie @whb im Code und/oder Profil nach.

Ist auch die Frage, inwieweit der Unterschied in der Praxis noch vorhanden ist, oder man für die langsamen Fahrzeuge einen eindeutigeren Key einführen sollte, da das leicht verwechselt oder bewusst ignoriert wird. Gibt auch einen Niederländer, der das weltweit ändert oder geändert hat. Ich habe ihn bei mir in der Nähe schon zweimal auf den Unterschied aufmerksam gemacht, genauso wie auch andere, wo er meinte, “vehicle=destination;agricultural” wäre mehrdeutig (was auch eine eigenartige Argumentation ist, denn wenn er dieser Ansicht ist und, wie er angibt, die Beschilderung vor Ort nicht kennt, wie kann er dann die Mehrdeutigkeit auflösen?).

1 Like

Ich würde vorschlagen, darauf zu verzichten, einen Unterschied zwischen motor_vehicle=agricultural und agricultural=yes zu machen und mit dieser Ungenauigkeit zu leben. Der diskutierte Fall sollte dann wie Version2 getaggt werden.

den Unterschied gibt es rechtlich, und wir bilden das ab, wieso sollten wir das jetzt alles über Bord werfen und „mit Ungenauigkeiten leben“?

Sehe ich jetzt als nicht so schlimm an. Die Tatsache, dass überhaupt eine schöne, hierarchische Darstellung vorhanden ist, macht es sogar relativ einfach. Ich schreibe zwar nicht hauptberuflich Router, aber eine Funktion, die einem zu so einem Tagging ein ja/nein/vielleicht zurückliefert ist kein Hexenwerk.

2 Likes

Ohne diese Hirachie ließe sich das gar nicht auswerten, weil dann die Reihenfolge der Bearbeitung vollkommen unklar wäre.
Aber ja dieser Detailgrad ist für einen Datensatz ungewöhnlich, woanders generalisiert der Datenanbieter, aber das ist ja auch eine Stärke von OSM.

Wäre es nicht möglicherweise sinnvoll die Unterscheidung zwischen agricultural und forestry einfach komplett weg zu lassen und gemeinsam mit Fischzucht, Gewässerunterhaltung und Stromleitungswartung als motor_vehicle=management/land_management oder ähnlichem zu taggen? Über management_type=* könnte man dann die genaueren Angaben machen.

1 Like

Die Unterstützung von vehicle=agricultural;forestry wurde in graphhopper schon vor längerer Zeit für alle Profile implementiert. Leider ist diese aber in der online Instanz noch nicht verfügbar. Es sollte aber nächste Woche soweit sein. Siehe https://discuss.graphhopper.com/t/car-profile-and-motor-vehicle-agricultural-forestry-on-graphhopper-maps/7922

4 Likes

Vielen Dank an ratrun für Bericht, Analyse und Initiative und an Peter Karich von Graphhopper fürs schnelle Fixen. :o) Bemerkenswert: Das Sperren eines Weges für Autos funktionert hier mit “agricultural=yes&forestry=yes” ohne dass “(motor_)vehicle=no” nötig wäre, wie man an diesem Teil der Versuchsstrecke sieht.: OpenStreetMap

Sollte nicht highway=track alleine für das Sperren von KFZ Verkehr ausreichen? Sollte ein track nicht motor_vehicle=agriculture;forestry implizieren?

laut Wiki ist der default Wert auf destination.

Das ist in hohem Maße Länderspezifisch.
Bei uns duerfen unbeschilderte Feldwege mit dem Auto befahren werden, bei Waldwegen sieht es schon wieder anders aus.

2 Likes

Das verschiebt das Problem doch aber nur, dann hast du die Semikolons in management_type=* stehen. Ich sehe hier keinen Gewinn.

1 Like

Glaube ich nicht. Der wird da sperren weil die umgebenden Straßen gesperrt sind oder weil die Änderungen noch nicht verarbeitet sind.

Bitte auf den richtigen Wert motor_vehicle=agricultural;forestry ändern.

5 Likes

Die Router treffen jede Menge Annahmen um typische Mappingfehler (insbesondere auch fehlende Daten) auszumerzen. Wenn das Routing funktioniert handelt es sich deshalb nicht unbedingt um korrektes Mapping sondern der Router hat ggf. einfach nur richtig geraten was der Mapper erreichen wollten. An anderen Stelle wird dafür richtig Erfasstes falsch interpretiert.

2 Likes

Es gibt Wegstücke, die gut durch PKW frequentiert auf abkürzenden Routen zwischen höher klassifizierten Straßen liegen, dann als track (um)gemappt werden, wenn sie durch Gebiete ohne Wohnbebauung und insbesondere durch Felder führen. Tatsächlich gibt es Fälle, in denen Gemeinden diese zum Beispiel zur Entlastung einer Ortsdurchfahrt im guten Zustand halten. IMHO sollten die eher “unclassified” sein, werden aber von manchen Mappern als “FELD”-Weg und somit als track grade1 empfunden.

1 Like

So sieht es aus, solange die Fahrzeuge da legal fahren.

1 Like

Sollte ein track nicht motor_vehicle=agriculture;forestry implizieren?

je nach Bundesland? Weltweit?

Das Sperren eines Weges für Autos funktionert hier mit “agricultural=yes&forestry=yes” ohne dass “(motor_)vehicle=no” nötig wäre,

das ist aber was anderes als landwirtschaftlicher Verkehr, nämlich landwirtschaftliche Fahrzeuge, und es sollte nichts ausschließen (weil der default dadurch nicht geändert wird), und forestry=yes ist sowieso undefiniert und von daher unklar, es gibt in Deutschland keine Fahrzeugklasse “Forstfahrzeug”