Tagging: Versenkbarer Poller

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.

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.

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)

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. :sunglasses:

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. :wink: 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.

Eigentlich sind die Klammern ja nicht nötig.

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,30@fog

Die Syntax klappt auch ohne. Und was man nicht angeben braucht, kann man nicht falsch machen.
Leerzeichen sollten erlaubt sein (Lesbarkeit) aber auch fehlen dürfen.

alle Spaces raus, split1 bei “,”, split2 bei “@” und schon hat man die Komponenten.

oder soll man hier Zeiten in allen Formaten von opening_hours angeben können? Dann kommt man wohl doch nicht um die Klammen rum. Aber nur, weil bei opening_hours ja ebenfalls Kommata und Semikolons verwendet werden.

Gruss
Walter

Hallo Walter

Ich fühle mich bei der Syntax mit Klammern wohler. Wenn man obligatorisch Klammern um die Bedingung setzt (so ist das glaube ich vorgesehen), kann natürlich das “@” als Trenner entfallen.

Wie auch immer ist die letztlich gewählte Syntax natürlich eine geringfügige Kleinigkeit.

Edbert (EvanE)

Bei den oben genannten Beispielen sind die Klammern eigentlich überflüssig. Für die Zeiten wird allerdings die Opening-Hours-Syntax übernommen, d.h. es kann in manchen Fällen eine Klammer notwendig sein. Das Proposal erwähnt ebenfalls, dass Klammern nur dann unverzichtbar sind, wenn ein Semikolon in der Bedingung vorkommt, aber empfiehlt, sie bei komplexeren Bedingungen einfach routinemäßig zu setzen.

Zusätzliche oder fehlende Leerzeichen sollten übrigens in der Tat keinem robust gebauten Parser etwas ausmachen. Das ist eher eine Frage der Lesbarkeit.