ich könnte wetten, dass das Thema schon diskutiert wurde, möchte das Ganze aber noch mal festzurren. Zwei grundsätzliche Fragen zur stop_area-Relation:
Was kommt rein? Auf jeden Fall die stop_positions und platforms, aber dann? Zwar werden Objekte mit amenity=* im Wiki als Mitglieder vorgeschlagen, aber: Die Elemente, die irgendwie mit dem Bahnhof in Verbindung gebracht werden können, sind zahlreich. Bei diesem Bahnhof ist so gut wie alles erfasst, damit könnte man die stop_area-Relation auf einen Umfang von über 80 Elementen anschwellen lassen. Und das ist nur ein simpler U-Bahnhof. Diese Relation enthält schon mit Fußwegen und Aufzügen über 200 Elemente, wenn da jetzt noch Läden im Zwischengeschoss etc. reingepackt werden, wird die Relation überdimensional (wenn sie es nicht jetzt schon ist). Ich persönlich würde es bei stop_positions und platform belassen, da nur diese Objekte für den ÖPNV unmittelbar relevant sind.
Nach welchen Kriterien grenze ich Relationen voneinander ab? Nur der Name? Oder irgendeine Referenzbezeichnung bzw. -nummer? Beispielsweise könnte ich die im zweiten Link verlinkte Haltestelle auch in einen S-Bahnhof, einen U-Bahnhof und eine Tramhaltestelle an der Oberfläche ausdifferenzieren, immerhin unterscheidet sich der S-Bahnhof durch den Betreiber vom Rest, und auch der U-Bahnhof ist betrieblich eine eigenständige Einheit. So ist es laut diesem Forumsbeitrag auch richtig, allerdings ist der Thread schon eine ganze Weile her.
Wäre gut, wenn dann auch die Seite im Wiki hinterher keine Unklarheiten mehr offen lässt.
Mein Eindruck ist, dass es eine, ääh, Müdigkeit gibt, über ÖPNV-Tagging zu diskutieren.
Die wichtige Diskussion über Public Transport Version 2.1 hat ja auch schnell aufgehört - und nicht, weil sie überflüssig wäre.
Es ist halt ein echt komplexes (und anstrengendes) Thema…
Fußwege, Aufzüge und Treppen sind gegen die Regeln. Im PTP werden nur zwei Sachen außer stops und platforms angegeben:
public_transport=station
amenity=*
und zwar mit der Bemerkung "…can also contain other elements like public_transport=station, amenity=shelter or amenity=bench. ".
Bei Karten werden ja nicht alle Objekte gelöscht die in der stop_area nicht aufgezählt sind. Es reicht doch völlig, wenn sie in der Karte sind.
Bei verschiedenen Namen kann es nicht in eine Relation, denn bei Existenz einer stop_area darf der Name an den stop positions und platforms weggelassen werden.
Das hatte ich befürchtet. Da bedanke ich mich für eure Antworten umso mehr.
Was unterscheidet denn amenity=* in dieser Sache so deutlich von anderen Objekten wie etwa emergency=, dass amenity= im Gegensatz zum Rest in die Relation reinkommt? Da würde ich lieber amenity weglassen, diese Objekte gibt es auch in großer Anzahl.
Wegen der bereits erwähnten “Müdigkeit”: Hat jemand einen Diskussionsthread oder eine Meetingdokumentation oder was ähnliches parat, auf das ich mich bei der Beantwortung dieser Frage sicher stützen kann? Beispielsweise dieser hier.
Die Aufteilung in mehrere stop_areas finde ich recht einfach: Wenn irgendwas ausser dem Verkehrsmittel anders ist gibt’s 'ne weitere stop_area.
Mit dem Satz ist mEn alles erlaubt, die drei sind ja nur Beispiele. Ich würde aber nur das rein tun, was unmittelbar dem öffentlichen Verkehr dient. Also z.B. Sitzbänke, Verkehrswege, Dächer und Beleuchtung nicht, bei FAA kann man drüber reden.
Etwas OT: Imo sollte er es auch, weil name=* sonst eine andere Bedeutung als normal erhalten würde. name=* ist nämlich eigentlich der Name dieses Objekts. Eine namenlose Strasse benennen wir ja auch nicht mit dem Stadtnamen…
Nichts - jedenfalls sehe ich es nicht. Das ist halt das, was im PTP steht. Ich hätte lieber nur die stops und platforms.
Aber unser Hauptproblem beim ganzen ÖPNV-Kram ist, das wir gar kein Konzept mal wirklich durchziehen. Das führt dazu, dass man viele Einträge nur dann verstehen kann, wenn man den Stil des Bearbeiters kennt. Das ist Mist.
Ich bin dafür, dass wir uns strikt an die Regeln halten. Es gibt zwei zur Auswahl:
Klassische (Old Style) Routen:
public_transport:version=1
alle Varianten in eine Relation
Reihenfolge der Member spielt keine Rolle
keine Master-relation
alle Haltestellen sind Nodes. Eine pro Halt und nie zwei.
bei den Halten gibt es “forward_stop” (Hinweg) und “backward_stop” (Rückweg) und “stop” (Beide)
Ways mit der Rolle “” werden bidirektional durchfahren, “forward” und “backward” in Wegrichtung bzw. gegen sie.
(Wer an einen Kreisverkehr oder eine andere Einbahnstraße die Rolle “” schreibt, macht einen “Geisterfahrerbus”)
PTP-Routen:
public_transport:version=2
keine Varianten innerhalb einer Relation - jede Variante eine eigene Relation. (Ja, genau dass, was z.B. in Mainz oder Paris sehr
unpraktisch ist)
kein forward, kein backward
Reihenfolge der Relationsmember gibt die Reihenfolge in der Realität an.
Es werden nur stop-positionen, Steige und Fahrwege angegeben. “Stations” - ob PTP oder sonstwie - kommen nicht rein.
Und während wir das mal endlich durchziehen und uns oft drüber ärgern, sollten wir am Nachfolger arbeiten und zusehen, dass wir die Version 1 loswerden ehe die Version 3 kommt.
Das Internet mit seinen RFCs zeigt uns, dass man klare (klappt nicht immer) Regeln geben kann, ohne die Freiheit inhaltlich einzuschränken.
Ja, das ist aber ein Problem der Editoren und sollte dort behoben werden. Der Name der Station sagt dir eh noch nicht, ob da nicht beispielsweise die stop_position der Gegenrichtung drin ist…
Und was machst du, wenn doch mal Bahnsteige eigene Namen haben? Vor allem: Wie würdest du diese von Fake-Namen unterscheiden?
Aber wenn sie wirklich keinen Namen hat nicht mit dem der Stadt (als übergeordentes Objekt)
Womit wir auch beim “beliebten” Thema der Sinnhaftigkeit der stop_position sind. In den meisten Fällen wird man diese durch das Fällen des Lotes auf den Linienweg von der platform (sei diese nun Knoten oder Weg) ermitteln können.
Letztlich stimme ich aber Weide zu: Wir sollten ersteinmal das bestehende Schema mit all seinen Unzulänglichkeiten konsequent umsetzen und alle sich hierbei ergebenen Probleme/Unklarheiten nutzen um eine neue Version der ÖPV-Schemas zu erstellen. Ich denke der Migrationsaufwand von einem konsequent eingehaltenen PTP v2 auf ein verbessertes PTP v2.1/3/… ist dann geringer, als wenn wir da ständig dran herumbasteln und letztlich niemand mehr genau weiß, was wann nach welchem Schema getaggt wurde.
