Wie am besten Barriere markieren? Nach Erscheinung oder Funktion?

Monstrukt · 2009-09-21T00:19:57.000Z

Hallo, ich habe folgenden Konflikt:

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?

Hobby_Navigator · 2009-09-21T07:18:19.000Z

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…

Georg

Nop · 2009-09-21T08:26:24.000Z

Hobby Navigator:

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.

aighes · 2009-09-21T10:03:00.000Z

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?

Tordanik · 2009-09-21T10:33:34.000Z

Hobby Navigator:

also in den Feature gibt es barrier=block bisher noch nicht, was aber nicht bedeutet das man es gar nicht verwenden darf.

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.)

Monstrukt:

Wie würdet ihr entscheiden? Nach Erscheinungsbild oder nach Funktion?

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).

Lars_Vegas · 2009-09-21T21:35:37.000Z

Hallo,

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)

gruß, lars

de_muur · 2009-09-22T05:57:31.000Z

Lars Vegas:

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.

Gruss
Torsten

de_muur · 2009-09-22T05:57:48.000Z

Lars Vegas:

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.

Gruss
Torsten

AlphaRay · 2009-09-22T06:37:35.000Z

Morgen,

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.

Gruß
Paul

aighes · 2009-09-22T07:02:03.000Z

Ich würde mich auch nicht unbedingt auf die Form stürzen, die im wiki abgebildet ist.

Monstrukt · 2009-09-22T17:18:43.000Z

Hallo vielen Dank für eure Kommentare und Anregungen.

Ich kennzeichne es jetzt als barrier=bollard und setze noch bicycle=yes und foot=yes.

access=no setze ich nicht, dass leitet sich ja automatisch aus der Barriere ab, ich mache es also genau nach der wiki-Beschreibung.

Ich war nur etwas verunsichert, weil ich noch sehr neu bei OSM bin, und Angst habe, vielleicht etwas falsch zu machen.

aeonesa · 2009-09-22T17:26:14.000Z

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

Gruß

Volker

de_muur · 2009-09-23T07:10:28.000Z

Monstrukt:

access=no setze ich nicht, dass leitet sich ja automatisch aus der Barriere ab, ich mache es also genau nach der wiki-Beschreibung.

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.

Gruss
Torsten

W_G · 2009-09-23T09:14:54.000Z

de_muur:

Monstrukt:

access=no setze ich nicht, dass leitet sich ja automatisch aus der Barriere ab, ich mache es also genau nach der wiki-Beschreibung.

Also ich finde auf der Wiki-Seite eigentlich nichts, dass das access=no automatisch fuer eine Barriere definiert.

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.

Kann ein access=no nicht auch eine “rechtliche Barriere” sein (Betreten verboten)?
Dann macht das schon Sinn es getrennt zu erfassen.

AlphaRay · 2009-09-23T21:17:23.000Z

Monstrukt:

Hallo vielen Dank für eure Kommentare und Anregungen.

Ich kennzeichne es jetzt als barrier=bollard und setze noch bicycle=yes und foot=yes.

access=no setze ich nicht, dass leitet sich ja automatisch aus der Barriere ab, ich mache es also genau nach der wiki-Beschreibung.

Ich war nur etwas verunsichert, weil ich noch sehr neu bei OSM bin, und Angst habe, vielleicht etwas falsch zu machen.

Das ist doppelt. Bei Pollern brauchst du natürlich nicht anzugeben dass Fußgänger und Radfahrer durch können
Einfach nur barrier=bollard…fertig

Tordanik · 2009-09-23T21:50:11.000Z

AlphaRay:

Das ist doppelt. Bei Pollern brauchst du natürlich nicht anzugeben dass Fußgänger und Radfahrer durch können
Einfach nur barrier=bollard…fertig

Angesichts der letzten Diskussionen im Wiki bin ich der Ansicht, dass man nur sicher fährt, wenn man sich auf überhaupt keine Implikation verlässt.