[RFC] Feature-Proposal Gültigkeit von Routenrelationen

Hallo,

jedes Jahr am zweiten Samstag im Dezember ändern sich um 24:00 Uhr beim Europäischen Fahrplanwechsel die Fahrpläne von sehr vielen Linien des öffentlichen Verkehrs. Das bedingt auch zahlreiche Änderungen bei Routenrelationen – seien es Betreiberwechsel, Nummernänderungen oder neue Linienverläufe.

I habe ein Proposal geschrieben, das das Tag timetable:valid_until=* einführen möchte. Damit kann man angeben, bis wann eine Route gilt. Wenn man eine Route auf Basis eines Fahrplans mappt, weiß man ja meist, bis wann der Fahrplan gilt.

Für weitere Informationen sei auf die Wikiseite verwiesen.

Hinweis: Dieses Proposal führt absichtlich kein Tag für den ersten Gültigkeitstag an. Dieser liegt nämlich idealerweise in der Vergangenheit. Wir mappen jedoch keine historischen Routenrelationen des öffentlichen Verkehrs.

Dies ist ein Crossposting auf folgenden Mailinglisten: Tagging, Talk-Transit, Nahverkehr

Viele Grüße

Michael

EDIT: Links korrigiert

Hallo,

sollte es keine Kommentare dagegen geben, werde ich den vorgeschlagenen Tag ändern. Statt timetable:valid_until=* wird der vorgeschlagene Tag dann recheck_itinerary_route_by=* heißen.

Siehe dazu mein Posting auf der Mailingliste Tagging.

Viele Grüße

Michael

EDIT: Grammatikkorrektur, danke chris66

??

Die Routen haben prinzipiell in OSM nichts verloren.

Ist das Ironie oder ein Aufruf zum Löschen von Routenrelationen des öffentlichen Verkehrs? Wie ich schon auf der Mailingliste Tagging schrieb, ist es nicht Absicht dieses Proposals Fahrplantagging einzuführen, sondern ein check_date=*-Äquivalent einzuführen.

Aus meiner Sicht impliziert der Name des Schlüssels dann allerdings ein komplett unterschiedliches Nutzungsszenario? Bei einem timetable:valid_until würde ich intuitiv erwarten, dass das auch für Anwendungen gedacht ist, die dann nach dem Datum die Route als potentiell veraltet ansehen können. Ein recheck_itinerary_route_by ist für mich vom Namen her aber zu 100% ein Hinweis an andere Mapper.

Da wäre es schon praktisch, wenn man die neuen Angaben schon bei Veröffentlichung und nicht erst am Stichtag eingeben könnte. Dazu müsste es aber ein Tag für den Startzeitpunkt geben. Kartenhersteller mit seltenen Updates könnten dann auch einen sinnvollen Kartenstand wählen.

Finde ich auch. Es sollte klar drinstehen, dass das Löschen abgelaufener Routen erwünscht ist. Entsprechend sollte aber auch drinstehen, dass das Ablaufen des Fahrplans nicht als Endzeitpunkt der Route eingetragen werden sollte. Nur wenn bekannt ist, dass die Route zu dem Zeitpunkt obsolet ist, sollte der Zeitpunkt eingetragen werden.

Hallo,

Möchtest du damit vorschlagen, dass wir beim Fahrplanwechsel alle Routenrelationen, bei denen Änderungen erforderlich werden, kurzzeitig duplizieren und parallel eine alte und eine neue Route pflegen? Das widerspräche aber einem Grundkonzept des heutigen OSM-Taggings, dass ein Neben-Tag wie start_date=* nicht ein Haupttag in seiner Bedeutung “umkehren” kann (Beispiel: highway=secondary + construction=yes). Wir würden damit der Parallelerfassung verschiedener Zustände im Hauptnamensraum die Tür öffnen und das scheinst du ja auch nicht zu wollen.

Es ist nicht machbar, innerhalb eines Tages alles umzustellen. In der Praxis wird man (und das war auch bislang schon so) bis zu zwei Wochen früher anfangen und zwei Wochen später aufhören. Systeme, die nicht für parallel Versionsstände konzipiert sind, haben nun einmal mit abrupten Wechseln ihre Probleme. Wer sich für ÖPNV in OSM als Datennutzer interessiert, kommt hoffentlich auf die Idee, dass man um den Fahrplanwechsel herum nicht unbedingt das bekommt, was man in den nächsten 12 Monaten benötigt.

Anmerkung: Manche örtliche Communities haben schon, wenn die Änderungen tiefgreifend waren, im Voraus das neue Liniennetz gemappt, aber mit einem Präfix aus dem Lifecycle-Tagging-Schema versehen. Ich meine, dass Düsseldorf das bei der Inbetriebnahme der Wehrhahn-Linie gemacht hat (siehe deren Mailinglistenarchiv).

Viele Grüße

Michael

Hallo Michael, Wilhelm, nur um sicherzustellen, dass wir das gleiche Verständnis haben… Was aus meiner Sicht nicht sein darf, ist, dass das Tag dazu animiert, dass eine Route nach Überschreiten des Datums einfach gelöscht werden darf/soll. Denn nicht bei jedem Fahrplanwechsel ändern sich die Linienwege, und nicht jeder Mapper hat alle neuen Linienwege immer sofort eingearbeitet.
Das Tag sollte bestenfalls anzeigen “bis zu diesem Datum ist die Route gemäß Fahrplan valide - danach bitte den aktualisierten Fahrplan überprüfen und das Datum ggf. aktualisieren und bei Bedarf den Linienweg anpassen”. Aber vielleicht meintet ihr das ja auch und ich habs nur falsch verstanden :wink:

Hallo,

Vielen Dank für den weiteren Blickwinkel. Es ist nicht die Absicht meines Proposals, jemandem die Rechtfertigung zu geben, sofort nach dem Fahrplanwechsel zu löschen. Ich denke, dass die Regeln, die auch für den Umgang check_date=* gelten, hier ebenfalls gelten sollten. Weiteres sollte unabhängig von diesem Proposal diskutiert werden. Da ich deine Bedenken jedoch nicht von der Hand weisen möchte, habe ich folgenden Absatz ergänzt:

Viele Grüße

Michael

Prima, danke. Grundsätzlich finde ich Dein Proposal gut. Habe bisher ein note-Tag im route_master verwendet, um Stand-Informationen nachzuhalten, ein offizielles Tag wäre aber die definitiv sauberere Lösung.

Gruß
Achim

Der erste Ansatz mit timetable:valid_until=* war eigentlich der bessere, nur dass es itinerary:valid_until=* hätte heißen müssen.
So hätten wir ein Grundgerüst für viele Bereiche, wo man nach einem gewissen Datum mal nachschauen sollte, ob’ noch so stimmt, man muss nur das erste Wort passend wählen …