[RFC] Feature-Proposal Gültigkeit von Routenrelationen

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

Nakaner wrote:

Statt timetable:valid_until=* wird er dann recheck_itinerary_route_by=* heißen.

Die Routen haben prinzipiell in OSM nichts verloren.

toc-rox wrote:

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.

Nakaner wrote:

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.

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.

Nakaner wrote:

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.

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.

Nakaner wrote:

Wir mappen jedoch keine historischen Routenrelationen des öffentlichen Verkehrs.

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,

Weide wrote:

Nakaner wrote:

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.

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.

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

Weide wrote:

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 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 ;-)

Hallo,

OEPNV_Achim wrote:

Weide wrote:

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 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 ;-)

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:

Wenn du eine Routenrelation findest, deren timetable:valid_until=* abgelaufen ist, ist es nicht richtig, sie sofort zu löschen. Du solltest nicht einfach Daten löschen, nur weil ein Verfallsdatum verstrichen ist. Es gelten hier dieselben ungeschriebenen Regeln, die auch für check_date=* gelten.

Viele Grüße

Michael

Nakaner wrote:

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:

Wenn du eine Routenrelation findest, deren timetable:valid_until=* abgelaufen ist, ist es nicht richtig, sie sofort zu löschen. Du solltest nicht einfach Daten löschen, nur weil ein Verfallsdatum verstrichen ist. Es gelten hier dieselben ungeschriebenen Regeln, die auch für check_date=* gelten.

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 ...