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

Communities Deutschland (Germany)
1

Moin, dieses Thema gab es hier schon, ohne dass es gelöst worden wäre.

Gemäß OSM-Wiki sollen Straßen mit dem Zusatzschild “Land- und forstwirtschaftlicher Verkehr frei” mit “motor_vehicle=agricultural;forestry” bzw. “vehicle=agricultural;forestry” gemappt werden:

https://wiki.openstreetmap.org/wiki/DE:Verkehrszeichen_in_Deutschland#Besondere_Fahrzeuge_und_Transportgüter_frei_(verbale_Angabe)_DE:1026

Das funktioniert mit den drei Routing Diensten auf der osm.org Seite und in OSMAND nicht und äußert sich dadurch, dass Autos über diese Wege geroutet werden. Um das näher zu untersuchen, habe ich eine Teststrecke mit verschiedenen Tagging angelegt, um zu sehen, wie die Dienste darauf reagieren. Und alle drei Router und OSMAND reagieren gleich. Das kann nachvollzogen werden, indem man hier die drei Routingdienste mit “Auto/car” testet:
OpenStreetMap
Für OSMAND muss man es auf dem Smartphone probieren. Sollte das Routing des letzteren Dienstes mit dem PC auch auf einer Website getestet werden können, wäre ich für einen Hinweis dankbar.

Das Mapping der Teststrecke habe ich für die relevanten access Tags in anliegender Zeichnung illustriert.

agricultur forestry
agricultur forestry1920×1248 160 KB

Daraus geht hervor, dass als einziges Mapping für das oben besagte Schild die Version2 korrekt funktioniert, indem es Autos nicht passieren lässt. Die oben aus dem OSM Wiki zitierte “Semikolon getrennte” Version1 funktioniert nicht. Sie funktioniert nur dann, wenn nur ein value für den den key (motor_)vehicle wie in Version4 genannt wird…

Ich habe von einem Fossgis-Verantwortlichen für OSRM die Antwort erhalten, dass nach dortiger Auffassung “Semikolon getrennte Werte manchmal Sinn machen, aber nicht bei access tags.” Die anderen Dienste reagieren auf die verschiedenen Mappings der Versuchsstrecke ebenfalls exakt entsprechend dieser Auffassung.

Zur Lösung des Problems wird vorgeschlagen, die access Tags wie auch sonst bei OSM zu vereinzeln. Hier ist es beispielsweise verbreitet, die access Tags “foot=yes & bicycle=yes”, manchmal zudem “psv=yes” zu trennen. Genau so könnte auch hier verfahren werden, indem im OSM Wiki die Version2 mit getrenntem “agricultural=yes & forestry=yes” statt der Semikolon getrennten “agricultural;forestry” (Version1) verwendet wird.

2

agricultural als key hat eine andere Bedeutung:
https://wiki.openstreetmap.org/wiki/Key:agricultural

11 Likes
3

Es ist nun wirklich keine Raketenwissenschaft, vehicle=agricultural;forestry in Routern korrekt auszuwerten. Die Router müssen hier angepasst werden, nicht die Daten.

18 Likes
4

Das Semikolon ergibt auch bei access-Tags Sinn.

Mit agricultural=yes und forestry=yes lässt sich agricultural;forestry aber nicht ausdrücken, denn yes wirkt nicht ausschließend, sondern nur zusätzlich.

Oder willst du so etwas?

motor_vehicle=no
agricultural=yes
forestry=yes

Zur anderen Bedeutung von agricultural, siehe den Beitrag oben.

Das ist wirklich schade, denn in der Vorverarbeitung wird das berücksichtigt (unvollständige Auflistung von mir):

<entity_convert pattern="tag_transform" from_tag="vehicle" from_value="agricultural; forestry" to_tag1="vehicle" to_value1="agricultural;forestry"/>
<entity_convert pattern="tag_transform" from_tag="vehicle" from_value="forestry; agricultural" to_tag1="vehicle" to_value1="agricultural;forestry"/>
(...)
<type tag="motor_vehicle" value="agricultural;forestry" minzoom="13" additional="true" poi="false"/>
(...)
<type tag="motorcar" value="agricultural;forestry" minzoom="13" additional="true" poi="false"/>
(...)
<entity_convert pattern="tag_transform" from_tag="motorcar" from_value="agricultural; forestry" to_tag1="motorcar" to_value1="agricultural;forestry"/>
<entity_convert pattern="tag_transform" from_tag="motorcar" from_value="agricultural;forestry;destination" to_tag1="motorcar" to_value1="agricultural;forestry"/>
(...)
<type tag="motorcycle" value="agricultural;forestry" minzoom="13" additional="true" poi="false"/>
(...)
<entity_convert pattern="tag_transform" from_tag="motorcycle" from_value="agricultural; forestry" to_tag1="motorcycle" to_value1="agricultural;forestry"/>
<entity_convert pattern="tag_transform" from_tag="motorcycle" from_value="agricultural;forestry;destination" to_tag1="motorcycle" to_value1="agricultural;forestry"/>

Im Routing wurde es dann anscheinend vergessen:
OsmAnd-resources/routing/routing.xml at master · osmandapp/OsmAnd-resources · GitHub

Hier hilft evtl. ein Fehlerbericht oder ein Pull Request.

1 Like
5

steht so im Ursprungsposting: Version2

6

Jetzt sehe ich es, in diesem seltsam unscharfen, verzerrten Bild. :wink:

7

Man könnte es über vehice=agricultural + forestry=yes lösen, aber ich sehe hier auch eher die Router in der Lösungspflicht.

EDIT: Korrektur: forestry ist nur als value, nicht als key erlaubt.
EDIT2: Ist doch erlaubt.

8

Ein wenig in die Breite gezogen, ja.
Unscharf? Ich kann es ohne Brille perfekt lesen, wenn ich zwei Mal zum Vergrößern draufgeklickt habe. Man weiß bei Foren nie, bei welcher Dateigröße Schluss ist und beschränkt sich daher.

Ich wollte halt zusätzlich zum verlinkten Routing, wo man jedes Mapping einzeln anklicken muss, eine Übersicht auf einen Blick anbieten. Eine Vektorgrafik, die trotz geringem Speicherbedarf viel schärfer wäre, will dieses Forum nicht.

9

Wenn man dass so lösen muss kommt man allerdings nicht weit, weil man alle möglichen Permutationen vorher definieren muss (zumindest weitere Schilder hängen gerne mal in beliebiger Reihenfolge):

agricultural;forestry;destination
destination;agricultural;forestry
destination;agricultural
destination;forestry
agricultural;destination
forestry; destination
…

Hier müssten schon die Semikolons geparst werden.

1 Like
10

Um sowas zu testen sollte man nicht Start/Ziel in einen gesperrten Bereich packen. Hier könnten Router durchaus Ausnahmen machen.

Und nochmal auch von mir der Hinweis:

  • Das Tag forestry=yes ist nicht definiert!!
  • agricultural=yes meint langsame Fahrzeuge (Ursprünglich landwirtschaftliche Fahrzeuge=Traktoren) und nicht den landwirtschaftlichen Verkehr (Zweck).
2 Likes
11

Das Wiki ist anderer Ansicht: https://wiki.openstreetmap.org/wiki/DE:Key:forestry
Ansonsten volle Zustimmung, vor allem zum Testaufbau.

Folgendes Beispiel OpenStreetMap zeigt, dass OSRM und Graphhopper in der Tat darüber routen, während Valhalla dies erst macht, wenn man den Startpunkt weit genug auf den grade2-track legt (bei 8 min zu 3 min geschätzter Fahrzeit).

Edit (12.05.2023): nach dem Online-Update routet jetzt auch Graphhopper bei meinem Testfall außen herum.

2 Likes
12

Danke für den Link.
https://wiki.openstreetmap.org/w/index.php?title=Key:forestry&action=history
Es sind hier aber tatsächlich forstwirtschaftliche Fahrzeuge beschrieben und nicht forstwirtschaftlicher Verkehr.

Es gibt mittlerweile 7000 Verwendungen. In Deutschland dürften das so gut wie nie vorkommen.
Wenn doch dann ist es meist die übliche Verwechslung von forst/landwirtschaftlichen Verkehr mit forst/landwirtschaftlichen Fahrzeugen.

1 Like
13

Access tags sind in den Auswirkungen relativ einfach - weil es nur 3 Zustände gibt. Das Problem ist die kombination mit anderen tags:

Ja → kosten niedrig
Vielleicht → wird nur genommen wenn unbedingt nötig
Nein → fällt aus dem graph wird nie genutzt, keine berücksichtigung im routing

So - Und jetzt kann man die ganzen total schön differenzierten tags in die Körbchen sortieren:

nix, permissive, yes → Ja
destination → Vielleicht
private, customers, no, forestry, agricultural und alles andere ->Nein

Es gibt in der Auswertungen keine anderen “auswirkungskörbchen” weil eben Dijkstra oder A* so funktionieren.

Und doch - das parsen ist total kompliziert - Ich habe selber solche Parser geschrieben und es gibt keine eindeutigkei - Was ist mit

highway=secondary
access=yes
motor_vehicle=no

oder

highway=path
access=yes
vehicle=no
motor_vehicle=yes

Es gibt keine kombination die man nicht in den OSM Daten findet. Und irgendwer ist immer da der erwartet “Das ist doch offensichtlich was da sein soll”. Und Mapper sind zunehmend in dem Modus “viel hilft viel”.

Flo

14

Das ist schon klar. Nur wenn ich versuche das per Zuordnungstabelle zu machen ohne die Aufzählungen vorher aufzulösen dann …

15

Das lässt sich ganz eindeutig auflösen, das speziellere Überschreibt das allgemeinere (du hast es ja schon so hingeschrieben). Die Frage ist nur, ob der Mapper da auch so gedacht hat.

a) heißt alles erlaubt außer Kraftfahrzeuge
b) alles erlaubt außer Fahrzeuge die keine Kraftfahrzeuge sind

viel problematische sind Kombinationen wie

highway=path
foot=designated
bicycle=designated.
access=no

Auch hierfür ist die Lösung eindeutig. aber vermutlich wollte der Mapper ja den gemeinsamen Rad/Fußweg einfach nur komplett sperren

2 Likes
16

Die Keys sind hierarchisch: access → vehicle → motor_vehicle → motorcar.

Man muss sie von allgemein zu speziell auswerten. Und nicht die Defaultwerte vergessen :face_with_spiral_eyes: !

Also highway=path → no, access=yes → yes, vehicle=no → no, motor_vehicle → yes. Endergebnis für Autos: yes.

Und jetzt schaut Euch doch mal Key:access - OpenStreetMap Wiki mit der Hierarchie an. Stellt Euch mal vor, Ihr sollt als Entwickler einen Router konfigurieren und habt Euch noch nie mit den Feinheiten des OSM-Taggings beschäftigt? Wer soll das denn im ersten Versuch fehlerfrei interpretieren? Und dann noch Semikolons? Könnt ihr vergessen.

Auch dass agricultural als Key etwas anderes bedeuten soll, als als Value? :man_facepalming:

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.

1 Like
17

Das sind die Eigenheiten von OSM-Daten. Dass muss man mit der Zeit lernen!
Für das generalisieren sind die Datennutzer zuständig.

Das besser zu dokumentieren und ggf. begrifflich nachzubessern, da darf jeder mithelfen und ggf. Proposals einreichen.

agricultural=yes und access=agricultural ist übrigens ganz gravierender Unterschied.

1 Like
18

Bei Deiner Betrachtung geht es aber vielmehr darum, welche unterschiedlichen Routing-Kosten die Router den einzelnen Taggings zuordnen. Valhalla erscheint hier die gro0e nördliche Schleife halt günstiger. Das hat aber nichts damit zu tun, ob ein Router einen Weg aufgrund seines Taggings für eine Auto grundsätzlich verschmäht oder nicht: OpenStreetMap Da zeigt sich auch an diesem Weg, dass auch Valhalla grundsätzlich bereit ist, ein Auto über “motor_vehicle=agricultural;forestry” zu routen, was das Problem ist.

19

@Langlaeufer @hfs Ihr habt das eigentliche Problem nicht erkannt

Der Widerspruch liegt doch nicht in der Hirarchie, sondern bereits im highway=secondary vs. motor_vehicle=no
Wenn da nur noch Fuß-, Fahrrad-, Kutsch- und Handkarrenverkehr zulässig ist, wo ist denn da noch die Verkehrsbedeutung einer secondary?

Genauso hier:

Wenn nur Fußgänger und Kfz, auch mehrspurige bis hin zu Bussen und Lkw erlaubt sind, dann stimmt was nicht. Der Router weiß aber nicht, ob path oder motor_vehicle richtig ist. Das wird auch durch Hierarchie nicht wieder richtig.

2 Likes
20

Worauf ich nur hinaus wollte, man kann das auflösen, dass das keinen Sinn macht ist eine andere Frage.
Ich hab mir daher bisher immer eine Tabelle gemacht mit allen Tagkombination die vorkamen und hab dann geraten, was die Mapper wohl damit gemeint haben. Das funktioniert natürlich nicht mehr, wenn man das für beliebig große Gebiete machen möchte, typische Fehler sollte man aber dennoch abfangen und dazu gehört agricultural=yes oder access=destination/agricultural/forestry → (motor_)vehicle = *