Alternatieven voor OTP (of betere instellingen) in Nederland
60 views
Skip to first unread message
Tristan van Triest
Jan 12, 2023, 2:33:14 PM1/12/23
to openov
Hallo allen,
Ik ben recentelijk wat gaan spelen met OTP 2 (Open Trip Planner) en de Nederlandse GTFS-RT stromen. Dit om te kijken wat er mogelijk is met betrekking tot het inbouwen van een routeplanner in mijn project.
Nu heb ik gemerkt dat OTP op zichzelf best een goed systeem is, maar in combinatie met het Nederlandse systeem en GTFS-RT, nogal wat problemen heeft.
OTP geeft namelijk ontzettend veel foutmeldingen (vooral bij de TrainUpdates feed) over niet-correcte stop volgordes. Hierdoor word deze data niet in de graph geupdated.
Ik heb met de GTFS-RT validator van OpenMobilityData gekeken of er ook echt zoveel fouten in de feed zaten als OTP aangaf. Dit is het resultaat:
Ookal komen hier dezelfde foutmeldingen voor, het lijkt wel in veel mindere getalen te zijn.
Hiermee komen mij twee vragen te boven.
1. Is er iets wat ik aan de configuratie (of set-up) van OTP aan kan passen zodat ik minder foutmeldingen krijg? (Op dit moment word er van treinvervoer dus slechts 49% goedgekeurd en van busvervoer 93%).
Aangezien Stefan al vaker heeft laten blijken dat de gegevens voor treinvervoer vanuit GTFS niet de meest ideale manier is van werken, heb ik hier weinig hoop voor.
Ik heb wel even gecontroleerd uiteraard of deze ritten met foutmeldingen in de GTFS te vinden waren, en dat is wel degelijk het geval. (Ook OTP kon een route plannen met deze ritten, echter zonder realtime gegevens).
2. Zijn er alternatieven voor OTP om alsnog een reisplanner te kunnen integreren?
Ik ben bekend met NS's API portal en hun "trips" API, echter lijkt deze alleen Station tot Station te kunnen navigeren met publieke API keys. Na contact op te zoeken met NS MLAB kreeg ik het antwoord dat "Deur tot Deur adviezen niet via deze API verstrekt kunnen worden".
Dus dan is mijn vraag, zijn er nog alternatieven om toch tenminste, wat betrouwbaardere informatie te kunnen verkrijgen?
Ik heb zelf een database met de ruwe KV1,7 & 8 en InfoPlus brondata, echter lijkt het mij zonde om het wiel opnieuw uit te vinden terwijl er waarschijnlijk al iemand die hier veel beter in is een oplossing voor heeft gevonden?
Alvast bedankt,
Tristan
Ik ben recentelijk wat gaan spelen met OTP 2 (Open Trip Planner) en de Nederlandse GTFS-RT stromen. Dit om te kijken wat er mogelijk is met betrekking tot het inbouwen van een routeplanner in mijn project.
Nu heb ik gemerkt dat OTP op zichzelf best een goed systeem is, maar in combinatie met het Nederlandse systeem en GTFS-RT, nogal wat problemen heeft.
OTP geeft namelijk ontzettend veel foutmeldingen (vooral bij de TrainUpdates feed) over niet-correcte stop volgordes. Hierdoor word deze data niet in de graph geupdated.
Ik heb met de GTFS-RT validator van OpenMobilityData gekeken of er ook echt zoveel fouten in de feed zaten als OTP aangaf. Dit is het resultaat:
Ookal komen hier dezelfde foutmeldingen voor, het lijkt wel in veel mindere getalen te zijn.
Hiermee komen mij twee vragen te boven.
1. Is er iets wat ik aan de configuratie (of set-up) van OTP aan kan passen zodat ik minder foutmeldingen krijg? (Op dit moment word er van treinvervoer dus slechts 49% goedgekeurd en van busvervoer 93%).
Aangezien Stefan al vaker heeft laten blijken dat de gegevens voor treinvervoer vanuit GTFS niet de meest ideale manier is van werken, heb ik hier weinig hoop voor.
Ik heb wel even gecontroleerd uiteraard of deze ritten met foutmeldingen in de GTFS te vinden waren, en dat is wel degelijk het geval. (Ook OTP kon een route plannen met deze ritten, echter zonder realtime gegevens).
2. Zijn er alternatieven voor OTP om alsnog een reisplanner te kunnen integreren?
Ik ben bekend met NS's API portal en hun "trips" API, echter lijkt deze alleen Station tot Station te kunnen navigeren met publieke API keys. Na contact op te zoeken met NS MLAB kreeg ik het antwoord dat "Deur tot Deur adviezen niet via deze API verstrekt kunnen worden".
Dus dan is mijn vraag, zijn er nog alternatieven om toch tenminste, wat betrouwbaardere informatie te kunnen verkrijgen?
Ik heb zelf een database met de ruwe KV1,7 & 8 en InfoPlus brondata, echter lijkt het mij zonde om het wiel opnieuw uit te vinden terwijl er waarschijnlijk al iemand die hier veel beter in is een oplossing voor heeft gevonden?
Alvast bedankt,
Tristan
Stefan de Konink
Jan 12, 2023, 2:47:47 PM1/12/23
to ope...@googlegroups.com
Hoi Tristan,
On Thursday, January 12, 2023 8:33:14 PM CET, Tristan van Triest wrote:
> OTP geeft namelijk ontzettend veel foutmeldingen (vooral bij de
> TrainUpdates feed) over niet-correcte stop volgordes. Hierdoor word deze
> data niet in de graph geupdated.
Ik zie dat in de specificaties staat "The updates must be sorted by
stop_sequence" om eerlijk te zijn vraag ik me af of deze requirement nieuw
is. Aan de andere kant lijkt het me het op zich geen lastige fix, tenzij de
fout over iets anders gaat (lees: niet de volgorde, maar meer informatie).
Lijkt me onderzoekswaardig. Kan jouw GTFS-RT validator ook snel een JSON
string uitvoeren van een entity fout is?
> Hiermee komen mij twee vragen te boven.
>
> 1. Is er iets wat ik aan de configuratie (of set-up) van OTP aan kan passen
> zodat ik minder foutmeldingen krijg? (Op dit moment word er van
> treinvervoer dus slechts 49% goedgekeurd en van busvervoer 93%).
>
> Aangezien Stefan al vaker heeft laten blijken dat de gegevens voor
> treinvervoer vanuit GTFS niet de meest ideale manier is van werken, heb ik
> hier weinig hoop voor.
Dat gaat eigenlijk over iets anders. Het annuleren en toevoegen van nieuwe
ritten. In OTP1 was met het laatste geen enkel probleem. Ik heb OTP2 nog
nooit zelf gebruikt in samenhang met realtime data.
> Ik heb wel even gecontroleerd uiteraard of deze ritten met foutmeldingen in
> de GTFS te vinden waren, en dat is wel degelijk het geval. (Ook OTP kon een
> route plannen met deze ritten, echter zonder realtime gegevens).
Graag screenshotje. Er is een eenvoudig tooltje om Protobuf naar JSON om te
zetten, zodat we in ieder geval zichtbaar kunnen maken waar het probleem
zou kunnen zitten.
> 2. Zijn er alternatieven voor OTP om alsnog een reisplanner te kunnen
> integreren?
> Ik ben bekend met NS's API portal en hun "trips" API, echter lijkt deze
> alleen Station tot Station te kunnen navigeren met publieke API keys. Na
> contact op te zoeken met NS MLAB kreeg ik het antwoord dat "Deur tot Deur
> adviezen niet via deze API verstrekt kunnen worden".
>
> Dus dan is mijn vraag, zijn er nog alternatieven om toch tenminste, wat
> betrouwbaardere informatie te kunnen verkrijgen?
>
> Ik heb zelf een database met de ruwe KV1,7 & 8 en InfoPlus brondata, echter
> lijkt het mij zonde om het wiel opnieuw uit te vinden terwijl er
> waarschijnlijk al iemand die hier veel beter in is een oplossing voor heeft
> gevonden?
Kreeg van de week de vraag van een ander mijn reactie daarop was;
"Als je geen problemen hebt om het zelf te doen zijn er nog een aantal
andere opties. OpenTripPlanner2 (java), Graphhopper (java), Itinero (C#),
en Valhalla (C++) kun je zelf installeren en heb je geen commerciële
beperkingen. Het betekent natuurlijk wel dat je zelf verantwoordelijk bent
voor het updaten.
Je weet wellicht nog dat we in 2013 zelf een reisplanner hebben gemaakt,
[...]. Die reisplanner kun je in principe in een bestaande applicatie
'hangen' en heeft daardoor ook de mogelijkheid om het geheel als Python
module te gebruiken. Het is alleen een OV-reisplanner en heeft wederom
input data nodig die van een behoorlijke kwaliteit is."
--
Stefan
On Thursday, January 12, 2023 8:33:14 PM CET, Tristan van Triest wrote:
> OTP geeft namelijk ontzettend veel foutmeldingen (vooral bij de
> TrainUpdates feed) over niet-correcte stop volgordes. Hierdoor word deze
> data niet in de graph geupdated.
stop_sequence" om eerlijk te zijn vraag ik me af of deze requirement nieuw
is. Aan de andere kant lijkt het me het op zich geen lastige fix, tenzij de
fout over iets anders gaat (lees: niet de volgorde, maar meer informatie).
Lijkt me onderzoekswaardig. Kan jouw GTFS-RT validator ook snel een JSON
string uitvoeren van een entity fout is?
> Hiermee komen mij twee vragen te boven.
>
> 1. Is er iets wat ik aan de configuratie (of set-up) van OTP aan kan passen
> zodat ik minder foutmeldingen krijg? (Op dit moment word er van
> treinvervoer dus slechts 49% goedgekeurd en van busvervoer 93%).
>
> Aangezien Stefan al vaker heeft laten blijken dat de gegevens voor
> treinvervoer vanuit GTFS niet de meest ideale manier is van werken, heb ik
> hier weinig hoop voor.
ritten. In OTP1 was met het laatste geen enkel probleem. Ik heb OTP2 nog
nooit zelf gebruikt in samenhang met realtime data.
> Ik heb wel even gecontroleerd uiteraard of deze ritten met foutmeldingen in
> de GTFS te vinden waren, en dat is wel degelijk het geval. (Ook OTP kon een
> route plannen met deze ritten, echter zonder realtime gegevens).
zetten, zodat we in ieder geval zichtbaar kunnen maken waar het probleem
zou kunnen zitten.
> 2. Zijn er alternatieven voor OTP om alsnog een reisplanner te kunnen
> integreren?
> Ik ben bekend met NS's API portal en hun "trips" API, echter lijkt deze
> alleen Station tot Station te kunnen navigeren met publieke API keys. Na
> contact op te zoeken met NS MLAB kreeg ik het antwoord dat "Deur tot Deur
> adviezen niet via deze API verstrekt kunnen worden".
>
> Dus dan is mijn vraag, zijn er nog alternatieven om toch tenminste, wat
> betrouwbaardere informatie te kunnen verkrijgen?
>
> Ik heb zelf een database met de ruwe KV1,7 & 8 en InfoPlus brondata, echter
> lijkt het mij zonde om het wiel opnieuw uit te vinden terwijl er
> waarschijnlijk al iemand die hier veel beter in is een oplossing voor heeft
> gevonden?
"Als je geen problemen hebt om het zelf te doen zijn er nog een aantal
andere opties. OpenTripPlanner2 (java), Graphhopper (java), Itinero (C#),
en Valhalla (C++) kun je zelf installeren en heb je geen commerciële
beperkingen. Het betekent natuurlijk wel dat je zelf verantwoordelijk bent
voor het updaten.
Je weet wellicht nog dat we in 2013 zelf een reisplanner hebben gemaakt,
[...]. Die reisplanner kun je in principe in een bestaande applicatie
'hangen' en heeft daardoor ook de mogelijkheid om het geheel als Python
module te gebruiken. Het is alleen een OV-reisplanner en heeft wederom
input data nodig die van een behoorlijke kwaliteit is."
--
Stefan
Tristan van Triest
Jan 12, 2023, 3:05:11 PM1/12/23
to openov
Hi Stefan,
Wederom dank voor je snelle en uitgebreide reactie.
>Kan jouw GTFS-RT validator ook snel een JSON
>string uitvoeren van een entity fout is?
Ik zal uiteraard ook kunnen bekijken hoe ver ik kom met een oudere versie van OTP (2.0/2.1 ipv 2.2) of helemaal terug naar OTP 1.X gaan, daar heb ik zelf nog niet naar gekeken.
>Graag screenshotje. Er is een eenvoudig tooltje om Protobuf naar JSON om te
>zetten, zodat we in ieder geval zichtbaar kunnen maken waar het probleem
>zou kunnen zitten.
Met vriendelijke groeten,
Tristan
Op donderdag 12 januari 2023 om 20:47:47 UTC+1 schreef ste...@konink.de:
Tristan van Triest
Jan 12, 2023, 3:48:04 PM1/12/23
to openov
Hi Stefan,
Hierbij de beloofde data bestanden. Het lijkt inderdaad vooral te gaan om "is not strictly sorted by increasing stop_sequence". Bijgevoegd vind je de OTP foutmeldingen, de bijbehorende ontvangen RT data en de uitkomsten van de GTFS-RT analyzer.
Nu heb ik zelf weinig kaas gegeten van GTFS-RT, dus ik kan je niet veel meer context geven dan dit.
Ik heb zelf handmatig even de bestanden doorgezocht naar 1 van de trips (161741042)
{
"id": "161741042",
"tripUpdate": {
"trip": {
"tripId": "161741042",
"startTime": "21:53:00",
"startDate": "20230112",
"scheduleRelationship": "SCHEDULED",
"routeId": "17522",
"directionId": 0
},
"stopTimeUpdate": [
{
"departure": {
"delay": 0,
"time": "1673556780"
},
"stopId": "2422005",
"scheduleRelationship": "SCHEDULED"
},
{
"stopId": "2423255"
},
{
"stopId": "2423251",
"scheduleRelationship": "SKIPPED"
},
{
"arrival": {
"delay": 0,
"time": "1673557680"
},
"departure": {
"delay": 0,
"time": "1673557800"
},
"stopId": "2422149",
"scheduleRelationship": "SCHEDULED"
},
{
"stopId": "2423329"
},
{
"arrival": {
"delay": 0,
"time": "1673559360"
},
"stopId": "2427767",
"scheduleRelationship": "SCHEDULED"
}
]
}
},
Dit is de volledige trip update. Lijkt erop dat de tijden weldegelijk in de juiste volgorde staan (of ik moet iets over het hoofd zien).
Kijkende in stop_times.txt lijken er voor deze trip slechts 3 stops te zijn (waar is sequence stop 2,3 en 5?):
161741042,1,2422005,,21:53:00,21:53:00,0,1,1,1,0
161741042,4,2422149,,22:08:00,22:10:00,0,0,1,17036,0
161741042,6,2427767,,22:36:00,22:36:00,1,0,1,69921,0
Zo te zien staat er in de GTFS-RT een extra "SKIPPED" stop welke hier niet in voor komt, wellicht hebben we het probleem daar te zoeken?
Dit is de foutmelding die de GTFS-RT analyzer geeft.
Dit is de volledige trip update. Lijkt erop dat de tijden weldegelijk in de juiste volgorde staan (of ik moet iets over het hoofd zien).
Kijkende in stop_times.txt lijken er voor deze trip slechts 3 stops te zijn (waar is sequence stop 2,3 en 5?):
161741042,1,2422005,,21:53:00,21:53:00,0,1,1,1,0
161741042,4,2422149,,22:08:00,22:10:00,0,0,1,17036,0
161741042,6,2427767,,22:36:00,22:36:00,1,0,1,69921,0
Zo te zien staat er in de GTFS-RT een extra "SKIPPED" stop welke hier niet in voor komt, wellicht hebben we het probleem daar te zoeken?
Dit is de foutmelding die de GTFS-RT analyzer geeft.
"152","E002","trip_id 161741042 stop_sequence for stop_ids [2422005, 2423255, 2423251, 2422149, 2423329, 2427767] is not strictly sorted by increasing stop_sequence".
Hier staan nog andere stops in welke uberhaupt niet in de stop_times voor deze specifieke trip staan.
Hier staan nog andere stops in welke uberhaupt niet in de stop_times voor deze specifieke trip staan.
2423255 - Adam Sloterdijk
2423251 - Adam Lelylaan
2422149 - Schiphol
2423329 - Hoofddorp
2427767 - Rotterdam Centraal
Deze opgegeven volgorde in de foutmelding van stations lijkt mij correct voor deze lijn?
Meer dan dit zal ik zelf niet durven te zeggen, wellicht kan jij er nog iets in vinden!
Dankjewel,
Tristan
Stefan de Konink
Jan 12, 2023, 4:21:58 PM1/12/23
to ope...@googlegroups.com
On Thursday, January 12, 2023 9:48:04 PM CET, Tristan van Triest wrote:
> Zo te zien staat er in de GTFS-RT een extra "SKIPPED" stop
> welke hier niet in voor komt, wellicht hebben we het probleem
> daar te zoeken?
Ik gok dat dit de tussenliggende stops uit RitInfo zijn (waar bijvoorbeeld
> Zo te zien staat er in de GTFS-RT een extra "SKIPPED" stop
> welke hier niet in voor komt, wellicht hebben we het probleem
> daar te zoeken?
een intercity niet stopt). Ik heb net de maker van de GTFS-RT validator al
een berichtje gestuurd, ik zou een bug report aanmaken bij OTP2. Je mag
natuurlijk veel van de data vinden, maar dat overcomplete data een probleem
geeft blijft een bug.
--
Stefan
Tristan van Triest
Jan 12, 2023, 5:06:51 PM1/12/23
to openov
>Ik gok dat dit de tussenliggende stops uit RitInfo zijn (waar bijvoorbeeld
>een intercity niet stopt). Ik heb net de maker van de GTFS-RT validator al
>een berichtje gestuurd, ik zou een bug report aanmaken bij OTP2. Je mag
>natuurlijk veel van de data vinden, maar dat overcomplete data een probleem
>geeft blijft een bug.
Grote kans inderdaad. Ik heb namelijk even bij NS zelf gekeken, en er lijkt geen trein te zijn die bij al die stations stopt op die manier.>een intercity niet stopt). Ik heb net de maker van de GTFS-RT validator al
>een berichtje gestuurd, ik zou een bug report aanmaken bij OTP2. Je mag
>natuurlijk veel van de data vinden, maar dat overcomplete data een probleem
>geeft blijft een bug.
Ik heb een issue op de OTP Github aangemaakt:
OTP gives "INVALID_STOP_SEQUENCE" error for "overcomplete" GTFS-RT data · Issue #4702 · opentripplanner/OpenTripPlanner (github.com)
Laten we hopen dat er iets mee gedaan kan worden. Anders word het toch een andere manier zoeken om het werkend te krijgen. Ik ben nu op de achtergrond versie 2.0.0 maar eens aan het proberen, en als dat niet werkt versie 1.X. Ik zal je op de hoogte houden.
Op donderdag 12 januari 2023 om 22:21:58 UTC+1 schreef ste...@konink.de:
Reply all
Reply to author
Forward
0 new messages