Changeset: 57710283
Kaub: Bahnsteigkantenmapping korrigiert
Closed by Nakaner
Tags
created_by | JOSM/1.5 (13500 de) |
---|---|
source | ESRI World Imagery; local knowledge |
Discussion
-
Comment from adjuva
Hallo Michael!
Was war denn an dem Tagging so schlimm, dass
1. das Multipolygon für den Bahnsteig gelöscht
2. die Tags public_transport=platform und name=Kaub an der Bahnsteigkante
gelöscht werden mussten?
Ich denke, dass sich langfristig alle Bahnsteige zu Multipolygonen mit Bahnteigkanten railway=platform_edge entwickeln werden und deswegen würde ich das hier gern beispielhaft mal grundsätzlich diskutieren.
Ich korrigiere recht viele Bahnsteigkanten (meist weil meine Route-Relationen-Prüf-Skripte Fehlermeldungen werfen) und setze dann immer die fünf Tags railway=platform_edge, name=Abc, ref=XY, train=yes, public_transport=platform.
zu 1. Im WIki hast Du einen Artikel Tag:railway=platform_edge angelegt und keines der dortigen Beispiele verzichtet auf ein Multipolygon. Und wenn in Zukunft jemand den Treppenaufgang mit einem inner-Way besser modellieren möchte ode jemand (wie in Mannheim Hbf) alle Säulen und Bahnsteigmöbel aus der Fläche herausnehmen will, dann wird er das Multipolygon wieder einführen.
Ich finde die aktuelle Modellierung unpraktisch, weil es jetzt viel schwieriger wird, von der Bahnsteigkarte zur Stop-Area-Relation (und dann weiter zum Betriebsstellen-Node) zu kommen. Um mit z.B. der Overpass-API vom Way Bahnsteigkante zum Bahnsteig-Multipolygon (das in der Stop-Area ist) zu kommen war vorher ein einfaches rel(bw) ausreichend. Jetzt muss man den Umweg über die gemeinsamen Nodes der Bahnsteigkante und des Bahnsteigs gehen.
2. Ich halte es für sinnvoll, in die PT2-Routen-Relationen nur noch die Ways der Bahnsteigkanten und nicht mehr die Relations der Bahnsteig-Multipolygone einzutragen. Und public_transpoprt=platform markiert eben aus meiner SIcht genau die Objekte, die man potentiell mit der Rolle 'platform' in eine Route-Relation (die Bahnsteigkante oder den ganzen Bahnsteig) oder in eine Stop-Area-Relation (der ganze Bahnsteig) einträgt. Deswegen ist das Löschen des public_transport-Tags kontraproduktiv.
In den Route-Relationen möchte man ganz gerne sehen, welche Objekte man da mit den Rollen 'stop' und 'platform' eingetragen hat, damit man die korrekte Reihenfolge der Halte kontrollieren kann. Deswegen mappt man entweder name=Abc, (local_)ref=XY oder description 'Abc, Gleis XY' (ich zumindestens habe JOSM-Styles, die name und ref in der Relationsliste und im Auswahl-Fenster anzeigen). Das name-Tag ist dabei eigentlich unschön, weil es bei Flächen vom OSM-Standard-Style gerendert wird. Wenn man nun die Bahnsteigkante in die Route-Relation aufnimmt, dann ist das nie gerendert und man kann guten Gewissens das Name-Tag benutzen. Es besteht außerdem auch keine Notwendigkeit local_ref statt ref zu benutzen (ref braucht man manchmal (siehe Mannheim Hbf) für Ids, die keine Gleisnummern sind). Und deswegen ist das Löschen des name-Tags ebenfalls kontraproduktiv.
Schö
Adjuva -
Comment from Nakaner
Hallo Adjuva,
ehrlich gesagt wäre es mir lieber, wir würden das anstatt hier auf der Mailingliste oder im Forum diskutieren.
Deine Kritik ist teilweise richtig. Wenn ich es so betrachte, ist das Löschen des Multipolygons nicht in Ordnung. Ich hatte es gelöscht, weil es nur einen äußeren Ring hatte. Wenn natürlich jemand den Treppenaufgang mappt, braucht man es wieder.
public_transport=platform ist für den gesamten Bahnsteig da, nicht für die Kante. Als wir uns railway=platform_edge im Sommer 2014 ausgedacht haben, wollten wir zum bestehenden Mapping abwärtskompatibel bleiben. Deshalb blieben railway=platform und public_transport=platform auf der Fläche.
Mit dem Gedanken, dass man von der Multipolygonrelation einfach auf die Kanten kommen kann, wenn solche platform_edge-Bahnsteige grundsätzlich als Multipolygone modelliert sind, haben wir damals die Multipolygon-platform_edge-Variante uns ausgedacht.
Leider hat diese zwei Haken. Erstens tun viele Datennutzer ihre Abfragen nicht auf den originalen OSM-Daten durchführen, sondern auf Datenbanken, die nicht topologisch sind. Zweitens binden wir uns an die suboptimale Art, wie Flächen in OSM modelliert werden. Es ist langsam absehbar, dass die Zeit der Multipolygonrelationen in OSM zu Ende gehen wird. Ob es mit der nächsten oder erst mit der übernächsten Version passieren wird, ist unklar, die Arbeiten an einer Überarbeitung des Datenmodells haben jedoch begonnen. Siehe dazu auch https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dplatform_edge
Ich lösche public_transport=platform von Bahnsteigkanten und übertrage es an die Flächen, wenn diese erfasst sind, weil das die übliche und anerkannte Erfassungsweise für Bahnsteige ist. Das PTv2-Schema schreibt vor, dass der Bahnsteig die Rolle "platform" hat und nicht dessen Kante. Das Modellieren von Kanten ist eine verhältnismäßig neue Detailstufe.
Das gelöschte Multipolygon kann ich wiederherstellen, wenn du das wünschst.
Ach und nochwas: Wer wann was als Namen rendert, ist mir beim Mappen egal und das sollte auch dir egal sein, weil es sonst Tagging für den Renderer wäre.
Viele Grüße
Michael
Ways (4)
Relations (4)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |