Fehlende Haltestellen in zHV

[hbruch]

Der aktuelle Deutschland GTFS-Gesamtfahrplan beinhaltet 101614 Stops, welche nicht im zHV geführt sind. Dies, obwohl im gtfs-germany Feed derzeit noch die Fahrplandaten einiger Bundesländer fehlen.

select count(*) from gtfs_stops where stop_id not in (select dhid from zhv);
101614

Insbesondere scheint es sich (neben Halten außerhalb Deutschlands) um solche Halte zu handeln, deren stop_id nicht dem Aufbau der DHID entspricht. Beispiele:

...
de:15003:10464::02|Magdeburg, Am Pfahlberg|52.180028000000|11.627886000000|0|
000000737006|Magdeburg, Opernhaus|52.136197000000|11.639489000000|0|
de:11000:900040101::3|S Halensee (Berlin)|52.496998000000|13.290587000000|0|
de:11000:900074702::2|S Lichtenrade (Berlin) [Bus Prinzessinnenstr.]|52.386712000000|13.396173000000|0|
000120004624|S+U Warschauer Str. (Berlin)|52.505988000000|13.451641000000|0|
de:08436:48619:0:1_G|Leutkirch Adrazhofen, Rathaus|47.818378000000|10.057846000000|0|
de:08436:48619:0:2_G|Leutkirch Adrazhofen, Rathaus|47.818478000000|10.057935000000|0|
de:08436:1300:0:2_G|Leutkirch Schulzentrum|47.817973000000|10.019401000000|0|
de:08436:48518:0:1_G|Isny Bolsternang, Toracker|47.669334000000|10.103224000000|0|
...

Gruppiert nach den ersten 5 Zeichen der DHID lassen sich diese wie folgt zuordnen:

```sql
SELECT substr(stop_id, 1, 5),
       count(*)
FROM gtfs_stops
WHERE stop_id not in
    (SELECT dhid
     FROM zhv)
  AND (stop_id not like '__:__%'
       OR stop_id like 'de:__%')
GROUP BY substr(stop_id, 1, 5);

DHID-Präfix	Anzahl
00000	30077
00001	5535
00002	422
00003	35
00004	34
00005	7
00007	1
00009	45
00010	26
00012	1
00013	1
00016	3
00017	97
00018	5
00020	437
00024	3
00026	1
00031	2
00033	2
00034	3
08235	2
77283	1
de:01	46
de:02	85
de:03	2406
de:04	3
de:05	8400
de:06	139
de:07	9391
de:08	14564
de:09	12915
de:10	6463
de:11	90
de:12	114
de:13	7109
de:14	1462
de:15	780
de:16	11
de:51	6
de:57	1
de:82	1
de_08	1

Für manche dieser Stops scheint ein Duplikat mit offizieller DHID in den zHV-Daten enthalten zu sein, der Fehler also eher in einer fehlerhaften stop_id im GTFS-Feed zu liegen. Andere stops fehlen jedoch vollständig im zHV.

Stand der Daten zHV: 09.07.2021 GTFS: 16.07.2021

[Busfahrer795]

Wir wissen dass z.B. Sachsen-Anhalt (de:15) noch nicht regelmäßig an das zHv meldet. Das sollte sich aber im zweiten Halbjahr 2021 ändern.

[hbruch]

@delfi-fahrplandaten Danke für die Rückmeldung! Sachsen-Anhalt betrifft 780 von über 100.000, d.h. 1%. Gilt dies analog für alle anderen auch?

@NVBWSeifert, werden die Halte Baden-Württembergs regelmäßig an das zHV abgegeben? Es fehlen ca. 14.500 de:08 Halte.

[Busfahrer795]

Nein. Bis auf Sachsen-Anhalt und das Saarland liefern alle anderen Bundesländer regelmäßig Daten an das zHv.

[dancesWithCycles]

Hi @hbruch , Ich verwende vergleichbare SQL-Statements und habe eine SQL-Datenbank in die ich mit Hilfe von dem Projekt gtfs-schema periodisch den Delfi-Datensatz importiere. Diese Infrastruktur verwende ich bisher fuer das GTFS-Display. Zusaetzlich ist eine API fuer Webseiten-Interaktion in Arbeit/ in Erweiterung, damit wir das aktuelle Qualitaets-Problem komfortabler darstellen koennen als mit SQL-Statements.

Allerdings bin ich mit dem aktuellen Zustand unzufrieden, weil das GTFS-Schema nicht aktuell ist. Jetzt ueberlege ich Zeit in die Aktualisierung zu stecken oder andere Wege zu gehen.

Ich bin auch schon die ersten Schritte gegangen, um das Projekt gtfs-via-postgres von @derhuerst zu verwenden. Allerdings ist es inkompatibel zu meiner PostgreSQL Version 11.xy.

@hbruch , Wie importiertst du den Delfi- und zHV-Datensatz periodisch in deine SQL-Datenbank?

Hi @derhuerst , Besteht eine Chance, dass gtfs-via-postgers in Zukunft PostgreSQL Version 11.xy kompatibel wird? Welcher PostgreSQL-Version ist der kleinste gemeinsame Nenner oder ein Kompromiss in der Mitte?

Cheers!

[hbruch]

Aktuell (Datenstand 17.04.2023) sind 107242 im DELFI-GTFS-Feed enthaltene stops nicht im zHV geführt oder verwenden nicht die im zHV geführte DHID.

Bei der weitaus geringsten Anzahl an Haltestellen handelt es sich um Haltestellen im Ausland.

Für in Deutschland liegende stops des DELFI-Feed haben deren stop_id

1. keine dem DHID-Format entsprechende ID (in Karte gelb) a. manche verweisen immerhin auf einen im zHV geführten Parent stop (z.B. 000320239809 Frankfurt (Main) Nieder-Eschbach, mit Parent_stop de:06412:2398) b. manche aber auch nicht (z.B. 000001057704, Leipzig Julian-Marchlewski-Str., welche im zHV mit de:14713:12434 geführt wird )
2. oder einen dem DHID Format entsprechenden Aufbau, sind jedoch nicht im zHV geführt (z.B. Haltestelle Trockenborn mit stop_id de:16074:174385::17438500 jedoch ohne Parent_stop. Trockenborn ist als nicht mastscharfer Halt de:16074:174385 im zHV geführt) (in Karte orange dargestellt)
3. oder einen nahezu dem DHID Format entsprechenden Aufbau, enden jedoch auf _G (ggf. mehrfach angehängt) (in Karte blau dargestellt). Mutmaßlich weil ein Stop mit gleicher DHID nicht exakt identische Eigenschaften aufwies und deshalb Duplikate mit angehängtem _G generiert werden.

Ich halte die folgenden Maßnahmen für sinnvoll: Situation 1: Die betroffenen Verkehrsverbünde / Unternehmen sollten auf die Nutzung von DHIDs umstellen, möglichst steigscharf. Situation 2: die VU sollten prüfen, ob die Übermittlung ihrer Haltestellen und Fahrplandaten an den DELFI vollständig und korrekt erfolgt. Im o.g. Beispiel scheint der Mast de:16074:174385::17438500 nicht an das zHV übermittelt worden zu sein (wobei sich die Frage stellt, ob die Mast-Nummer tatsächlich die Haltestellennummer doppeln muss oder eine Form de:16074:174385:0:0 nicht auch verwendet werden kann) Situation 3: Die mutmaßlich durch die Datenausleitung des DELFI verursachten _G-Variationen sollten m.E. auf die im zHV geführten Angaben vereinheitlicht werden und Datenlieferanten entsprechende Hinweise / Korrekturaufforderungen zurückgemeldet werden.

[derhuerst]

Besteht eine Chance, dass gtfs-via-postgers in Zukunft PostgreSQL Version 11.xy kompatibel wird? Welcher PostgreSQL-Version ist der kleinste gemeinsame Nenner oder ein Kompromiss in der Mitte?

Wenn du einen akzeptablen Workaround für WITH NOT MATERIALIZED (PostgreSQL >=14) kennst, welches ich nutze, dann ja! Mach in diesem Fall am Besten ein Issue im Repo auf.

[dancesWithCycles]

Debian Bookworm koennte dieses Jahr veroeffentlicht werden. Damit waere PostgreSQL Version 15 per offiziellem Repository verfuegbar. ;-)

So lange wird meine Aktivitaet ruhen, wenn es keine Alternative als gtfs-schema oder gtfs-via-psql fuer den periodischen Import von Delfi- und zHV-Daten in eine SQL-Datenbank gibt. :-(

Cheers!

[hbruch]

@dancesWithCycles ich verwende https://github.com/mfdz/gtfs-sql-importer bzw. importiere direkt. Lass uns aber den Austausch zu GTFS-Import außerhalb dieses Issues vertiefen.

[dancesWithCycles]

Hat jemand diesen Validator bereits auf den Delfi-Datensatz angewandt?

Das Ergebnis fuer die aktuelle Woche (KW17 2023) sieht wie folgt aus.

https://nc.swingbe.de/index.php/s/7pdbpyaqtSd4p94

Versteht jemand diese Fehlerart?

stop_times.txt - 100 ERROR 
ERROR | stop_id | Wrong type ENTRANCE(2) for stop de:08315:6517:2:3 Ihringen Bahnhof, should be type STOP(0)

Ich vermute, dass diese Fehlerarten auch interessant ist.

stops.txt - 100 INFO - 500 WARNING - 101 ERROR 
ERROR | stop_lat, stop_lon | Stop at sequence 10 on examplar trip 2101927414 is too far from computed projection point (52.549073,13.388017) on shape 133559 (at arc-length 11877.32m): 128.68m away

transfers.txt - 200 WARNING - 100 ERROR
ERROR | from_stop_id, to_stop_id | Invalid value 69520.96 meters: Suspiciously large transfer distance between stops

Cheers!

[hbruch]

Diese Validator-Meldungen haben nichts mit diesem Issue zu tun. Bitte kommentiere neue Fehler des GTFS-Feeds im Repo https://github.com/mfdz/GTFS-Issues. Für die ersten beiden von Dir genannten Fehlertypen gibt es dort bereits Meldungen, z.B. https://github.com/mfdz/GTFS-Issues/issues/72 https://github.com/mfdz/GTFS-Issues/issues/126. Für die Transfer-Meldung macht vermutlich ein neuer Eintrag Sinn.

[dancesWithCycles]

Aktuell (Datenstand 17.04.2023) sind 107242 im DELFI-GTFS-Feed enthaltene stops nicht im zHV geführt oder verwenden nicht die im zHV geführte DHID.

Aktuell (Datenstand Mai 2023) koennen 106839 Haltestellen vom DELFI-GTFS-Datensatz nicht dem zHV zugeordnet werden.

Die Richtung stimmt!

Wer moechte mit mir ueber die Geschwindigkeit reden?

Angenommen ich habe mich nicht verrechnet, brauchen wir etwa 22 Jahr, um diese beiden Datensaetze in der aktuellen Geschwindigkeit abzugleichen. Das koennte ich noch erleben. ;-)

[dancesWithCycles]

Ich habe angefangen, eine API zu betreiben, damit wir die Daten mit mehr Komfort analysieren koennen. Die bisher einzige verfuegbare Route ist die folgende.

https://v1delfi.api.swingbe.de/stops-not-dhid?oset=48025&limit=1

Als Antwort erhalten wir Haltestellen aus dem DELFI-GTFS-Datensatz (entsprechend Offset oset und Limit limit), welche keine DHID verwenden. Stand May 2023 (KW19): 48025

Die aktuelle Anzahl von Haltestellen-Bezeichnern aus dem DELFI-GTFS-Datensatz, welche nicht kompatibel mit der DHID sind, koennen ueber diese Route abgefragt werden.

[hbruch]

Keine DHID ist wie definiert? Ich sehe wie oben beschrieben drei unterschiedliche Fälle. Ist der Code zum Tool offen und kannst Du ihn hier verlinken? Danke.

[dancesWithCycles]

Keine DHID ist wie definiert?

Das Dokument VDV-Schrift 432 | 09/2022 interpretiere ist so, dass eine DHID mindestens die drei Elemente Haltestellen: <LK>: <KS>: <lokale Haltestellen-ID> enthalten soll. Daraus ergibt sich das aktuelle SQL-Statement.

Ist der Code zum Tool offen und kannst Du ihn hier verlinken?

Der Code zum Tool ist public und free as in freedom. Das Repository ist aktuell noch nicht komplett, weil ich noch keine Gelegenheit hatte das gesamte Tool dorthin zu kopieren. Diese Arbeit ist hoffentlich nur eine Frage der Zeit ;-)

[dancesWithCycles]

Das Repository ist aktuell noch nicht komplett, weil ich noch keine Gelegenheit hatte das gesamte Tool dorthin zu kopieren. Diese Arbeit ist hoffentlich nur eine Frage der Zeit ;-)

Ich habe angefangen diese API mit einem Web-Dienst fuer Datenanalysen zu nutzen.

[dancesWithCycles]

Update: In der Zwischenzeit habe ich mein Delfi/NAP-Display erweitert.

Etwa 10 Prozent der Haltestellen im Delfi-Datensatz liegen ausserhalb von Deutschland. Diese habe ich jetzt gefiltert. Resultat Stand Juni 2023:

Number of stops of the DELFI GTFS feed: 523887 Number of stops of the DELFI GTFS feed inside DE: 480938

Es bleiben jetzt nur noch etwa 46000 Stops innerhalb DE uebrig, welche nicht kompatible mit der Global ID sind.

Ein Workaround, welcher die Halt-Id aus dem ZHV in Stops vom Delfi-Datensatz eintraegt, welche keine Global ID auf Bereichts- oder Mast-Ebene haben, habe ich auch schon ausprobiert. Bei Interesse ergaenze ich dieses Tuning online zu dem aktuellen Stand. Es ist nur die Frage, wann ich Luft holen kann, um mich damit zu beschaeftigen. ;-)

[dancesWithCycles]

Die Aanalyse auf der Seite zeigt den folgenden Stand fuer Ende Juni 2023 wie folgt:

Zentrales Haltestellenverzeichnis (ZHV)
Number of stops: 852707
DELFI GTFS Feed
Number of stops: 525308
Number of stops inside DE: 482368
Number of stops inside DE not compliant with the Global ID: 46051

Es koennte sein, dass die inside DE not compliant with the Global ID Halte im zHV enthalten sind, aber wegen fehlender Global ID nicht gefunden werden.

Daher habe ich hier eine Analyse ergaenzt, welche GTFS und zHV nicht Mittels Bezeichner oder Name zuordnet, sondern Mittels Koordinate. Auf Basis von Koordinaten habe ich die GTFS stop_id um die zHV Global ID erweitert. Angenommen die Koordinaten sind aehnlich, koennen Halte aus dem GTFS Feed dem zHV zugeordnet werden.

Ausserdem ist ein Vergleich von Koordinaten der Halte zwischen GTFS, zHV und OSM interessant. Im Idealfall, sind dies Datensaetze per Global ID verbunden und die Koordinaten identisch. Ein Traum. ;-)

[hbruch]

Hallo @dancesWithCycles. Danke für Deine Fortschritt-Reports zu deinem Abgleich. Ich würde dieses Ticket jedoch gerne etwas fokussierter halten.

Insbesondere hoffe ich auf eine Rückmeldung des DELFI e.V. zu den verschiedenen in https://github.com/mfdz/zhv-issues/issues/12#issuecomment-1513233901 genannten mutmaßlichen Problemursachen und wie eine Behebung dieser Abweichungen geplant ist.

[dancesWithCycles]

Aktuell (Datenstand 17.04.2023) sind 107242 im DELFI-GTFS-Feed enthaltene stops nicht im zHV geführt oder verwenden nicht die im zHV geführte DHID.

@hbruch Sind in den 107242 Stops die Eintraege gefiltert, welche ausserhalb von DE liegen und welche ungleich location_type=0 sind? Mit diesen beiden Filtern komme ich aktuell auf 26526 (6.476 %) Stops nicht konform zur DHID in den "DELFI-Datensatz GTFS" Daten.

[CM-RMS]

Um das zu recherchieren bitte 2-3 Beispiele angeben.

[dancesWithCycles]

@CM-RMS Wenn sie bitte meine Kontakt-Seite nutzen um mir eine Email zu schreiben, sende ich Ihnen gerne als Antwort alle 26526 (6.476 %) Stops nicht konform zur DHID aus "DELFI-Datensatz GTFS" per CSV-Datei.

Alternativ koennen sie hier live die Stops seitenweise durchblaettern, welche nicht konform zur DHID sind.

Zusaetzlich koennen sie hier live die Stops seitenweise durchblaetter, welche die angestrebte DHID als stop_id enthaelt.

[hbruch]

Nach meiner Auswertung sind allein > 54.000 GTFS-Stop-IDs mit location_type=0 mit Präfix de nicht im DELFI-Datensatz enthalten. Darüberhinaus weitere >28.000 mit location_type=0 mit den ersten beiden Stellen 00, also nicht DHID-konform, obwohl viele davon in Deutschland:

SELECT stop_id_first_two_letters, count(*) 
  FROM (
    SELECT substr(stop_id,1,2) stop_id_first_two_letters  
      FROM gtfs_stops 
     WHERE location_type='0' 
       AND NOT stop_id IN (SELECT dhid FROM zhv)) 
GROUP BY stop_id_first_two_letters;

00|28232
...
de|54781
...

Zufällig ausgewählte Beispiele zum Nachvollziehen:

SELECT *
  FROM gtfs_stops
 WHERE location_type='0'
   AND NOT stop_id IN (SELECT dhid FROM zhv)
   AND (stop_id LIKE '00%' or stop_id like 'de%')
 LIMIT 10;
000320439797|Bad Homburg v. d. H.-Gonzenheim (U)|50.219050000000|8.640304000000|0|000320439797|
de:06412:1370_G|Frankfurt (Main) Eschersheim Bahnhof|50.160146000000|8.655020000000|0|de:06412:1370|
de:06412:923:6:6|Frankfurt (Main) Stresemannallee/Gartenstraße|50.098119000000|8.669706000000|0|de:06412:923|
000320092041|Frankfurt (Main) Stresemannallee/Mörfelder Landstr|50.089440000000|8.671498000000|0|000320092041|
000320231291|Bad Homburg v. d. H.-Ober-Eschbach (U)|50.215208000000|8.651107000000|0|000320231291|
000320134904|Frankfurt (Main) Riedwiese/Mertonviertel|50.171374000000|8.642985000000|0|000320134904|
000320144509|Frankfurt (Main) Sigmund-Freud-Straße|50.154921000000|8.686205000000|0|000320144509|
000320150799|Frankfurt (Main) Bornheim Mitte|50.126344000000|8.708012000000|0|000320150799|
de:12054:900230004::3|S Babelsberg/Wattstr.|52.391578000000|13.094243000000|0|de:12054:900230004|
de:12054:900230028::1|S Babelsberg/Schulstr.|52.390628000000|13.090521000000|0|de:12054:900230028|

[dancesWithCycles]

Nach meiner Auswertung sind allein > 54.000 GTFS-Stop-IDs mit location_type=0 mit Präfix de nicht im DELFI-Datensatz enthalten.

Confirm!

Wenn du nur die Halte innerhalb Deutschland betrachtest, dann sind es aktuell etwa rund 49000 stop_ids.

SELECT foo.stop_id_2_char, count(*) FROM ( SELECT substr(stop_id,1,2) AS stop_id_2_char FROM test_analysis.tbl_gtfs_stops_de WHERE NOT stop_id IN (SELECT dhid FROM test_gtfs.stops_zhv )) AS foo GROUP BY stop_id_2_char;
 stop_id_2_char | count 
----------------+-------
 DE             |     2
...
 de             | 48963
...
 00             | 26377
...

Ich habe die Halte, welche nicht konform mit der DHID (aktuell rund 27000 stop_ids) mit den Halten, welche nicht konfrom mit der DHID UND im ZHV fehlen (aktuell rund 5X000 stop_ids) verwechselt. Entschuldigung!

[hbruch]

Sechs Monate später ergeben sich immer noch:

SELECT stop_id_first_two_letters, count(*)
  FROM (
    SELECT substr(stop_id,1,2) stop_id_first_two_letters
      FROM gtfs_stops
     WHERE location_type='0'
       AND NOT stop_id IN (SELECT dhid FROM zhv))
GROUP BY stop_id_first_two_letters;
00|25348
...
DE|2
..
de|50422

Ausgewählte Beispiele:

SELECT *
  FROM gtfs_stops
 WHERE location_type='0'
   AND NOT stop_id IN (SELECT dhid FROM zhv)
   AND (stop_id LIKE '00%' or stop_id like 'de%')
 LIMIT 10;
de:06434:559_G|Oberursel (Taunus)-Hohemark|50.215332000000|8.537144000000|0|de:06434:559|
de:06434:1513_G|Oberursel (Taunus) Altstadt|50.206033000000|8.578823000000|0|de:06434:1513|
...
de:12054:900230004::3|S Babelsberg/Wattstr.|52.391578000000|13.094243000000|0|de:12054:900230004|
de:12054:900230028::1|S Babelsberg/Schulstr.|52.390628000000|13.090521000000|0|de:12054:900230028|
de:11000:900074702::6|S Lichtenrade (Berlin)|52.386872000000|13.395325000000|0|de:11000:900074702|
de:12051:900275330::1|Brandenburg Görden Bhf Einkaufszentrum|52.426730000000|12.503137000000|0|de:12051:900275330|
...
000320231291|Bad Homburg v. d. H.-Ober-Eschbach (U)|50.215208000000|8.651107000000|0|000320231291|
000320134904|Frankfurt (Main) Riedwiese/Mertonviertel|50.171374000000|8.642985000000|0|000320134904|
000320144509|Frankfurt (Main) Sigmund-Freud-Straße|50.154921000000|8.686205000000|0|000320144509|
000320150799|Frankfurt (Main) Bornheim Mitte|50.126344000000|8.708012000000|0|000320150799|

@CM-RMS Gibt es neue Erkenntnisse bzgl. der Ursachen oder Aktivitäten, diese anzugehen?