Ich würde gerne eine Barriere kennzeichnen, und zwar einen Poller aus Beton (NICHT so einen zum umlegen zum Durchlassen von Rettungsfahrzeugen etc.).
Ich tue mich nun schwer damit, ob ich ihn lieber als Steinblock (barrier = block) kennzeichen soll (um auszudrücken, dass es sich um ein immobiles Objekt handelt, das nur mit großem Aufwand und/oder Spezialgerät überwunden werden kann) oder einfach schlicht als Poller, was mehr der Form und dem Aussehen entspricht.
Für Rettungskräfte ist es ja durchaus interessant, zu wissen ob ein Weg im Notfall passierbar gemacht werden kann, indem man z.B. einen Poller umlegt, oder ob es sich wirklich um ein unüberwindbares Hindernis handelt.
Wie würdet ihr entscheiden? Nach Erscheinungsbild oder nach Funktion?
Hallo, also in den Feature gibt es barrier=block bisher noch nicht, was aber nicht bedeutet das man es gar nicht verwenden darf. Wobei es dann als neues Feature mit Erklärung, eingefügt werden sollte.
Deine Gedanken sind durchaus schlüssig, wobei die “Rettungskräfte” in der Regel ortskundig sind und wissen wo sie den Poller rausnehmen können, die Schranke aufschließen und wo dies nicht geht.
Ich würde barrier=block verwenden und es in die Feautures einfügen…
Ich würde es keinesfalls mal eben schnell in die Features einfügen, nur weil es einer einmal benutzt hat. Für neue Features gibt es einen Proposal-Prozess, bei dem meist noch einiges an Argumenten dafür und dagegen zu Tage kommt.
Ich halte die Verwenung von block für einen nicht beweglichen Poller für zu kurz gegriffen. Dieselbe Problematik betrifft auch andere Hindernisse und sollte einheitlich geregelt werden. So ist es z.B. bei einer Schranke oder einem Tor genauso interessant, ob es geöffent werden kann oder versperrt ist.
Mögliche Arten damit umzugehen sind: Andere Tags (block, locked_gateIMHO die schlechteste Variante), zusätzlcihe Tags die das näher beschreiben oder eine Darstellung mit access-Tags, wer durchkommt und wer nicht.
Ich würde hier Nop zustimmen. Eine Barriere behindert das Durchkommen von Verkehrsteilnehmern. Wer durch kommt und wer nicht regeln dann die access-Parameter, wobei ein access=no wohl default ist, oder?
Es war Bestandteil des barrier-Proposals, steht auf Key:barrier und hat eine eigene Seite im Wiki. Ich glaube, das kann man im Allgemeinen guten Gewissens verwenden. (Womit ich nicht sagen will, dass es hier das richtige Tag ist.)
Da “Funktion” im wesentlichen “Zugangsrechte” bedeutet, und diese abgesehen von den Implikationen ohnehin mit zusätzlichen Tags ausgedrückt werden können und müssen, würde ich mich an der Form orientieren. Wenn das Ding ein nicht beweglicher Poller ist, ist es zunächst einmal barrier=bollard. Das “nicht beweglich” ist eine Zusatzeigenschaft, die man als Extra-Tag ausdrücken kann. Jemand hat z.B. mal für Bänke moveable=yes/no vorgeschlagen (alternativ permanent=no/yes).
ich habe ein ähnliches Problem: Bei uns in der Nähe gibt es einen Straßenabschnitt, der zwischen zwei Kreuzungen gesperrt ist. Dafür wurden rechts und links auf der Fahrbahn zwei Pfosten in die Straße betoniert und so ein rot-weiß-gestreiftes “Blechbrett” drangeschraubt. D. h. die Straße ist wirklich zu. Bis auf einen Meter an einer Seite, der für Fahrräder explizit per Fahrbahnmarkierung freigegeben ist. Fußgänger können nach wie vor auf dem Gehweg auf beiden Seiten vorbei.
barrier=bollard wäre solide genug, bezieht sich aber eigentlich auf Pfosten (siehe Wiki)
Ich glaube nicht, dass jemand an bollard Anstoss nehmen wuerde (das Wiki will bei mir momentan nicht, so dass ich alleridngs nicht ueberpreufen kann, ob irgendwas anderes etabliertes vielleicht besser passen wuerde). Es scheint mir auf alle Faelle sinnvoller, als irgend ein neues Tag zu erfinden, was keiner kennt.
Dazu wuerde ich dann access=no, bicycle=yes und foot=yes setzen, damit auch eindeutig beschrieben ist, welche funktionelle Einschraenkung die Barriere darstellt. Auf irgendwelche Defaults wuerde ich da nichts geben, bei einem freien Projekt wie OSM kann sich das viel zu leicht aendern. Also lieber die Sachen direkt und eindeutig markieren.
Ich glaube nicht, dass jemand an bollard Anstoss nehmen wuerde (das Wiki will bei mir momentan nicht, so dass ich alleridngs nicht ueberpreufen kann, ob irgendwas anderes etabliertes vielleicht besser passen wuerde). Es scheint mir auf alle Faelle sinnvoller, als irgend ein neues Tag zu erfinden, was keiner kennt.
Dazu wuerde ich dann access=no, bicycle=yes und foot=yes setzen, damit auch eindeutig beschrieben ist, welche funktionelle Einschraenkung die Barriere darstellt. Auf irgendwelche Defaults wuerde ich da nichts geben, bei einem freien Projekt wie OSM kann sich das viel zu leicht aendern. Also lieber die Sachen direkt und eindeutig markieren.
ein Poller ist ein Poller…ob der jetzt aus Metall, Holz oder Beton ist ist völlig egal…hauptsache hier wird gesagt bzw. vom Navi erkannt: Autos dürfen hier nicht durch! Ob der herausnehmbar ist oder fest ist total egal - weil der nicht feste nicht einfach so entfernt werden kann und somit genauso ein festes Hindernis ist.
barrier=block gibt es in den Vorlagen von JOSM und wird in JOSM auch als Betonklotz dargestellt. In Osmarender ist es halt ein Poller. Aber wir mappen ja sowieso nicht für die Renderer. Wenn es später einer auswerten will, ist es schon in der Karte. Macht schon Sinn zu wissen, wo ein Poller mit Sollbruchstelle und wo eine “Panzersperre” ist
Also ich finde auf der Wiki-Seite eigentlich nichts, dass das access=no automatisch fuer eine Barriere definiert.
In den angegebenen Beispielen wird es zwar nicht gesetzt, aber es ist auch nicht unter “implies” angegeben. Allgemein macht es auch nicht fuer alle barrier-Tags Sinn, es gibt ja z.B. auch barrier=entrance. Und auch bei den Linienbarrieren kann eine Nutzung entlang der Linie durchaus erlaubt/moeglich sein, die Barriere wirkt da ja eher senkrecht zur Linie.
Auf der anderen Seite tut es auf alle Faelle niemanden weh, wenn man das access=yes explizit setzt, obwohl es eigentlich nicht noetig gewesen waere.
