Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fehlerhafte LastOperationDate-Angaben #23

Open
hbruch opened this issue Jul 18, 2023 · 4 comments
Open

Fehlerhafte LastOperationDate-Angaben #23

hbruch opened this issue Jul 18, 2023 · 4 comments

Comments

@hbruch
Copy link
Member

hbruch commented Jul 18, 2023

Mit dem zHV-Datensatz vom 18.7.2023 wurden die bisherigen Attribute state und condition ersetzt durch das neu eingeführte Attribut LastOperationDate.

Die dem Datensatz beigefügte Information Metadaten / aktuelle Hinweise / Tabellenaufbau führt hierzu aus:

Die Felder Condition (Betriebszustand) und State (Status) entfallen und werden durch das Feld „LastOperationDate“ ersetzt. Dieses wird auf der Ebene Mast (Quay) und auf der Ebene Haltestelle (stop) ermittelt und ausgewiesen. Das ausgewiesene Datum gibt den Tag an, an dem in den aktuellen Fahrplandaten zum letzten Mal eine Fahrt an dem entsprechenden Haltestellenobjekt hält. Bei regelmäßig bedienten Objekten liegt das Datum in der Zukunft und typischerweise am Ende der im Fahrplandatensatz abgelegten Fahrplanperiode. Bei nicht mehr bedienten Haltestellenobjekten liegt das Datum in der Vergangenheit und entspricht dem Tag der letzten Bedienung.

Für sämtliche 853912 Einträge ist als LastOperationDate fälschlicherweise "31.12.1999 00:00:00" angegeben, wonach sämtliche Halte in Deutschland seit dem 1.1.2000 unbedient wären.

Unabhängig von der fehlerhaften Befüllung hätten wir geraten, den Zeitstempel im ISO-8601-Timestamp-Format bzw. Datumsformat zu formatieren.

@hbruch
Copy link
Member Author

hbruch commented Jul 18, 2023

Zusätzliche Anmerkung: für eine sanftere Migration wäre es aus unserer Sicht hilfreich gewesen, die Attribute State und Condition noch eine Übergangszeit zusätzlich zum neuen Attribut LastOperationDate zu führen. Dies würde auch die Durchführung von Plausibilitätstests erleichtern.

@hbruch
Copy link
Member Author

hbruch commented Jul 19, 2023

Rückmeldung hierzu:

Leider kam es bei der Systemaktualisierung am Montag zu Verzögerungen. Daher wurde der Import, der unter anderem das LastOperationDate aktualisiert, erst gestern durchgeführt. Zu diesem Zeitpunkt war die (automatische) Bereitstellung des zHV-Datensatzes als Download bereits abgeschlossen. Mittlerweile ist jedoch ein aktueller Datenstand verfügbar.
Ebenso sind sämtliche Datumsangaben in den Exportdateien nun einheitlich in einem ISO-8601-Format.
Das Datum "31.12.1999" ist im zHV der gültige Standardwert für ein fehlendes oder unbekanntes Datum.

Der aktualisierte Datenbestand vom 19.7.2023 gibt nun für 441.568 S,A,Q-Objekte ein Gültigkeitsdatum > 31.12.1999 an. Allerdings ist für viele Steige/Masten die Angabe immer noch falsch (siehe nachfolgendes Bild). Insbesondere scheinen in den GTFS-Daten nicht mastscharf referenzierte Steige nun als nicht bedient (in Karte als graue Punkte dargestellt) angegeben zu werden.

image

Bild: Alle im zHV Datensatz Stand 19.7.2023 enthaltenen Steige (Type='Q'). Grün: LastOperationDate <> 1999-12-31, Grau: LastOperationDate = 1999-12-31 Hintergrundkarte: © OpenStreetMap Mitwirkende. Tiles courtesy of Andy Allan, Haltestellendaten: DELFI e.V.

@hbruch
Copy link
Member Author

hbruch commented Jul 19, 2023

Nachtrag: auch in den Sollfahrplandaten referenzierte Steige, z.B. de:08111:2419:0:3 und de:08111:2419:0:4 werden als zuletzt am 31.12.1999 bedient ausgewiesen:

$ grep de:08111:2420 zHV_aktuell_csv.2023-07-19.csv
"1195";"S";"de:08111:2420";"de:08111:2420";"Laihle";"48,78213";"9,130935";"08111000";"Stuttgart";"-";"-";"";"NVBW";"-";"D91FAF000974";"-";"2023-12-09T00:00:00"
"1196";"Q";"de:08111:2420:0:3";"de:08111:2420";"3";"48,781923";"9,130557";"00000000";"-";"-";"-";"Rtg Händelstr.";"NVBW";"-";"-";"-";"1999-12-31T00:00:00"
"1197";"Q";"de:08111:2420:0:4";"de:08111:2420";"4";"48,782409";"9,131222";"00000000";"-";"-";"-";"Rtg Paul-Lincke-Str.";"NVBW";"-";"-";"-";"1999-12-31T00:00:00"

Auszug aus stop_times.txt des GTFS-Datensatzes vom 17.7.2023:

$ grep de:08111:2420 stop_times.txt
...
2192177452,20:48:30,20:48:30,"de:08111:2420:0:3",11,0,0,""
2192177451,21:18:30,21:18:30,"de:08111:2420:0:3",11,0,0,""
2192177403,5:54:00,5:54:00,"de:08111:2420:0:4",3,0,0,""
2192177402,5:54:00,5:54:00,"de:08111:2420:0:4",12,0,0,""
...

@hbruch
Copy link
Member Author

hbruch commented Jul 22, 2023

Im zHV Datensatz vom 19.7.2023 sind

  • 229.232 Quays mit LastOperationDate=1999-12-31 (unbedient) ausgewiesen, obwohl sie in der stops.txt des DELFI GTFS-Feeds vom 17.7. enthalten sind (rot dargestellt, niedrigste Zeichenebene, daher meist verdeckt).
  • 10.785 Quays als unbedient ausgewiesen, deren übergeordnete Haltestelle zwar bedient sein soll, jedoch kein einziger der untergeordneten Steige bedient ist (gelb dargestellt). In den GTFS-Daten liegen dann entweder keine steigscharfen Informationen vor, oder die dort bedienten Steige haben gänzlich andere DHIDs als die im zHV geführten.
  • 157.947 laut zHV in 2023 bedienten Steige (grün dargestellt)
  • 73.719 Steige, die unter keine der vorgenannten Kategorien fallen, d.h. womöglich tatsächlich nicht bedient wären, falls der GTFS-Feed vollständig und korrekt sein sollte (grau dargestellt). Leider ist dies nicht der Fall, denn es fehlen z.B. vielfach OnDemand-Angebote ( ein Beispiel ist der Holzkirchener Hoki), deren Haltestellen nun als nicht bedient erscheinen.

In nur lückenhaft eingefärbten Regionen Deutschlands liegen nur sehr wenige Haltestellen steigscharf im zHV vor.

image

(Auswertung am 23.7. aktualisiert, in erster Statistik hatte ich fälschlicherweise viele der unbedienten Quays vermeintlich bedienten Halten zugeordnet, dies es jedoch nicht waren)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant