opening hours und Router

Communities Deutschland (Germany)
1

Nachdem ich grad mal wieder ein paar gates mit opening_hours versehen habe, frage ich mich, ob es eigentlich schon praxistaugliche Router gibt (OSM-basiert oder nicht), die solche Informationen nutzen. Es gibt wohl Router die tageszeitabhängig Hauptstrecken meiden. Aber gibt es auch Router, die tatsächlich

  1. nachts geschlossene Parks,

  2. im Winter geschlossene Passstraßen,

  3. nur zu bestimmten Zeiten verkehrende Fähren,

  4. nach Tageszeit wechselnde Höchstgeschwindigkeiten,

  5. nach Tageszeit wechselnde Einbahnstraßen,

  6. nächtliche Verbote für Motorradfahrer,

  7. Wochenendbefahrverbote von Ausflugsstraßen,

  8. etc.

berücksichtigen?
2

Eine mir bekannte Straße mit Nachtfahrverbot wird derzeit von Osmand gemieden. Ich schau morgen vormittag nochmal nach, ob sie dann genutzt wird :slight_smile: Aber Osmand wertet opening_hours auf jeden Fall relativ zur aktuellen Zeit aus, z.B. zeigt er die Öffnungszeiten in den POI-Eigenschaften rot bzw. grün an.

–ks

3

Das eine hat mit dem anderen nichts zu tun. In der Osmandgruppe https://groups.google.com/forum/#!forum/osmandwurde so etwas mal diskutiert. Einfach mal nachschauen.

Wenn die lookups.dat von brouter der einzige Indikator für solche Fragen ist, dann beachtet brouter das auch nicht.

4

IMHO ist das direkte Tagging mit opening_hours bei Barrieren, Strassen etc. so oder so falsch, dass müsste, wenn schon, mit conditional restrictions + opening hours passieren.

5

+1. Also access=no + access:conditional=yes@(von-bis)

–ks

6

Wenn da auch verboten ist langzulaufen, dann ja.

7

In meinem Beispiel ist es das, ansonsten versteht sich das „access“ natürlich als Platzhalter für die entsprechenden Schlüssel.

–ks

8

Ihr habt recht, conditional access ist besser als opening_hours. Werde mein bisheriges tagging dahingehend mal überprüfen. Ändert aber nichts an meiner grundsätzlichen Frage oben.

@kreuzschnabel: konntest du das heute Vormittag in Osmand überprüfen? Ist die Strecke denn mit access:conditional getaggt?

9

Die Strecke ja, aber eines der Tore, die sie abschließen, war noch etwas umständlich getaggt, das habe ich heute morgen erst geändert. Es geht um

http://www.openstreetmap.org/way/29273329
http://www.openstreetmap.org/way/35976992
http://www.openstreetmap.org/way/34317690
http://www.openstreetmap.org/way/41215735

… mit der zusätzlichen Erschwernis, dass keine festen Uhrzeiten getaggt sind. Aber lokale Sonnenauf- und -untergangszeiten sollte ein Smartphone ja ermitteln können :slight_smile:

Baulich handelt es sich um reinste Tracks (grade2 und grade1), rechtlich sind es Privatwege, sie sind aber tagsüber für Verkehrsarten bis einschließlich PKW öffentlich nutzbar (daher permissive). Über Nacht werden die Tore dichtgemacht.

–ks

10

GraphHopper unterstütz conditional tags nur falls es mehrerer Tage sind also bei Langzeitbaustellen oder “im Winter geschlossene Passstraßen”

11

Viele Router die sehr schnell sind haben das Prinzip, dass sie, vereinfacht gesagt, auf statisch stark vor-optimierten Daten routen (Stichwort: Contraction Hierarchies). Das macht die einzelne routing-Anfrage sehr schnell, verträgt sich aber schlecht mit tags, die für jede Anfrage dynamisch ausgewertet werden müssten. Andere Router sind sehr flexibel z.B. BRouter. Bei dem lassen sich alle Bedingungen noch zur Laufzeit flexibel anpassen, da dauert eine einzelne Anfrage aber auch ca 1000 mal so lang. GraphHopper kann meines wissens nach beides, nutzt aber standardmäßig Contraction Hierarchies.

12

Ja, genau. Und demnächst führen wir einen neuen Algorithmus ein der eine Art Hybrid ist (etwas langsamer aber fast genauso flexible wie der normale A*). Auch gibts im latest master public transit routing was ja standardmäßig zeitabhängig ist und davon wird das Straßenrouting auch demnächst was abbekommen.