European Sleeper in GTFS

[Sander van Hoogdalem]

Ik zit in de GTFS data te kijken van openOV (https://gtfs.openov.nl/gtfs-rt/). Het valt mij op dat daar geen European Sleeper tussen zit. Die zit in die van OVApi (https://gtfs.ovapi.nl/nl/) wel. Echter geeft de GTFS dataset van OVApi weer een hoop andere problemen in de API van Transitous en daarom willen we graag de GTFS van OpenOV er in zetten. 

Is er een mogelijkheid dat in de GTFS dataset van OpenOV ook European Sleeper wordt toegevoegd?

[Sander van Hoogdalem]

In de GTFS data van OVApi staat in Agency.txt European Sleeper, echter in de GTFS van OpenOV is dat niet het geval. Voor de API van Transitous is het beter als die van OpenOV gebruikt wordt, aangezien in die van OVApi stoparea's zitten zonder correcte GPS coördinaten waardoor de API niet goed werkt.

Kan European Sleeper toegevoegd worden aan de GTFS dataset van OpenOV?

[Stefan de Konink]

Het is eigenlijk wel grappig hoe je het omschrijft. Doordat alles in de GTFS van OVapi zit, heb je problemen.

Heb je al eens gekeken welke problemen regelmatig door European Sleeper worden veroorzaakt? (hint: het is een van de redenen dat het niet in de openOV publicatie zit)

In basis komt het neer dat DCRI/NS regelmatig gewoon matige brondata levert en we de rest van de publicatie daarmee niet willen blokkeren bij de grote platforms.

Stefan

[Sander van Hoogdalem]

Een uitleg:

MOTIS (de client achter transitous) controleert of haltes bij elkaar horen door middel van de coördinaten die meegeleverd worden. de stoparea's hebben geen valide coördinaten  ( dit staat bijvoorbeeld bij KNMI De Bilt: 0.08250667933491687,0.00820690657165479) maar de gekoppelde haltes wel. Om die reden kunnen de stoparea's niet gekoppeld worden en de logica achter die "Coords" is mij onduidelijk. Maar daardoor worden bij bushaltes die een stoparea hebben in Diever vertrekken getoond van haltes uit Apeldoorn, Emmen, Groningen en Nijmegen omdat die "coördinaten" bij elkaar in de buurt liggen. Om die reden geeft het dus echt problemen omdat "alles" er in zit.
Als je toevallig weet hoe die logica met stoparea's en coördinaten zit dan hoor ik dat graag zodat daar misschien de oplossing gezocht kan worden voor het specifieke transitous probleem. 

Ik wist overigens niet dat European Sleeper zulke belabberde data aanlevert. Maar aangezien OVApi de enige is die die data levert, lijkt het erop dat we die toch moeten gebruiken omdat anders gebruikers van de app träwelling weer gaan zeuren dat de European Sleeper ontbreekt (en dat kan echt een vervelende community zijn) en dat is dus juist wat we niet willen om geen problemen met data te hebben.

Op vrijdag 25 juli 2025 om 23:02:14 UTC+2 schreef Stefan de Konink:

[Stefan de Konink]

Ik heb vernomen dat er een bak NLNet-geld aan MOTIS is uitgedeeld om
NeTEx en SIRI te implementeren. Als MOTIS de Nederlandse data in NeTEx
wil verwerken, dan kan dat ook he :) Dan zit je rechtstreeks op de bron
en kun je alle problemen in de bron data zelf oplossen. Klinkt als
win-win ;)

https://data.ndovloket.nl/netex/

Hoe kom je er bij dat OVapi de enige is? Je kunt gewoon bij de bron
informatie die NS/DCRI aanlevert.

https://data.ndovloket.nl/iff/

--
Stefan

[Sander van Hoogdalem]

Maar dat is niet in GTFS beschikbaar. Wat betreft het omzetten naar NeTEx: daar wordt momenteel naar gekeken. Alleen ik zie bijvoorbeeld dat Keolis al een tijdje geen nieuwe NeTEx file heeft aangeleverd? Aan datum format te zien van het bestand is die dan niet meer geldig? Of wel?

Op zaterdag 26 juli 2025 om 01:23:01 UTC+2 schreef Stefan de Konink:

[Stefan de Konink]

Op 7/26/25 om 12:33 PM schreef Sander van Hoogdalem:

> Maar dat is niet in GTFS beschikbaar.

Jawel hoor in de OVapi GTFS ;)

> Wat betreft het omzetten naar NeTEx: daar wordt momenteel naar gekeken.

Niet omzetten naar NeTEx, de NeTEx bestanden gebruiken in plaats van GTFS.

> Alleen ik zie bijvoorbeeld dat
> Keolis al een tijdje geen nieuwe NeTEx file heeft aangeleverd? Aan datum
> format te zien van het bestand is die dan niet meer geldig? Of wel?

Ik weet niet naar welke map jij zit te kijken, maar de laatste levering
is 8 juli geweest en dat lijkt me prima.

https://data.ndovloket.nl/netex/keolis/

--
Stefan

[Sander van Hoogdalem]

Maar ik heb aangegeven om welke reden de OVApi GTFS niet handig is om te gebruiken 😉

Bestandsnaam van Keolis heeft 2 data. Laatste is 20250713. 

Op zaterdag 26 juli 2025 om 13:22:02 UTC+2 schreef Stefan de Konink:

[Stefan de Konink]

Iemand heeft bedacht dat dat de ingangsdatum is.

Stefan