Hm. Um nochmal ganz deutlich zu sein bzw. zu fragen: Momentan werden potenziell folgende physikalische Gegebenheiten gemappt, die auch Teil der PTv2-Strategie sind:
• public_transport = stop_position
• public_transport = platform
Ob man die Plattform jetzt noch nach Verkehrsmittel trennen möchte, sei mal dahingestellt (es gibt ja z.B. auch noch railway=platform und highway=platform). Ich persönlich halte es nicht für nötig, da die Elemente ja normalerweise einer Relation angehören und daraus abgeleitet werden kann, ob um was es sich handelt (und es können dadurch sogar Mischnutzungen sein).
Beide Informationen halte ich für sinnvoll, nützlich und notwendig. Für sich alleine sind sie aber natürlich nur begrenzt nutzbar.
Daher kommt zur Physik noch die Organisation hinzu, sprich, die Verknüpfung zu Strukturen. Das kann man z.B. über gleiche Namen zum Gruppieren erreichen und über eine eindeutige Nummerierung für die reihenfolge. Letzteres wurde ganz am Anfang sogar mal gemacht, glaube ich. Stattdessen kann man den Zusammenhang aber über Relationen darstellen, und genau das wird ja mittels PTv2 getan. Hier können weitläufige Haltestellen zusammengefasst, deren Reihenfolge definiert und sogar die Fahrwege erfasst werden. Für sich genommen also eigentlich sehr einfach und transparent.
Ein Problem stellt sicher dar, dass Änderungen an den verwendeten wys für die Fahrwege schnell zu korrupten Fahrwegen führen können (Stichwort “Zumutung” in Post #128). Okay. Das ist doof. Aber letztlich ist die Reihenfolge und Konsistenz der Haltestellen und deren Zugangspunkten wichtiger. Die Fahrwege sind eigentlich nur für die Visualisierung wichtig, auch wenn diese in bestimmten Fällen auch sehr nützlich ist. Auf der anderen Seite ist jeder Netzplan, den ich bisher gesehen habe, von den exakten Fahrwegen entkoppelt und stellt lediglich synmbolische Wege dar. Man könnte dies also als Argument nehmen, auf die Fahrwege komplett zu verzichten, um der Gefahr der Zerstörung durch unerfahrene oder unsensible Mapper zu entgehen. Ich persönlich würde sie trotzdem mappen.
So. Nun lese ich aus der Introduction auf gafte.de heraus, dass ein PIO die Kombination aus Plattform und Stop ersetzen soll. Ich interpretiere das so, dass es sich nur auf die Rollen in der Relation bezieht (darauf zielte wohl auch Posting #130 ab). Das kann ich zunächst mal noch nachvollziehen. Aber damit fallen die physikalischen Objekte komplett oder teilweise aus der Relation heraus. Ersteres würde erfordern, einen zusätzlichen Node oder Way zu erzeugen, der über getaggten physikalischen Objekte hinausgehen. Letzteres führt dazu, dass man sich entscheiden muss, ob man die PIOs an die stop_position oder die Plattform hängt. Gewählt wird natürlich die Plattform, aber damit fällt die Stop-Position aus der Relation raus und schwebt damit völlig frei im Raum. Und wenn die Plattform nicht dem Wartepunkt entspricht, muss noch ein solcher definiert werden, aber das geht auch ohne PIO. Dazu braucht man lediglich ein paar neue Werte, und zwar genau die, die hier oft für die PIOs angezogen werden.
In diesem Zusammenhang möchte ich mal den folgenden Satz aus der Introduction in Frage stellen:
Klar, es hängt immer davon ab, wie man etwas interpretiert, aber ich halte die Aussage für falsch. Warum sollte es nicht mehrere Plattformen geben können? Die Plattformen haben mit den Haltepositionen nichts zu tun, so dass ein zweiter Halt nicht impliziert wird. Wenn es zwei Plattformen für den gleichen Haltepunkt gibt, dann sind diese auch alternativ nutzbar. Das ist dann eben so, und der geneigte Datennutzer muss sich dann halt für eine entscheiden – wie “im wahren Leben” auch, wenn er oder sie vor Ort ist.
Anders ist es, wenn es verschiedene Plattformen für verschiedene Richtungen oder Linien gibt. Aber das ist ja auch kein Problem, da jede Linie und Richtung ja ohnehin eine eigene Relation hat. In dem Zusammenhang stand oben dies hier:
Sehe ich nicht so. Was ist daran kompliziert und fehleranfällig? Im Gegenteil: Es ist ziemlich straight forward, wie man neudeutsch sagt. Es gibt eigentlich nur zwei Regeln, die eingehalten werden müssen: Haltestellenreihenfolge und innerhalb der Haltestelle die Rollenreihenfolge, obwohl letztere eigentlich völlig egal sein sollte (ich wüsste jedenfalls keinen Nutzwert davon).
Die Länge eines Bereichs hat in der Organisationsstruktur auch nichts verloren und wird dort auch nicht gebraucht. Das ist Physik und wird von den Elementen selbst vorgehalten, indem eine Plattform zum Beispiel als Way ausgeführt wird. Das ist ja auch üblich. Theoretisch könnte man das sogar mit Stop-Positionen machen, ich persönlich würde aber eher die übliche Fahrzeugmitte als Punkt setzen. Und jetzt komme bitte keiner mit Kurzzügen, die ab Null Uhr fahren oderso … man muss die Kirche auch im Dorf lassen, denn wir können hier ohnehin keine zentimetergenaue Navigation ermöglichen. Bei langen Bahn- und Bussteigen gibt es dann eben mehrere Stop-Positionen. Das ist ja auch kein Problem, und es ist vor allem die (relativ einfache) Aufgabe des Renderers, diese in geeigneter Weise für jede Zoomstufe zusammenzufassen oder eben nicht. In welcher Weise publick_transport=stop_area zu verwenden wäre, erschließt sich mit in diesem Zusammenhang übrigens nicht aus der Wiki.
So, zuletzt noch einmal zu den Use Cases, die hier ja auch schon eingefordert wurden:
Wofür machen wir das alles? Der Hauptgrund für die PIOs scheint mir die Fußgängernavigation zu sein. Ich will eine Person also zu einem bestimmten Punkt lotsen, an dem sie ein Verkehrsmittel besteigen bzw. zumindest darauf warten kann (von da bis zum Fahrzeug aus übernimmt normalerweise der Betreiber mit Hinweisschildern, wenn nötig). Oder wir wollen eine Person von einer Haltestelle zu einem Ziel außerhalb der Haltestelle lotsen. In beiden Fällen muss der Navi-Nutzer angeben, in welche Richtung gefahren werden soll oder wurde, damit ggf. die richtige Einstiegs-Plattform angesteuert bzw. die richtige Ausstiegsplattform als Startpunkt gesetzt werden kann. Wenn ich mir nun PTv2 anschaue, erkenne ich nicht, was da fehlt. Es ist alles möglich. Hier geht es auch nicht so sehr um Geschmack, sondern um konsistente Daten.
Zweiter Use Case ist die Erstellung und Wartung der Daten. Hier spielt der Geschmack bzw. der “Nutzertyp” eine gewisse Rolle, ja. Dummerweise haben wir nun aber verschiedene Tools, und nicht jeder nutzt JOSM. Das ist ein Problem. Lösen könnte man es nur, in dem man “zu einfachen” Editoren bestimmte Änderungen nicht erlaubt. Konsequent umgesetzt würde das aber oft heißen, dass man gerade in Städten gar nichts mehr ändern kann, weil alles irgendwie von Relationen durchsetzt ist. Dafür habe ich auch keine spontane Lösung.
Eine Möglichkeit wäre natürlich, Relationen von den physikalischen Objekten zu trennen, aber das ist leider ein Widerspruch in sich und fällt damit raus. Ein Kompromiss wäre, Relationseigenschaften zu entwerfen, die einen Basissatz von Eigenschaften optional ergänzt. Das ist ja ein nicht unüblicher Ansatz. Wenn das mit den PIOs in diese Richtung ginge, wäre das in Ordnung, hätte dann aber nichts mit PTv3 zu tun, sondern wäre eine Ergänzung, die ab PTv3 hinzu kommt. Damit würde PTv3 PTv2 ersetzen, da es dieses vollständig umfasst. Oder man muss für Ergänzungen mit einem Sub-Index arbeiten: PTv2.1, PTv2.2 und so weiter. Das würde bedeuten, dass alle abwärtskompatibel sind. Dies wäre bei einem neuen Hauptindex nicht mehr unbedingt der Fall, also PTv3 wäre nicht mehr mit PTv2 kompatibel.
Sorry für die Textmenge und Glückwunsch an diejenigen, die bis hierher gekommen sind 
PS: Wir können mit dem OSM-Ansatz nur eine bestimmte Komplexität erreichen. Alles, was über diese hinausgeht, ist mit einem offenen System nicht mehr leistbar. Das sollte man auch immer im Hinterkopf behalten.
