[Talk-de] Offene Schranken

Garry GarryD2 at gmx.de
Do Sep 6 07:27:36 UTC 2012


Am 05.09.2012 23:04, schrieb Tirkon:
> Sven Geggus <lists at 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






Mehr Informationen über die Mailingliste Talk-de