Treppen modellieren

Ich bin seit Langem über die Schwächen des REnderings von Treppen in höchsten Zoomstufen irritiert.
Ich habe daher einige Gedanken zusammen gestellt wie dies besser funktionieren könnte:

http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling

Insbesondere relevant sind gruße Treppenanlagen im Freien (Etwa Spanische Treppe, Rom).
Nach der Untersuchnung mehrerer Treppenformen bin ich der Meinung dass man die meisten Treppearten mit diesem Ansatz detailliert rendern kann.
Da die Beschreibung richtung 3D zielt sind dort auch andere Taggingvorschläge die erst in einem 3D Bild sichtbar werden, wie Wtwa Treppenart, oder Geländerart.

Das Regelwerk welches präziseres Rendern ermöglichen sollte beinhaltet bei mir außer dem was man bisher verwendet zwei zusätzliche Elemente:

Außenkante Treppenfläche
Start und Endkante Treppe (in diesem Fall ist Multipolygon Treppenfläche überflüssig)

Bie der Benennung der Tags habe ich mich an sprachliche Beschreibung gehalten. Falls Ihr vorschläge habt, wie man dies in englischer Sprache besser taggen kann, bitte ergänzen.

Das scheint mir nicht fehlertolerant …
Dann kommt einer daher, der von den Treppen keine Ahnung hat, und snappt einen zuführenden Weg rein oder eine PLZ-Grenze, …

Das stimmt,
mit diesem Ansatz kann man unmögliche Elemente bauen.
Es gibt dafür 2 Lösungen:

  1. Softwarewarnung - “Treppe kann nicht generiert werden”
  2. Nix machen - nach dem Rendern wird sichtbar, dass es nicht funktioniert hat.

Ich habe es noch nicht beschrieben, aber damit kann man auch in Zukunft 3D Gelände modellieren.

Das Problem dürfte sein, dass viele Renderer das nicht darstellen werden. Es fällt also nur einer sehr kleinen Gruppe überhaupt auf und ob die Gruppe das über längere Zeit lustig findet, die Nodeanzahl zu kontrollieren. Genauso wenig kann man erwarten, dass andere Nutzer Lust haben, sich jedes Tagging-Schema anzuschauen, was ihnen irgendwo über den Weg läuft, um durch eine banale Sache nichts kaputt zu machen. Wenn ich als unwissender dann die Meldung erhalte, dass auf der einen Seite ein Node zu wenig ist, mache ich halt irgendwo einen Node hin. Da die Position des Nodes aber auch wichtig zu sein scheint, wäre es sinnvoll, den entscheidenden Nodes ein Tagg zu spendieren.

Unabhängig davon sollte der Way mit highway=steps weiterhin bei jeder Treppe vorhanden sein. Das ist ein etablierter Standard.

Highway=steps blebt auf jedem Fall.
Viele Renderer werden dies nicht darstellen: über wieviele Renderer reden wir denn? Falls ein Renderer opensource ist, kann man dies nämlich einbauen. Des weiteren gilt, wie bei allen Dingen in OSM: Entweder macht eine Sache Sinn, dann wird sie sich mit der Zeit etablieren, oder eben nicht.
Momentan ist die Sache sowieso nirgendwo umgesetzt. Was die Anzahl der Punkte entlang von 2 Polylinien angeht ist es aber richtig: Es wäre nervig zu erwarten dass man sich die Anzahl der Punkte merkt. Dort muß ein Mechanismus eingebaute werden, der dem User die Arbeit erleichtert, etwa eine Warnmeldung dass eine der Polylinien 3 Punkte zu wenig hat.

Erst mal zu den leichteren Themen:

  • Für Handläufe gibt es aus früheren Diskussionen handrail:left/right/center = yes/no/Anzahl. Die bringen es zusammen schon auf gut 1500 Verwendungen und haben gegenüber deinem handrail_position = left/right/middle/both den Vorteil, dass auch Kombinationen wie links + Mitte problemlos darstellbar sind.

  • Ich würde statt “type” eher ein konkreteres Wort wie “shape” für die Bauart von Stufe und Treppengeländer verwenden.

  • Sind Stairs_start_angle und Stairs_end_angle wirklich nötig? Der Fall scheint mir eher selten zu sein, und bei den wenigen Vorkommen könnte man ja dann auf die Modellierung mit Start- und Endline zurückgreifen. Oder irre ich mich?

Die Forderung nach einer identischen Anzahl an Nodes erscheint mir doch eher problematisch, weil sie für den Mapper eine unerwartete Fehlerquelle ist. Ich habe zwar auch keine perfekte Lösung parat, aber fände es fast intuitiver, mehrere Flächen für eine solche Treppe anzulegen. Innerhalb dieser Flächen ließe sich die Verbindung statt über Nodenummern dann über relative Längen machen. Statt “der x. Node der Startlinie wird mit dem x. Node der Endlinie verbunden” also: “Die Stelle an x% der Länge der Startlinie wird mit der Stelle an x% der Länge der Endlinie verbunden”.

Da muss ich selber noch mal drüber nachdenken, aber mir wäre wohler, wenn man hier ein Verfahren fände, das auch ohne Warnmeldungen im Editor auskommt. Denn das wirkt doch eher wie eine Notlösung, die auf eine Schwäche des Modellierungskonzepts hinweist.

Kombinationen von Handrails sind tatsächlich gut. Gefällt mir. Bei größeren Anlagen, kann es sogar mehrere Handrails geben - da muß man sich Etwas einfallen lassen.

Die Parametrisierung mit start und end angle scheint auf den Ersten Blick überflüssig, ermöglicht aber bei der Modifikation der Treppenverläufe eine angenehmere Modellierung. Beispiele werde ich auf der Seite unterbringen.

Ich dachte über die Restriktion mit der gleichen Anzahl der Punkte nach:

  • Bei ganz einfachen Treppen ist das offensichtlich und die Restriktion erklärt sich von selbst: Etwa startend mit einem rechteckigen Podest wo die Treppe zu einem Kleinen rechteckigen Podest vor dem Eingang wird.
  • Es ist einfach zu programmieren, wenn die Treppe die gleiche Anzahl der Punkte unten und oben hat.

Was mich jedoch mehr noch als die Hinweise über mögliche Fehlerquelle nachdenklich machte, ist die Tatsache, dass es Treppenverläufe geben kann die in der Tat unten anders als oben aussehen: Etwa Unten ein Rechteck, oben ein Dreieck.

Ich glaube dafür eien Lösug gefunden zu haben und werde diese nächste Woche in die Seite einbauen.

Tordanik, Aighes,
herzlichen Dank für Eure Hinweise!

Marek

Hallo Tordanik und Aighes,
Dank Eurer Kritik an dem Kriterium “gleiche Anzahl der Knoten an Nodes” bin ich zu einer Lösung gekommen, welche die Gestaltungsvielfalt der Treppen noch erhöht:

http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling#Gestaltungsm.C3.B6glichkeiten

@ Tordanik: Kannst Du Deinen Hinweis auf: handrail:left/right/center = yes/no/Anzahl. in die Seite einbauen?

Grüße,
Marek

Bei deinem Bild:

In der Datenbank wäre dann die rechte untere graue Linie, die Gelbe, die Grüne und die linke untere Graue, richtig?

Wenn ich nun in die gelbe Linie im unteren rechten Segment leicht unterhalb der Segmentmitte einen Knoten einfüge, würde dieser nach unten verbunden werden. Beim Rendern hätte ich dann erst einen Linksknick und dann einen Rechtsknick zurück.

Was spräche denn dagegen, die Punkte, die wichtig für das Rendern der Treppe wichtig sind, gesondert zu kennzeichnen. Zum einen ist dann klar, wie das Resultat aussieht, unabhängig davon, ob irgendwo noch ein Knoten nötig ist. Zum anderen ist anderen Mappern klar, dass der Knoten eine spezielle Bedeutung hat.

Hallo Henning,
in dieser Variante wäre in der Datenbank Nur die Gelbe, die Grüne und natürlich die rote Verbindungslinie. Alles Andere soll der Renderer generieren.
http://wiki.openstreetmap.org/wiki/File:MarekStairsDownAndTopLineDifferentEdgesB.jpg

Nichts spricht gegen einen solchen Vorschlag. Damit könnte man entlang längerer Verläufe punkte kennzeichnen, die miteinander beim Rendern verbunden werden.
Irgend ein Vorschlag für Tagging?

Viele Grüße,
Marek

Auf der Tagging-Mailingliste gibt’s grad eine ähnliche Diskussion. Dort wurde auch das ältere Relations/Proposed/Area#area-steps ins Spiel gebracht.

Hallo Marek, Tordanik, aighes

Bitte daran denken, dass breite Treppen heute oft/gelegentlich als mehrere parallele / auseinander laufende Treppen erfasst sind.

In dem angeführten Beispiel kann/wird es eher 3 oder 5 Treppen (als highway=steps) geben als die eine rot eingezeichnete Verbindungslinie. Dies verstärkt, wenn die Treppe oben und/oder unten eine Verbindung zu mehreren Wegen (z.B. Ecke) hat.

Edbert (EvanE)

Hallo Evan,
auch dafür gibt es eine Lösung. Beschreibung in der Spez. demnächst.
Gruß,
Marek