Derzeit sind im zHV für eine Reihe von Haltestellen mehrere Steige mit der gleichen Koordinate angegeben.
Da in Realität unterschiedliche Steige bis auf wenige Ausnahmen auch unterschiedliche Koordinaten aufweisen, gehen wir überwiegend von Datenfehlern aus. Solche Fehler erhöhen das Risiko, dass es zu falschen Steigzuordnungen von Bedienungen kommt, wie derzeit bei einigen Linien im GTFS-Sollfahrplan der Fall (siehe https://github.com/mfdz/GTFS-Issues/issues/147 und https://github.com/mfdz/GTFS-Issues/issues/149). Eine realitätsnahe Positionierung verbessert darüberhinaus die Möglichkeit zur automatischen Plausibilisierung, z.B. durch Abgleiche mit Datenquellen wie OSM oder auch Plausibilisierungen der Seitenlage zur Fahrtrichtung.
SELECT h.Authority, anzahl_hst_mit_doppelungen, anzahl_hst, ROUND(100.0*anzahl_hst_mit_doppelungen/ anzahl_hst,1) Prozent
FROM (SELECT Authority, count(*) anzahl_hst_mit_doppelungen
FROM (SELECT Authority, dhid, count(*) anzahl_verschiedener_koordinaten_doppelungen FROM
(SELECT s.Authority, s.dhid, q.Latitude,q.Longitude, count(*) anzahl_steige_mit_dieser_koordinate
FROM zhv q
JOIN zhv a ON a.DHID = q.Parent
JOIN zhv S ON s.DHID = a.Parent AND s.type='S'
WHERE s.lastOperationDate > '2024-05-09'
AND q.type='Q'
GROUP BY q.Authority, s.dhid, q.Latitude,q.Longitude
HAVING COUNT(*) > 1)
GROUP BY Authority, dhid)
GROUP by Authority) d
JOIN (SELECT Authority, count(*) anzahl_hst
FROM (SELECT s.Authority, s.dhid
FROM zhv s
WHERE s.type='S'
AND s.lastOperationDate > '2024-05-09'
GROUP BY s.Authority, s.dhid)
GROUP BY Authority) h ON h.Authority=d.Authority
ORDER BY ROUND(100.0*anzahl_hst_mit_doppelungen/ anzahl_hst,2) DESC;
Aufgeschlüsselt nach Authority ergibt sich:
Authority
anzahl_hst_mit_doppelungen
anzahl_hst
Prozent
NVV
721
3691
19.5
BEG
5956
42708
13.9
NVBW
2923
25680
11.4
VBN
2475
26300
9.4
VMV
562
8125
6.9
VRR
2782
46990
5.9
VMT
278
7133
3.9
HannIT
376
10123
3.7
Hamburger Hochbahn
275
8028
3.4
rms
285
10236
2.8
VVO
281
11115
2.5
NASA
32
10546
0.3
ZPS
11
3623
0.3
VBB
25
12717
0.2
VRN
22
17542
0.1
Da sich das LastOperationDate leider nicht auf Steige bezieht (siehe #25), sondern nur auf gesamte Haltestellen, ist es möglich, dass bei den Steigen auch mittlerweile nicht mehr gültige in die Zählung eingehen.
Beispiele betroffener Haltestellen:
WITH examples AS
(SELECT authority, dhid, count(*) anzahl_verschiedener_koordinaten_doppelungen,
ROW_NUMBER() OVER ( PARTITION BY authority) AS nr
FROM (SELECT s.Authority, s.dhid, q.Latitude,q.Longitude, count(*) anzahl_steige_mit_dieser_koordinate
FROM zhv q
JOIN zhv a ON a.DHID = q.Parent
JOIN zhv S ON s.DHID = a.Parent AND s.type='S'
WHERE s.lastOperationDate > '2024-05-09'
AND q.type='Q'
GROUP BY q.Authority, s.dhid, q.Latitude,q.Longitude
HAVING COUNT(*) > 1)
GROUP BY authority, dhid)
SELECT * FROM examples WHERE nr <= 3;
Derzeit sind im zHV für eine Reihe von Haltestellen mehrere Steige mit der gleichen Koordinate angegeben.
Da in Realität unterschiedliche Steige bis auf wenige Ausnahmen auch unterschiedliche Koordinaten aufweisen, gehen wir überwiegend von Datenfehlern aus. Solche Fehler erhöhen das Risiko, dass es zu falschen Steigzuordnungen von Bedienungen kommt, wie derzeit bei einigen Linien im GTFS-Sollfahrplan der Fall (siehe https://github.com/mfdz/GTFS-Issues/issues/147 und https://github.com/mfdz/GTFS-Issues/issues/149). Eine realitätsnahe Positionierung verbessert darüberhinaus die Möglichkeit zur automatischen Plausibilisierung, z.B. durch Abgleiche mit Datenquellen wie OSM oder auch Plausibilisierungen der Seitenlage zur Fahrtrichtung.
Aufgeschlüsselt nach Authority ergibt sich:
Da sich das LastOperationDate leider nicht auf Steige bezieht (siehe #25), sondern nur auf gesamte Haltestellen, ist es möglich, dass bei den Steigen auch mittlerweile nicht mehr gültige in die Zählung eingehen.
Beispiele betroffener Haltestellen: