Breite von Barrieren

Hi,

da wir ja nun inzwischen bei einem recht hohen Detaillevel angekommen sind, habe ich mir Gedanken um Barrieren gemacht. Typen wie city_wall ( http://www.openstreetmap.org/?lat=53.120565&lon=13.496093&zoom=18&layers=M ) können ja gut und gerne mal mehrere Meter breit sein. Deswegen ist das Eintragen als einfache Linie sicherlicher nicht mehr wirklich sinnvoll. Umrande ich allerdings die Mauern, kommt im Endeffekt eine andere Aussage raus, nämlich eine Mauer, die ringförmig wäre. Wie kann ich also eine breite Barriere taggen?

Ich habe das mit der “Ringform” mal an einem Beispiel für besonders breite Hecken gemacht ( http://www.openstreetmap.org/?lat=52.392944&lon=13.05702&zoom=18&layers=M ), aber das ist natürlich nciht zufriedenstellend. Was schafft also Abhilfe?

Gruß S-Man

Spontan würde mir einfallen, solche Barrieren mit einem width=* zu versehen, das die Breite angibt. Ich denke, so ein Tag wäre die “natürlichste” Methode, die Breite von etwas anzugeben.

Wenn man wirklich die Umrisse einer Barriere mappen wollte, wie du beschrieben hast, dann sollte man dem ganzen wohl noch ein area=yes verpassen, damit klar ist, dass die Barriere die Fläche ausfüllt statt sie zu umranden. Aber ich denke, wenn die Barriere nicht gerade eine besonders komplexe Form hat, sondern im wesentlichen eine “Linie mit konstanter, endlicher Breite” ist, kommt man mit width=* einfacher zum Ziel.

Moin,

Das lässt sich ja auf das Grundproblem “OSM-Objekt kann sowohl linear wie auch flächig sein” zurückführen.

Dies wurde bisher - und wird wohl auch zukünftig bis zur Einführung eines echten Flächentyps - mit dem Zusatztag “area=yes” bei Flächen gelöst.

Aber schon die im Beispiel angesprochenen einfachen geometrischen Figuren sind keine “Linien mit konstanter Breite” mehr und erfordern ein entsprechendes Zerlegen der Struktur in Mittellinie / Richtungen / Breiten. Erfordert also deutlich mehr Gehirnschmalz beim Mapper.
Mit Luftbild ist die Fläche da wesentlich einfacher zu erfassen.

Desweiteren scheitert das dann noch ‘psychologisch’ an dem bisherigen Nicht-Rendern von width - zumal auch noch der JOSM Validator das bei barrier ‘anmeckert’.
Auch hier führt area=yes sofort zum Erfolg.

Gruß
Georg

Edit: Hochkomma ergänzt.

Kommt evtl. auch auf die Barriere an, aber bei Pollern und ähnlichen Sperren würde ich unter width die freie Breite des Weges vermuten.

Ja, die breiten sind nicht konstant. Gerade bei Stadtmauern kommen häufig Aussparungen und Erker vor…

Also einfach umranden und area=yes ran, hab ich das richtig verstanden?

Mauern und all sowas habe ich bisher immer mit height=, width= und material=* erfasst. Ich denke das kann man z.B. bei OSM2World sehr gut auswerten um eine entsprechende 3D Repräsentation zu wählen. Bei Flächen-Objekten sehe ich derzeit keine Notwendigkeit, aber vielleicht übersehe ich etwas?

Hm… Die hätte ich eher als maxwidth=* getaggt.

Stimmt, für komplexere Geometrien, die keine “breiten Linien” mehr sind, braucht es natürlich mehr als nur width=*. Da klingt ein zusätzliches area=yes vernünftig - so macht man es ja z.B. auch bei Fußgängerzonen.

Und zwar an die Strasse, nicht den Poller.

Ich stimme da mit aighes überein.
maxwidth halte ich in allen Varianten für unglücklich, da es sich dabei um eine angeordnete Beschränkung handelt. Das ist im Fall eines Pollers in der Regel nicht gegeben.

Edbert (EvanE)

Moin,

ich finde es generell ungünstig, langgestreckte und gerichtete Objekte statt als Linien nur als Flächen zu erfassen. Dadurch verliert man die Möglichkeit, die Länge aus den Daten zu ermitteln oder das Objekt im kleineren Zoomlevel als Linie zu rendern.
Wenn man wie bei Straßen und Flüssen bei Bedarf zusätzlich zur Linie auch die Fläche mit einem anderen Tag (area:highway=*, waterway=riverbank) erfasst, hat man alle Vorteile von Linie und Fläche.

Wenn für die Stadtmauer eine Linie mit mit height=* und width=* nicht ausreicht, könnte man analog zu den Straßen eine Fläche mit area:barrier=* hinzufügen.

Gruß
Stephan

width ist laut Wiki die Breite eines Weges oder anderen Features. Bei Barrieren würde ich somit unter width die Breite der Barriere verstehen.

Die mögliche Durchlassbreite tagge ich mit maxwidth:physical.

Chris

Wenn du Wert auf den Unterschied zwischen rechtlich vorgegebenem und praktisch möglichen maxwidth legst, würde ich wie chris66 in Richtung maxwidth:physical=* nachdenken (analog zu maxheight:physical=*).

width ist nach Definition die Breite des damit getaggten Features. Also an einem Poller dann doch die Breite des Pollers, nicht der Platz links und rechts daneben.

Die Tagging-Praxis scheint sich anderes entwickelt zu haben. Das ist ja nicht von mir so ausgedacht worden.

Du hast natürlich recht mit deiner Argumentation. Allerdings ist die Bedeutung von width an einem Knoten eher unklar. Wie auch immer der Vorschlag mit maxwidth:physikal gefällt mir recht gut.

An alle:
Ich habe bei einigen Wendeflächen den Durchmesser mit width=xx eingetragen, damit klar ist wieviel Platz zum Wenden dort vorhanden ist. Diameter wollte ich nicht verwenden, da die meisten Wendeflächen heutzutage eher keine (Wende)Kreise sind. Gibt es dafür ggfs. auch einen anderen/besseren Vorschlag?

Edbert (EvanE)

Moin,

wenn Du dazu area=yes taggst kann man nicht annehmen dass die Mauer ringförmig wäre.

LG,

-moenk