Could not resolve (tag=us-ri-RIPTA)
sjwhitak opened this issue · comments
Hello,
I am failing to resolve many buses in the GTFS-rt API.
I'm trying to run transitous locally for a single configuration; the us-ri.json. I deleted all feeds to simply use us-ri.json only. I have the following setup:
I downloaded the two files here: http://download.geofabrik.de/north-america/us/rhode-island.html and placed them in out/ with the configuration config.ini pointing to those two files. I properly imported them into motis and when I deploy the server, I can see the map and three or four buses. The remaining forty buses in Rhode Island failed. The following is my entire log:
I'm unsure how to debug this. Would someone be able to help me figure out how to debug this? Is this a transitous or a motis issue?
As an update, this is a motis issue with not properly working with the RIPTA GTFS data format. I'll try to debug this more and send it over to their github issues.
There are three possible ways to report delays, motis only supports one of them. I'm interested in adding support for the delay attribute based one. Maybe that already helps
I pushed the issue to here: motis-project/motis#501 if you are curious. That is a good idea though, it could be with delays or alerts. I'll look into that tomorrow, thanks!
There are three possible ways to report delays, motis only supports one of them. I'm interested in adding support for the delay attribute based one. Maybe that already helps
It currently handles absolute times and delays:
- https://github.com/motis-project/nigiri/blob/5def8503fa8baf36cf5fc5fd69bef4e6c59e8456/src/rt/gtfsrt_update.cc#L87
- https://github.com/motis-project/nigiri/blob/5def8503fa8baf36cf5fc5fd69bef4e6c59e8456/src/rt/gtfsrt_update.cc#L92
What exactly is missing?
As far as I can see, TripUpdate.delay is not yet supported. Not sure how much it is used in practice, but this seems easier to implement when bridging third-party non-standard realtime APIs to GTFS-RT, which someone is working on.
From the documentation:
TripUpdate.delay should represent schedule deviation, i.e., the observed past value for how ahead/behind schedule the vehicle is. Predictions for future stops should be provided through StopTimeEvent.delay or StopTimeEvent.time.
For routing purposes, the predictions for future stops via StopTimeEvent.delay and StopTimeEvent.time are relevant (and already supported in MOTIS). The documentation doesn't state that this value should be used by consumers as kind of "default prediction". It's not clear to me what's the purpose of TripUpdate.delay.
If no other information is available, the StopTimeEvent.delay can be set to the TripUpdate.delay for the first stop. Consumers are supposed to propagate to all future stops.