Tagging: Versenkbarer Poller

Wolfgang B · 2012-08-24 18:05:45

Wie tagge ich einen automatisch versenkbaren Poller? Auf der zugehörigen Straße ist zwischen 20:00 und 6:00 der Autoverkehr verboten. In dieser Zeit wird der in der Straße eingelassene Poller automatisch hochgefahren.

yzemaze · 2012-08-24 19:02:59

barrier=bollard
bollard=rising

Q: Key:bollard

chris66 · 2012-08-24 19:05:44

Da fehlen dann noch die zeitabhängigen access Tags.

Und da kein OSM Router zeitabhängig routen kann muss man sich überlegen ob man da defaultmäßig das Routing sperren
will oder nicht.

Wolfgang B · 2012-08-25 16:19:47

"bollard=rising" kannte ich noch nicht, habe es ergänzt. Leider sieht man hier wieder, wie wirr das Wiki aufgebaut ist. Es gibt einen Eintrag zu barrier=bollard und einen zu bollard allein.
Die Zeitangaben habe ich versucht, mit hour_off/on anzugeben (auch auf dem zugehörigen Straßenabschnitt). Ob und wie es ein Router auswertet - wir taggen nicht für ...
Nachsatz: Ich bin für weitere Ideen zu diesem Thema offen.

KaChing_Cacher · 2012-08-25 16:52:42

chris66 wrote:

Und da kein OSM Router zeitabhängig routen kann muss man sich überlegen ob man da defaultmäßig das Routing sperren
will oder nicht.

Meine Herren ... Dann müssen sie es halt lernen!

EvanE · 2012-08-25 17:00:35

Wolfgang B wrote:

"bollard=rising" kannte ich noch nicht, habe es ergänzt. Leider sieht man hier wieder, wie wirr das Wiki aufgebaut ist. Es gibt einen Eintrag zu barrier=bollard und einen zu bollard allein.
Die Zeitangaben habe ich versucht, mit hour_off/on anzugeben (auch auf dem zugehörigen Straßenabschnitt). Ob und wie es ein Router auswertet - wir taggen nicht für ...

Das geht schon in Ordnung mit den zwei verschiedenen Seiten.
bollard=rising/removable ist eine genauere Beschreibung eines spezifischen Wertes (barrier=bollard) des allgemeinen Schlüssels barrier, für den es eine Vielzahl von linearen (Zäune, Hecken, Ketten, ...) und punktuellen Werten (diverse Tore, ...) gibt.

So ist die normale und und in diesem Fall systematische Vorgehensweise im OSM-Wiki.

PS:
Es gibt zudem noch Barriers mit weiteren Erläuterungen zur Anwendung. Da sind die Einträge nach einer anderen Systematik sortiert und Rendering-Vorschläge für alle beschriebenen Werte enthalten.

Edbert (EvanE)

chris66 · 2012-08-25 17:04:00

KaChing_Cacher wrote:

Dann müssen sie es halt lernen!

Ist nicht trivial. Würde mich mal interessieren wie die kommerziellen Navis dort routen.

Wolfgang B · 2012-08-25 18:20:40

Mangels eines kommerziellen Routers kann ich das nicht sagen. Gockel und Bingobongo fahren jedenfalls drüber, aber auch Openrouteservice, yournavigation und die Cloudmade Maps erkennen den Poller, obwohl eingezeichnet, nicht. Aber er ist auch erst seit gestern in der Datenbank.

scai · 2012-08-25 18:24:13

Ganz und gar nicht trivial würde ich sagen, in der Regel weiß man nicht mal wann man dort vorbei kommen wird. Klar hat man eine ungefähre Ankunftszeit, aber die kann sich unterwegs auch ändern. Und dann gibt es noch vorgefertigte Routen als GPX, die sowas gar nicht erst unterstützen. Das reicht demnach von "geht überhauptnicht" bis "geht wahrscheinlich, vielleicht aber auch doch nicht".

Ich nehme mal an dass der größte Autoverkehr außerhalb von 20-06 Uhr stattfindet, so gesehen könnte man es standardmäßig frei geben. Man könnte aber auch motor_vehicle=destination missbrauchen, wenn es sich nur um einen kleinen Bereich handelt. Von der Bedeutung her dürfte das zumindest etwas ähnlich sein. Sind natürlich leider alles nur Krücken.

Dennis[B] · 2012-08-25 18:35:59

Nur weil die Router das noch nicht können, sollte man das aber nicht falsch Taggen. Dann lernen es die Router nie, weil es keine Beispiele und kein Bedarf gibt.

Taggt man es jetzt richtig, besteht für die Router Bedarf. Und die können so etwas dann lernen. Zeitabhängiges Routing ist eigentlich überall wichtig, wie viele Schilder haben Zeitbeschränkungen drauf.

Tordanik · 2012-08-25 20:00:50

Dennis[B] wrote:

Nur weil die Router das noch nicht können, sollte man das aber nicht falsch Taggen. Dann lernen es die Router nie, weil es keine Beispiele und kein Bedarf gibt.

Die ursprüngliche Anregung war ja auch nicht, es falsch zu taggen. "Hier ist Autoverkehr erlaubt, außer zwischen 20:00 und 6:00" und "hier ist Autoverkehr verboten, außer zwischen 6:00 und 20:00" sind beispielsweise beide richtig und würden von einem perfekten Router daher auch identisch behandelt. Der Unterschied ist nur, wie die heute existierenden Router damit umgehen. Und es ist nicht nur erlaubt, sondern auch durchaus sinnvoll, das in seine Überlegungen einzubeziehen.

chris66 · 2012-08-25 20:04:40

Genau, und ich persönlich würde mich da vom Verkehrsaufkommen leiten lassen, mich also fragen, wieviele Fahrzeuge
wollen wohl den Weg zwischen 6:00 und 20:00 Uhr, und wieviele zwischen 20:00 und 06:00 Uhr nutzen.

fkv · 2012-08-25 20:22:18

Wolfgang B wrote:

In dieser Zeit wird der in der Straße eingelassene Poller automatisch hochgefahren.

Das finde ich gefährlich. Was ist, wenn in dem Moment grad ein Kinderwagen dort steht? Also da scheint mir ein hazard=* angebracht.

Dass drüber geroutet wird, ist vertretbar. Im schlimmsten Fall muss man halt 10h warten, bis man weiterfahren kann. Der Unterschied zu einer Ampel oder einem Bahnübergang ist nur quantitativ.

Fabi2 · 2012-08-25 20:35:07

Ich würde da opening_hours=* taggen, dann ist klar wann da offen ist. Was dann irgendwelche Router draus machen, muß man sehen, die nötigen Infos, wann man da durch kann, sind dann jedenfalls erfaßt und das Problem hier an den Routern, sie auch auszuwerten. Deswegen würde ich nicht den subjektiv empfundenen überwiegenden Zustand als access=* erfassen, weil das wäre ja dann Tagging für den Router.

Wolfgang B · 2012-08-26 09:43:24

Bedeutet "opening_hours" nicht Öffnungszeiten?

Über "hazard" könnte man durchaus nachdenken. Allerdings steht am linken und rechten Straßenrand ein Warnlicht, das wie bei einem Bahnübergang vorher zu blinken beginnt. Bei einem Bahnübergang taggen wir auch nicht das "hazard".

Warten muss man nicht, man kann auch umkehren und einen anderen Weg wählen, schlimmstenfalls über die Umfahrungsstraße des Ortes. Das Gebiet ist ohnehin verkehrsberuhigte Zone mit Fahrverbot von 22:00 bis 6:00, nur bei dieser Straße beginnt das Fahrverbot schon um 20:00.

chris66 · 2012-08-26 10:02:17

Wolfgang B wrote:

Bedeutet "opening_hours" nicht Öffnungszeiten?

Im Prinzip ja.

Wiki (access):
A more flexible solution for time-dependent tagging is using access:<opening_hours value>=* as proposed by Extended conditions for access tags.

Ich vermute, dies hat Fabi2 gemeint.

Das wäre dann sowas wie: motorcar:(20:00-06:00)=no

Wolfgang B · 2012-08-26 12:54:04

War das, wenn ich die access-Debatte richtig verfolgt habe, nicht in dieser Form verpönt? Müsste es nach den letzten Diskussionsergebnissen nicht motorcar:no=(20:00-6:00) heißen?

Fabi2 · 2012-08-26 13:34:33

chris66 wrote:

Wolfgang B wrote:
Bedeutet "opening_hours" nicht Öffnungszeiten?
Im Prinzip ja.
Wiki (access):
A more flexible solution for time-dependent tagging is using access:<opening_hours value>=* as proposed by Extended conditions for access tags.
Ich vermute, dies hat Fabi2 gemeint.
Das wäre dann sowas wie: motorcar:(20:00-06:00)=no

Nein, ich meinte den normalen opening_hours=*-Key, weil damit gibt man ja an, das eine Sache irgendwann geöffnet hat, also die Öffnungszeiten. Wenn man den Tag zusammen mit bollard=rising an einem Poller einsetzt, dann ist doch naheliegend, das damit die Zeit gemeint ist, in der man da die Einfahrt durchfahren kann. Die variablen Keys heiße ich nicht für gut und habe auch gegen das "Extended conditions for access tags"-Proposal gestimmt.

Last edited by Fabi2 (2012-08-26 13:35:48)

wambacher · 2012-08-26 14:02:59

Wolfgang B wrote:

War das, wenn ich die access-Debatte richtig verfolgt habe, nicht in dieser Form verpönt? Müsste es nach den letzten Diskussionsergebnissen nicht motorcar:no=(20:00-6:00) heißen?

klar, aber steter Tropfen höhlt den Stein. Wenn man es immer wieder in dieser (banned?) Form erwähnt, sickert das langsam ein. Könnte man auch als "Lobbyarbeit" bezeichnen

Gruss
Walter

Fabi2 · 2012-08-26 14:13:49

wambacher wrote:

Wolfgang B wrote:
War das, wenn ich die access-Debatte richtig verfolgt habe, nicht in dieser Form verpönt? Müsste es nach den letzten Diskussionsergebnissen nicht motorcar:no=(20:00-6:00) heißen?
klar, aber steter Tropfen höhlt den Stein. Wenn man es immer wieder in dieser (banned?) Form erwähnt, sickert das langsam ein. Könnte man auch als "Lobbyarbeit" bezeichnen

Sollen die Verfechter dieses Vorschlags es doch noch so oft erwähnen oder so taggen, das es nicht sinnvoll auswertbar ist, das wurde ihnen ja gesagt, somit dient es nur dazu, den Speicherplatzbedarf für die Datenbank zu erhöhen.

Tordanik · 2012-08-26 15:04:13

Wolfgang B wrote:

War das, wenn ich die access-Debatte richtig verfolgt habe, nicht in dieser Form verpönt? Müsste es nach den letzten Diskussionsergebnissen nicht motorcar:no=(20:00-6:00) heißen?

Die Variante hab ich noch nicht gesehen. In der Diskussion waren entweder

motorcar:(20:00-6:00) = no

nach dem alten Proposal. Oder nach dem neuen, hoffentlich Fabi2-kompatiblen, Proposal:

motorcar = no @ 20:00-6:00

Letztere Variante kann übrigens noch ein paar Tage kommentiert werden, bevor es Zeit für die Abstimmung ist.

fkv · 2012-08-26 20:25:12

Wolfgang B wrote:

Über "hazard" könnte man durchaus nachdenken. Allerdings steht am linken und rechten Straßenrand ein Warnlicht, das wie bei einem Bahnübergang vorher zu blinken beginnt.

Ok, dann ist hazard überflüssig.

Die Gemeinde muss ganz schön im Geld schwimmen, wenn sie sich so einen Aufwand leisten kann, wo ein Fahrverbot mit Zusatztafel gereicht hätte.

EvanE · 2012-08-26 20:46:07

fkv wrote:

Die Gemeinde muss ganz schön im Geld schwimmen, wenn sie sich so einen Aufwand leisten kann, wo ein Fahrverbot mit Zusatztafel gereicht hätte.

Offensichtlich reicht ein einfaches Fahrverbot nicht aus, um das durchzusetzen.
Und keine Sorge, die Gemeinden holen sich solche Ausbauten über die Anliegerkosten zurück.

Edbert (EvanE)

Wolfgang B · 2012-08-27 18:25:10

Ohne es genau zu wissen - arm dürfte die Gemeinde nicht sein. So viele Poller wie hier gibt es, glaube ich, nicht einmal in Wien. Manchmal denke ich mir, was ich mir da angetan habe: Access-Einschränkungen en masse, Parkplätze mit unterschiedlichsten Aufenhaltszeiten mit und ohne Gebühr und jede Menge Sackerl-fürs-Gackerl-Spender.

Fabi2 · 2012-08-28 23:13:22

Tordanik wrote:

Oder nach dem neuen, hoffentlich Fabi2-kompatiblen, Proposal:
motorcar = no @ 20:00-6:00
Letztere Variante kann übrigens noch ein paar Tage kommentiert werden, bevor es Zeit für die Abstimmung ist.

Diese Variante ist auf jeden Fall besser als die Alte/Andere, aber aus meiner Sicht immer noch nicht ganz optimal.

Eigentlich funktioniert eine Datenbank ja so: man hat seinen, für den Anwendungsfall eindeutig passenden Schlüssel, über den man dann die Daten zielgenau abrufen kann.

Mal angenommen, ich will als LKW-Fahrer das maxspeed=* für eine Straße wissen, dann kann ich je nach Modell entweder maxspeed:hgv:conditional=* als Schlüssel benutzen, wobei die Unterscheidung auf *:forward/backward:conditional dann als zusätzliche Info mit im Wert stehen muß (und natürlich für den Menschen länger und damit fehleranfälliger zu erfassen ist) oder man definiert von vorn herein auch: bei der Abfrage brauch ich zwingend die Fahrtrichtung und dann ist immer maxspeed:hgv:forward:conditional=* zusammen mit maxspeed:hgv:backward:conditional=* zu erfassen, aber in diesem Fall dann nie maxspeed:hgv:conditional=*.

Nach aktuellem Proposal kann man aber alle drei Varianten wahlweise und auch zusammen benutzen, was zum einem heißt, das man im Zweifelsfall 3x nach den gleichen Daten fragen muß statt 1x. Das ist aber noch nicht mal das Schlimmste, denn die Daten können auch noch inkonsistent sein:

maxspeed:hgv:conditional=80 @ wet
maxspeed:hgv:forward:conditional=50 @ (10:00-18:00), 60 @ wet
maxspeed:hgv:backward:conditional=60 @ (06:00-22:00), 50 @ (length>5)

Da weiß man doch immer, was korrekt ist. Das Problem gibts aber in OSM nicht nur hier, sondern noch öfter, was die Sache aber nicht wirklich besser macht, aber andererseits seh ich die Mapper schon über noch mehr vermeintlich nutzlose und lange Tags (z.B. health_object=* (hatte ich anfänglich aber drin)), jammern...

Natürlich kann ich auch nur Daten im Key haben, die ich zum Zeitpunkt der Abfrage zweifelsfrei weiß, denn der bekannte Key soll mir ja gerade immer die Nutzdaten für den Anwendungsfall liefern, welche ich nicht weis. Da will ich keine Schlüsselratespiele veranstalten müssen.

So, das erst mal als Hinweise von mir zum Proposal.

Last edited by Fabi2 (2012-08-28 23:36:04)

Announcement

#1 2012-08-24 18:05:45

Tagging: Versenkbarer Poller

#2 2012-08-24 19:02:59

Re: Tagging: Versenkbarer Poller

#3 2012-08-24 19:05:44

Re: Tagging: Versenkbarer Poller

#4 2012-08-25 16:19:47

Re: Tagging: Versenkbarer Poller

#5 2012-08-25 16:52:42

Re: Tagging: Versenkbarer Poller

#6 2012-08-25 17:00:35

Re: Tagging: Versenkbarer Poller

#7 2012-08-25 17:04:00

Re: Tagging: Versenkbarer Poller

#8 2012-08-25 18:20:40

Re: Tagging: Versenkbarer Poller

#9 2012-08-25 18:24:13

Re: Tagging: Versenkbarer Poller

#10 2012-08-25 18:35:59

Re: Tagging: Versenkbarer Poller

#11 2012-08-25 20:00:50

Re: Tagging: Versenkbarer Poller

#12 2012-08-25 20:04:40

Re: Tagging: Versenkbarer Poller

#13 2012-08-25 20:22:18

Re: Tagging: Versenkbarer Poller

#14 2012-08-25 20:35:07

Re: Tagging: Versenkbarer Poller

#15 2012-08-26 09:43:24

Re: Tagging: Versenkbarer Poller

#16 2012-08-26 10:02:17

Re: Tagging: Versenkbarer Poller

#17 2012-08-26 12:54:04

Re: Tagging: Versenkbarer Poller

#18 2012-08-26 13:34:33

Re: Tagging: Versenkbarer Poller

#19 2012-08-26 14:02:59

Re: Tagging: Versenkbarer Poller

#20 2012-08-26 14:13:49

Re: Tagging: Versenkbarer Poller

#21 2012-08-26 15:04:13

Re: Tagging: Versenkbarer Poller

#22 2012-08-26 20:25:12

Re: Tagging: Versenkbarer Poller

#23 2012-08-26 20:46:07

Re: Tagging: Versenkbarer Poller

#24 2012-08-27 18:25:10

Re: Tagging: Versenkbarer Poller

#25 2012-08-28 23:13:22

Re: Tagging: Versenkbarer Poller

Board footer