Treppe mit Fußweg

Es geht um diese Fußgängerzone: http://www.openstreetmap.org/way/343192974

Die Bearbeitung ist durch eine Fehlermeldung meinerseits entstanden. Daraus entstand ein Disput, ob Steps wirklich als barrier zu taggen sind. Ergebnis des Disputs, wir fragen das Forum.

Also das ganze ist archetektonisch ungewöhnlich. Der Bereich, in dem http://www.openstreetmap.org/way/343192972 gezackt wird, führt dieser Platz stufig abwärts. Also die Stufen ziehen sich über den ganzen Platz und sind sehr breit. Grobe Schätzung: 10x2x0,1m. Also wunderbar begehbar. In diese gestufte Fläche ist eine Wegführung eingebracht (Weg 343192972), sodass Radfahrer, Skater, Rollatoren und Einkaufswagen und ähnliches entlangkönnen. Breitemäßig ginge auch ein Rollstuhl. Ob das konditionsmäßig ginge, kann ich nicht sagen.

Zwischen Stufen und dem Weg gibt es keine Erhebung, wenn sie auf gleicher Höhe sind. Materialmäßig gibt es keinen Unterschied. Auf Anhieb sieht man den Weg nicht.

Meine Frage, wie taggt man die Stufen und den Weg oder diese Wegführung.

Hier ein aktuelles Proposal für breite Treppen: http://wiki.openstreetmap.org/wiki/Relation/Proposed/Area-steps

Nicht schlecht, aber die zwei Beispiele sind als Treppe erkennbar. Bei meinen Stufen beträgt, wenn man http://de.wikipedia.org/wiki/Treppenstufe#Auftritt als Terminus verwendet, der Auftritt 2 Meter oder sogar mehr. Ist das dann noch eine Treppe?

Gibt es ein Bild um sich vielleicht bildlich ein Bild zu machen? Letztendlich “glaube” ich, dein Problem verstanden zu haben, aber sicher bin ich mir nicht.

Ob barrier=step hier das richtige ist, will ich nicht beurteilen. Schlecht finde ich es nicht.

Generell würde ich empfehlen, bei barrier=* immer auch ein paar access-Regeln mitzuliefern. Im Wiki steht nämlich “impliziert access=no”. Das kann ein Auswerter in Einzelfällen ignorieren, weil es bei den einzelnen Hindernissen im Wiki anders steht (bollard z.B.), oder weil es dem Programmierer vernünfig erscheint (caddle_grid z.B. oder stile). Bei bisher unbekannten und wenig dokumentierten Werten wird aber doch gelegentlich mal auf die Vorgaben des Wiki zurückgegriffen und dann sind die Stufen unübertretbar.

Grüße, Max

Da sollte man analog zu highway=pedestrian + area=yes highway=steps +area=yes nehmen, anstatt mal wieder eine IMO unnötige Relation zu zimmern.

Das Problem ist dass eine Treppe eine Richtung hat, die man mit dem geschlossen Linienzug einer area nicht angeben kann.

Das hganze hat mitr keine >Ruhe gelassen so bin ich da heute wieder hingefahren. Hier sind ein paar Bilder, die ich gerade eben gemancht habe:
http://wiki.openstreetmap.org/wiki/File:Treppe-H.-Lübcke-Str-1.jpg
http://wiki.openstreetmap.org/wiki/File:Treppe-H.-Lübcke-Str-2.jpg
http://wiki.openstreetmap.org/wiki/File:Treppe-H.-Lübcke-Str-3.jpg

Das ganze sieht also schon eher wie eine standard Treppe aus. Die Stufen sind entgegen unserer urspünglichen Meinung zwar tatsächlich Tiefer als üblich aber “nur” 60-70cm nicht “etwa 2m” wie ursprünglich gedacht.
(Es ist schon erstaunlich wie leicht man solche Längen überschätzt. wenn man sich erst später wieder daran erinnern soll.)

Ich habe das aber jetzt auch als highway=steps+area=yes plus einer type=steps Relation mit einem weiteren (ungetaggten) way der die Aufwärts Richtung angibt umgemappt.

Allerdings ist mir noch eingefallen, wo ich kürzlich eine wie ursprünglich beschriebene Treppenanlage gesehen habe. Der als Hafentreppe benannte Platz am Ende des Offenbacher Hafenbeckens hat so tiefe Stufen.
http://www.openstreetmap.org/#map=19/50.11289/8.75418

Gruß, Micha H.

Anmerkung: In einem anderen Thread wurde darauf verwiesen, dass das zusätzliche area=yes nur für Plätze und nicht für Wege zu nehmen ist. Für letztere area:highway.

Ergo: area:highway=steps als Fläche + highway=steps als Linie.

Die steps-Relation ist neu und ich sehe keine Notwendigkeit dafür. Siehe Posting #8

Hallo,
Das grundsätzliche Problem ist ja, warum lassen sich Freitreppen nicht taggen oder rendern. Und das auch noch in Fußgängerzonen.
Ein weiteres, vielleicht nicht unwichtiges Beispiel ist die Zone “Treppenstraße, Kassel”.
Das momentane Tagging lässt jeden Ansatz außer acht, das diese “Straße” aus Treppen und Zwischenplattformen besteht.
Ich denke, da gibt es noch mehrere Beispiele, erst recht, wenn ich daran denke, wie es in den mediterannen Ländern und Altstädten aussieht.

+1 Ich denke, das Proposal wird mit diesem Ansatz auch wieder scheitern. Wer hat schon Lust, eine Relation anzulegen für eine einfache Freitreppe?

Jedoch ohne Proposal werden wir es nicht schaffen, das auch im rendering sich was tut (sowohl Mapnik wie 3D). Dafür gibt es zu viele unterschiedliche Ansätze.
Ich bin auch der Meinung, wir haben ja nun das anerkannte highway=pedestrian + area=yes. Warum macht man sich das Leben schwer?
In Verbindung mit dem 3D Tagging lässt sich auch eine Freitreppe sehr leicht zeichnen. Man braucht nur eine Hilfslinie für die Richtung.
Ansonsten wäre es mit einfachen Tags getan wie Stufenkanten (z.B. barrier=step); Anzahl der Stufen (step_count=x); Breite ergibt sich aus der Geometrie.
Das lässt sich durchaus auch in der 2-dimensinalen Mapnik darstellen.
Und am einfachsten wäre umzusetzen, den noch sehr dürftigen tag area=yes aufzuwerten auf area=“…” (steps, ramp, ??? ). Also, an Ideen soll es nicht scheitern.
Man sollte jedoch das alles nicht zu komplex darstellen… anders als z.B. im Indoor tagging.

Der Ansatz könnte doch ganz einfach sein. Es gibt ja die Idee Straßen außer als Linie auch als Fläche zu erfassen (area:highway=). Wenn man das jetzt auf Treppenanlagen überträgt wäre das einfach area:highway=steps. Analog zu 3D (roof:direction) könne man dann noch die Richtung der Treppe mit step:direction= erfassen.

Puncto schätzen war ich noch nie ein Held.

Was ich jetzt noch interessant finde, der Weg. Was ist der eigentlich funktional? Extrem lange Rampe oder Fußweg. Ich habe noch nie jemanden den nutzen sehen.

Stimmt, deshalb Posting #8

Ich habe die Rampe heute benutzt :slight_smile: (mit dem Fahrrad runter) und da kamen dann gerade auch drei “Väter” (obwohl, Väter waren die wohl noch nicht, aber schon ziemlich angetrunken) einer musste den Bollerwagen die Rampe raufziehen. Die anderen haben dann sich dann laut beschwert (“Schüttel das Bier nicht so!”) wenn er mit dem Bollerwagen von der Rampe abgekommen ist und doch eine Stufe mitgenommen hat :P.

Ich schon, um die Richtung der Stufen anzuzeigen braucht es m.M. nach einen separaten Way, den ich über die Relation mit der Area verknüpft habe.

Wer lesen kann, ist im Vorteil. :roll_eyes:

Hatte ich nicht bei area:highway den zusätzlichen Weg mit angeführt. Dazu braucht es keine Relation, über die nicht mal abgestimmt wurde, AFAIK.

+1

Ja, da hast Du vollkommen Recht (und Du hattest es schon vor mir gepostet, was ich übersehen hatte). Aber es geht hier -glaube ich- auch darum, die Treppenanlage (irgendwo) als Fläche optisch ansprechend rendern zu können. Und dazu braucht man die Richtung der Treppe an der Fläche. Daher mein Post #11, letzter Satz.

Ein geschlossener Weg mit area:highway und ein zusätzlicher Weg mit der Richtungsangabe halte ich nicht für sinnvoll, da bei komplizierteren Treppenformen unzureichend. Das Problem ist, dass man nicht feststellen kann, welche der Knoten des geschlossenen Weges am Seitenrand der Treppe liegen und welche Knoten an der oberer und unteren Kante der Treppe liegen. Man denke zum Beispiel an eine halbkreisförmige Freitreppe.

Die Area-Steps Relation wäre hier schon leistungsfähiger, allerdings meines Erachtens doch der falsche Ansatz, denn wenn man eine neue Methode zur Flächendefinition schaft, sollte diese möglichst generisch und nicht nur auf Treppen beschränkt sein.
Nötig haben wir mindestens eine neue Methode zur Flächendefinition neben dem geschlossenen Weg und dem Multipoligon unbedingt, insbesondere um gerichtete Flächen definieren zu können. Das kann durchaus eine relationsbasierte Flächendefinition sein, wobei dann ein geeigneter Editorsupport benötigt wird, um dies einfach handhabbar zu machen. Man bedenke dass der geschlossene Weg zur Flächendefinition (und jeder ander OSM-Weg) auch nichts anderes als eine geordnete Relation von Knoten ist, die nur aus historischen Gründen in anderer Weise gespeichert wird, wie die sonstigen QSM-Relationen. Weil es aber geeigneten Editorsupport für die Eingabe dieser Wege gibt, werden diese Relationen nicht als kompliziert empfunden.

Für die Treppen (und viele andere Flächen) wäre jedoch auch eine relationsfreie Methode möglich:
Die Treppe wird an den seitlichen Ränden sowie am oberen und unterem Rand jeweils von separaten OSM-Wegen umgeben.
Diese werden alle mit highway=steps getaggt. Die seitlichen zusätzlich mit incline=up (oder down) sowie der obere und untere Weg mit incline=0 (oder incline=none).
Weiterhin wird mit area:highway:right=steps bzw. area:highway:left=steps gekennzeichnet, auf wecher Seite des OSM-Weges sich die Treppenfläche befindet. Um Verwirrunge mit der RIchtung des OSM-Weges am oberen und unteren Treppenende zu vermeiden, könnten diese alternativ z.B. mit area:highway:limit=yes getaggt werden, um zu kennzeichnen, dass die von den seitlichen OSM-Wegen definierte Fläche hier endet.

Das Routing könnte auch für vorhandene Appllikationen über diese OSM-Randwege erfolgen, jedoch könnten problemlos auch zusätzliche OSM-Wege für direktes Routing in die Treppenfläche eingefügt werden.