Am 05.09.2012 23:04, schrieb Tirkon:
Sven Geggus <li...@fuchsschwanzdomain.de> wrote:
Da das nicht die einzige Schranke solchen Typs ist, könnte man ein Tag
"barrier=normally_open_lift_gate" nutzen.
-1
Wir mappen genausowenig für kaputte routing engines wie wir für den renderer
mappen!
Ich habe nur deshalb "normally_open_lift_gate" vorgeschlagen, weil es
genau dasjenige ist, was wir in der Wirklichkeit vorfinden. Du musst
ja der Anwendung wenigstens die Chance geben, über den Zustand
"normally open" informiert zu sein. Das access Tag regelt im
verbreiteten Gebrauch von OSM den Zugang bei geschlossener Schranke
und nicht bei offener. Denn dann gibt es keine durch die Schranke
verurachte Zugangsbeschränkung. Ist die Schranke also "normally
closed", muss der Router sperren und ist deswegen nicht kaputt.
Lediglich sofern ein access angegeben wurde, soll er diesen auch bei
geschlossener Schranke zulassen. Dass die Router und Navis bei dem
Gebrauch von "barrier=normally_open_lift_gate" ohne weitere Eingriffe
richtig reagieren, ist somit nur ein schöner Nebeneffekt. Ich habe
hierfür korrekt und nicht bewusst falsch gemappt, um eine gewünschte
Reaktion zu erzwingen.
Eine Unterscheidung "Ereignisgetriggerte-" von
"Berechtigungsgetriggerte-" Barriere hätte was...
Schranken an Mautstellen, Parkhäusern müsste man dabei unter
"Ereignisgetriggert" (Ereignis = bezahlen) einordnen.
Ereignis:
Tunnelstörung/Unfall,
Lawinengefahr/Wintersperre,Hochwasser,Nutzungsgebühr entrichtet,
Berechtigung:
Uhrzeit, Fahrzeugkategorie, Personenkategorie (Anlieger, Werkszugehöriger,)
Dabei sollte sich der key deutlich unterscheiden um bei
"Ereignis"-Barrieren grundsätzlich von einer Durchfahrtmöglichkeit
ausgehen zu können soweit
keine anderen, externen Informationen vorliegen.
Garry
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
