Holger Bruch

Das Problem tritt mit dem Datensatz Stand 12.08.2024 weiterhin auf. Gibt es hierzu neue Erkenntnisse @CM-RMS ? ```sql SELECT distinct s.stop_id, location_type, a.agency_id, a.agency_name FROM agency a JOIN routes r...

Im DELFI e.V. GTFS-Feed vom 29.5. sieht die Lage korrekt aus. Womöglich ein Fehler in der Netex-Ausleitung oder der gtfs.de Aufbereitung? ```sh $ grep "Plohn, Freizeitpark" stops.txt "de:14523:444:2:1","","Plohn, Freizeitpark",,"50.570708000000","12.400337000000",0,,0,"","" ```...

Im zHV ist der Schlehenweg korrekt verortet (siehe https://gtfs.mfdz.de/delfi/region_de04011.html). Auch im GTFS-Feed des DELFI e.V. werden diese Koordinaten verwendet. Lässt sich die Lageabweichung direkt im Netex-Datensatz nachvollziehen?

@patrickbr Diese Fehlermeldung bezieht sich auf den gtfs.de Datensatz. In den DELFI e.V. GTFS Daten sowie dem DELFI zHV sind die Koordinaten korrekt. Liegt hier ein Transformationsfehler vor, oder sind...

Stand 22.5.: ```sql SELECT COUNT(*) FROM gtfs.stops WHERE NOT stop_id ~ '[a-z]{2}:.*'; count ------- 28541 ```

Mit dem DELFI-Datensatz vom 12.08.2024: ```sql SELECT COUNT(*) FROM stops WHERE NOT stop_id ~ '[a-z]{2}:.*'; ┌──────────────┐ │ count_star() │ │ int64 │ ├──────────────┤ │ 47000 │ └──────────────┘ ```

Fehler weiterhin vorhanden (Aktualisierungszeitpunkt der GTFS-Daten: 02.05.2022)

Fehler weiterhin für 63 Routen (davon 12 `DB`, 51 `SBB`) vorhanden (Aktualisierungszeitpunkt der GTFS-Daten: 21.02.2023) Als Workaround, um die Daten weiterverarbeiten zu können, kann z.B. wie folgt eine Korrektur vorgenommen...

Im Landkreis Rosenheim weichen für 200 Steige die Folgehalte in OSM von jenen der gematchten zHV-Haltestelle ab. Für die drei untersuchten Stichproben scheint die ref:IFOPT in OSM oder dem zHV...

Auch einige Halte des Aachener Verkehrsverbunds (AVV) sind betroffen: Hermesstraße (de:05334:4807:2:2): Monschau Kirche (de:05334:4811): Simmerath Einruhr (de:05334:5383):