stop_area-Relationen überflüssig?

Communities Deutschland (Germany)
1

Hallo,

in der letzten Zeit habe ich mich vermehrt mit der Überarbeitung von Bushaltestellen in meiner Umgebung beschäftigt. Das umfasst ein einheitliches Tagging gemäß PTv2, das Aufteilen in stop_positions und platforms und etwa im Verkehrsverbund Rhein-Ruhr auch die Erfassung der IFOPT-Referenzen. Zum Erfassen von Haltestellen gemäß PTv2 gehört eigentlich auch das Erstellen der jeweiligen stop_area-Relationen. Das habe ich bisher auch immer gemacht, aber mittlerweile hinterfrage ich, ob das überhaupt einen Nutzen bringt.

In meinen Augen sind die stop_area-Relationen eigentlich überflüssig, zumindest bei mindestens 90% aller Bushaltestellen. Eine Gruppierung von zusammengehörigen stop_positions und platforms lässt sich ebenso gut über die Tags name, ref, uic_ref, ref:IFOPT, etc. in Verbindung mit der räumlichen Entfernung zueinander vornehmen. In einer PostGIS-Datenbank ist das eine relative einfache Sache, man macht einerseits ein GROUP BY nach einem oder mehreren der genannten Referenz-Tags und ein Clustering nach räumlicher Anordnung. Wenn die IFOPT-Referenzen getaggt sind, kann man darüber sogar die stop_position der zugehörigen platform zuordnen, was in den meisten Fällen aber auch aufgrund der räumlichen Lage eindeutig möglich wäre.

Derzeit ist eine stop_area-Relation eigentlich nur eine Sammelrelation von platforms und stop_positions mit dem gleichen name-Tag, uic_ref-Tag, ref:IFOPT-Tag oder einer anderen Referenzangabe. Genau solche Sammelrelationen für Dinge, die sich auch über die Abfrage von Tags ermitteln lassen, wollen wir in OSM ja eigentlich gar nicht haben.

Daneben produzieren die stop_area-Relationen relativ viel Redundanz, da ein Großteil der Tags an der Relation identisch mit den Tags der einzelnen stop_positions und platforms ist.

Außerdem hätte eine “Abschaffung” der stop_area-Relationen den Vorteil, dass das Bearbeiten einfacher wird. Je einfacher das PT-Schema ist, desto eher kann man die breite Masse der Mapper dazu bringen, ÖPNV-Features zu mappen. Und das ist gerade beim ÖV-Mapping dringend nötig. Besonders für Anfänger stellen Relationen auch immer eine gewisse Hürde dar, ganz zu schweigen von der komplexen Umsetzung in Editoren. Deshalb bevorzuge ich generell immer Lösungen, bei denen man ohne Relationen auskommt, einmal abgesehen von Fällen wie Multipolygonen oder Routenrelationen, wo es nicht ohne Relationen geht.

Wie seht ihr das? Sind die stop_area-Relationen überflüssig, oder gibt es durchaus Gründe, warum man nicht auf sie verzichten kann?

Gruß
Alex

2

Seh ich auch so. Die meisten stop_areas sind überflüssig. Das gilt auch für die meisten Aufteilungen in stop_position und platform.

Nur: PTv2 hat das auch nie gewollt. Es haben nur viele Leute gedacht, dass das die neue Mappingart wäre.

stop_areas sind optional und man sollte sie nur da einsetzen, wo die Lage für den Mapper oder für den Umsteigenden unübersichtlich ist.

Die Aufteilung in stops und platforms wurde erst durch PTv2 möglich. Es sollte nur eine Möglichkeit zum Detailmapping geschaffen werden, die mit einem einfachen Node mit highway=bus_stop pro Haltestelle nicht existierte. Das war nie als “jetzt soll das so gemacht werden” konzipiert.

Mit wir immer ganz schlecht wenn ich sehe, dass aus einem einfachen Node auf der Landstraße, der zwei einander gegenüberliegende gleich ausgestattete Haltestellen gut repräsentierte ohne irgendeine Absicht etwas zusätzliches zu mappen zwei Nodes, zwei frei erfundene Platformlinien und eine stop_area gebaut werden. Die Verwunderung ist dann immer ganz groß, wenn man sagt dass man nach PTv2 da am Besten garnichts geändert hätte.

3

Hi,

momentan habe ich da nicht den vollen Durchblick, aber der name-Tag und ref-Tag dürften nicht ausreichend sein, diese können in anderen Gegenden ebenfalls vorkommen. uic-ref gibt es, wenn ich es richtig verstanden habe, nur bei Bahnhöfen, ref:IFOPT hingegen ist als eindeutiger Tag gedacht und dürfte zur Zusammenführung von platform und stop_position reichen.

Allerdings sind die IFOPT-Nummern wohl noch nicht flächendeckend eingeführt, dies muss jedes Verkehrsunternehmen wohl für sich selbst vergeben (bzw. jeder Verkehrsverbund). Bei Bürgerbushaltestellen gibt es z.B. KEINE IFOPT-Nummern, bei Schulbushaltestellen meine ich ebenfalls keine gefunden zu haben. Hier kommt man um die stop_area wohl nicht herum.

Bezgl. des VRR wurde sich in großer Runde auf dieses Tagging MIT stop_area geeinigt. Von daher sollte dies erstmal auch weiter so getaggt werden, selbst wenn sich möglicherweise rausstellt, dass sie überflüssig sind. Dazu sollten wir eine neue Vereinbarung in großer Runde diskutieren und treffen.
Bezgl. der Wartbarkeit gebe ich Dir nur bedingt Recht, es ist nicht einfach an die IFOPT-Nummern ran zu kommen (insbesondere bei neu eingerichteten Haltestellen). Der “normale” Mapper wird sicher auf eine aufwendige Suche nach der richtigen Nummer verzichten und dadurch gibt es “Kuddelmuddel” → keine eindeutige Zuordnung. Die stop_area sorgt aber dafür, dass auch bei fehlender IFOPT, die Zuordnung funktioniert.
Diese erwartbare Unordnung lässt mich zu der Annahme kommen, dass die stop_area besser weiterhin gepflegt werden sollte.

Zur IFOPT fällt mir noch ein, dass diese bei mehreren Bussteigen auch unterschiedlich ist, man kann also dann nur auf einen Teilbereich der IFOPT-Nummer referenzieren, nicht jedes Unternehmen vergibt die Nummer derart gewissenhaft und manche Unternehmen gehen sehr ins Detail. An welcher Stelle soll die IFOPT denn dann unberücksichtigt bleiben?

Thoschi

4

Deshalb hatte ich ja auch von einer Kombination aus name-Tag bzw. Referenznummer und räumlicher Entfernung gesprochen. Eine Haltestelle “Bahnhof” oder “Goethestraße” gibt es in Deutschland in Massen. Wenn man aber alle stop_positions und platforms mit name=Goethestraße im Umkreis von 100 m betrachtet, dann ist die Eindeutigkeit gegeben.

Streng genommen gibt es die uic_ref nur für Bahnhöfe. Das HAFAS-System verwendet aber wohl auch für nicht-Eisenbahn-Haltestellen eine Nummer, die nach diesem Schema aufgebaut ist, aber soweit ich weiß länger ist. Bisher wurde diese Nummer auch als uic_ref getaggt, wobei das eben nicht ganz korrekt ist.

Ja, die IFOPT-Nummern sind bisher leider noch nicht flächendeckend verfügbar, obwohl sie für die Verknüpfung von OSM-Daten mit anderen Systemen wie Fahrplanauskünften ideal wären.

Allerdings kann man in den meisten Fällen auch ohne IFOPT-Nummer auf eine stop_area verzichten, wenn man wie erwähnt die Kombination aus name-Tag und räumlicher Entfernung als Kriterium verwendet.

Die IFOPT-Nummern sind ja nach dem Schema aa:bbbb:cccc:dd:ee aufgebaut.

aa ist das Länderkürzel (z.B. de für Deutschland), bbbb der Gemeindeschlüssel, cccc die Haltestellennummer innerhalb des Namensraums von Länderkürzel und Gemeindeschlüssel, dd ist bei großen Haltestellen mit mehreren Verkehrsmitteln die Bereichsnummer, bei den Standardbushaltestellen aber meist 0 oder 1, und ee ist die Steignummer.

Das, was man mit einer stop_area-Relation zusammenfassen würde, wäre dann die Ebene aa:bbbb:cccc. Mit dd kann man je nach Anwendungszweck noch Untergruppen bilden. Das ist übrigens auch so ein Nachteil bei den stop_area-Relationen: Es ist nicht so klar definiert, ob man nun z.B. bei einem Hauptbahnhof mit Busbahnhof vor der Tür zwei Relationen für die jeweiligen Verkehrsmittel anlegt, oder alles in eine einzige Relation packt. Früher gab es ja dafür noch die stop_area_group-Relationen, wobei die in PTv2 ja nicht mehr definiert sind. Relationen über mehrere Hierarchieebenen sind auch nicht wirklich mapperfreundlich.

Gruß
Alex

5

OK, das war mir so bisher nicht klar. Dann sollte das Wiki aber dementsprechend angepasst werden. Derzeit ist aus der Doku im Wiki nicht ersichtlich, dass das optional wäre. Im Gegenteil, es wird eher der Eindruck erweckt, dass die stop_areas zu einem vollständigen ÖV-Mapping dazugehören.

Gruß
Alex