destination_sign relation

Hallo zusammen,

hab mich mal etwas mit der destination_sign Relation befasst https://wiki.openstreetmap.org/wiki/Relation:destination_sign. Dazu hätte ich zwei Fragen: Gibt es aktuell Software, die diese auswertet und woran merkt der Router, für welches Verkehrsmittel die Beschilderung ist?

Für welches Verkehrsmittel das Schild Bedeutung hat, ließe sich eventuell aus der Rolle sign in der Relation rekonstruieren. Denn das ist die Node mit dem Wegweiser und dort kann dann beispielsweise hiking=yes oder bicycle=yes dranstehen (wobei Wegweiser, die Schilder für verschiedene Verkehrsmittel tragen, dann getrennt gemappt sein müssten).

Dass es aber außer dem im Wiki unten verlinkten Demotool derzeit nennenswerte Auswertungen gibt, würde ich mal bezweifeln. Allerdings ist es natürlich für Wanderwegweiser viel besser, als die unter information=guidepost sinnloserweise vergebenen “Freitextfelder” direction_xyz. Denn die Information aus der destination_sign-Relation ist zumindest auswertbar, während die direction-Angaben weder bezüglich Syntax, noch bezüglich Zuordenbarkeit eindeutig zu verarbeiten sind.

… und wenn ihr in dem Tool Fehler findet oder Verbesserungsvorschläge habt, lasst es mich wissen.
Der ideale Platz für eine sinnvolle Anwendung wäre natürlich eine Karte wie https://hiking.waymarkedtrails.org
Dafür muss sich nur noch jemand finden, der das miteinander verheiraten kann.

Ja, so sollte es gehen. Fahrrad und Wandern zu vermischen würde ich noch nicht mal für so schlimm halten, aber wenn sich Autofahrer plötzlich nach Schildern führ Fahrräder oder umgekehrt umsehen müssten würde das wohl nicht funktionieren. Das ist aber kaum zu befürchten, da die Wegweise immer gut getrennt sind. Das bisherigen destination mapping ist leider sehr Auto-Zentriert.

Ich muss zugeben, dass ich nicht mal das Tool kannte, da ich nur die deutsche (offenbar stark veraltete) Übersetung gelesen hatte und nicht die von mir verlinkte Seite. Das Tool hilft schon sehr weiter.

Ich halte es auch für die einzig brauchbare Methode, Schilder für Fahrradrouten auswertbar zu mappen.

Das Tool ist schon sehr hilfreich. Ich finde Die Sektion in der die Ziele Aufgelistet sind schwer verständlich. Die Richtung der Pfeile ist immer von der Richtung aus der man kommt bezogen oder? Ich finde das nicht sehr intuitiv. Entweder sollten die Richtungen absolut sein, oder das sonst irgendwie besser verdeutlicht werden. Gut wäre, wenn die Ziele in einer Richtung nach Entfernung sortiert würden, da das auf den Wegweisern meist auch so ist.

Eine andere Frage zu dieser Relation: Laut wiki soll die Farbe des Hintergrundes, der Beschriftung und des Pfeils angegeben werden (übrigens ließe sich vielleicht auch daran ableiten, an wen sich der Wegweiser richtet). Allerdings gibt es ja auch solche Wegweiser wiw das im wiki https://wiki.openstreetmap.org/wiki/DE:Relation:destination_sign als Beispiel abgebildete. Wie soll man denn da die Farbe des Pfeils kennzeichnen? Da ist ja das Schild selbst der Pfeil.

Schau mal auf das zweite “Optionshäkchen”. “Show as seen from from way”. Voll farbige Pfeile sind immer Himmelsrichtungen. Leere Pfeile sind immer wie man es in der darüber klein angegebenen Reiserichtung sieht.

Sortieren kann ich da sicher noch, das ist ja kein großes Problem.

Ok, wenn man es einmal verstanden hat, ist es gut zu benutzen. Sehr informativ und nützlich. Hat immer man wieder kleinere Fehler. Immer mal wieder verschwindet die linke Seite mit den Informationen und man muss neu laden. Momentan tauchen bei mir keine Marker auf der Karte auf, wenn ich zu einem anderen Ausschnitt wechsel.

Stimmt, das Problem ist, dass sich dieses Leaflet-AddOn, das ich da benutze, verrennt und zu viele Anfragen startet und nicht beendet. Sieht man schön in der Konsole vom Browser. Hat da jemand Ahnung wie man das richtig aufsetzt und kann helfen?

Und wenn ich nicht raten soll, ob es sich hier um Autopista handelt, lass es mich wissen.

Nein Walter, der Link im Wiki führt dich zu meinem Machwerk: http://osm.mueschelsoft.de/destinationsign/example/index.htm

aha: der Link in #1 zeigt nach https://wiki.openstreetmap.org/wiki/Relation:destination_sign und deine Software wird nur auf https://wiki.openstreetmap.org/wiki/DE:Relation:destination_sign erwähnt. :frowning:

Toll, da muss man erstmal drauf kommen. Nun denn, jetzt kann ich mir das Teil mal ansehen.

Gruss
walter

aha LayerJSON - nie was von gehört.

ich nehme als erstes Funktionen, die direkt von Leaflet kommen, danach die auf der Leaflet Pluginseite aufgelisteten und sonst keine.
Dann schreib ich den Ajax-Request lieber selber.

Zu LayerJSON mag und kann ich nix sagen.

Momentan bekomme ich auch öfter:

Software error:
malformed JSON string, neither tag, array, object, number, st

Die deutsche Übersetzung davon lautet: “Server hat keine Daten von Overpass erhalten.” Das muss ich noch ordentlich als Meldung ausgeben.

DoppelPost :rage:

Um diese Meldung seltener zu bekommen, würde es eventuell auch helfen, statt auf http://overpass-api.de/api/interpreter lieber auf den Alternativserver http://overpass.osm.rambler.ru/cgi/interpreter zuzugreifen. Denn overpass-api.de wird fast überall als Standardserver verwendet und ist damit sehr häufig überlastet. Wenn man nicht wegen des Zugriffes auf Attic-Data gezwungen ist, diesen Server zu verwenden, sollte man lieber einen anderen nehmen.

Da macht sich wohl eher das Rate Limiting bemerkbar, das Resourcen fair verteilen soll und ab einem gewissen Punkt mehrfache Queries mit einem Too Many Requests ablehnt. Unter http://overpass-api.de/api/status sieht man, wie lange man warten darf…

Rambler hängt übrigens meistens ein paar Stunden hinterher, vielleicht nicht die erste Wahl, wenn man minutenaktuelle Daten will. Auch sind die Antwortzeiten dank Festplatte meistens länger.

Mir ist übrigens gerade noch ein Ungenauigkeit in Relation:destination_sign aufgefallen: Die Rolle intersection sollte nicht optional, sondern verpflichtend sein, auch wenn from als Rolle gesetzt ist.

Grund dafür ist folgender: Die Wege from und to können sich in exotischen Fällen an beiden Endpunkten berühren (Weggabelung, die später wieder zusammen führt). In dem Fall ist es nicht möglich, die intersection, zu der die Relation gehört, automatisch zu ermitteln. Nebenbei sind eindeutige Vorgaben bezüglich der Auswertung besser als verschiedene Optionen.

Meiner Meinung nach ist diese Flexibilität genau das, was wir für diese Relation brauchen. Das liegt daran, dass wir damit sehr unterschiedliche Schildarten erfassen: Entfernungstafeln an Autobahnen (bei denen es gar keine intersection gibt, weswegen mancher “via” verwendet), Wegweiser an Straßenkreuzungen (die in der Regel ein from brauchen, weil sie entsprechend ausgerichtet sind) und Wegweiser an Wegen (für die from in der Regel keinen Sinn macht). Den Fall mit der Weggabelung halte ich eher für die ganz große Ausnahme - da muss man dann eben entsprechend sinnvoll wählen und z.B. als from/to keinen Weg sondern einen Knoten benutzen, dann gibt es kein Problem, auch ohne intersection.
Es hat mich zwar etwas Arbeit gekostet, die verschiedenen Möglichkeiten richtig zu interpretieren, aber eigentlich ging es ohne größere Probleme. Das meiste hing nur an ein paar abstrusen Sonderfällen die ich natürlich auch abfangen wollte.

In die technischen Probleme mit meinem Tool schaue ich am Wochenende rein und schreibe noch etwas dazu.

Auch dort gibt es einen Punkt auf der Autobahn, auf den sich der Wegweiser bezieht, ab dem also die Entfernungen gelten. Und der ist dann als intersection zu mappen.

Natürlich ist das die Ausnahme. Aber letztlich sollte eine Spezifikation sämtliche Wegemöglichkeiten abdecken. Die Lösung mit den Knoten hilft übrigens in der Form nicht. Denn dann müsste die Zusatzbedingung lauten, dass der Knoten näher zur gemeinten Kreuzung liegen muss, sonst gewinnt man nichts. Nebenbei frage ich mich gerade, warum für from und to überhaupt Knoten zulässig sein sollen. Das ist nur eine weitere Flexibilität, die Auswertungen unnötig verkompliziert.

Und sie ist übrigens auch aus Sicht der eintragenden Nutzer nicht hilfreich. Denn mit den Abbiegebeschränkungen hat man eigentlich schon etwas Etabliertes, was viele kennen und was vor allem sehr ähnlich funktioniert. Warum also das Rad mit unnötigen Freiheitsgraden neu erfinden, wenn man sich dort Anleihen nehmen kann? Damit haben es Auswerter und auch eintragen Nutzer viel leichter, wenn sie mit bekannten Strukturen operieren (was sich auch daran zeigt, wenn du schreibst, dass die Nutzer bei Autobahnschildern statt intersection die Rolle via verwenden - weil sie das kennen).

Wenn Sonderfälle überhaupt auftreten, spricht das nicht gerade für die Spezifikation. Das sorgt nur dafür, dass Auswertungen unterbleiben, weil die nötige Implementierungskomplexität zum Abfangen all dieser Fälle zu groß ist.