Configuration messed up with nigiri and database #501
Comments
|
Regarding this resolve error: This looks like this bug in TheTransitClock. Someone wanted to fix it but got ignored by the repo maintainer. Seems like TheTransitClock is now completely unmaintained. The first departure is this The service operates on So in theory, I tried to clarify how these cases are supposed to be handled here and tried to follow the interpretation of @derhuerst that it's treated like a foreign key that has to 100% match:
In the end this is just one of many gaps in the GTFS-RT standard where the specification is vague and should be improved to be more precise. I fixed the |
|
Release v0.12.1 should fix the problems. Problems were:
Since this changes the matching logic, it makes sense to also check matching statistics on other feeds. We have a test suite with all kinds of special cases and it's working for all of them. But still @everybody: please check with your feeds and report bugs if this introduced any. |
|
I'm test running a server for a day and I'll let you know if that fixes it. Currently it's been two hours with 100% entity success, but I'll let you know if there's an issue with the 00 vs 24 boundary, thanks for this. |
|
Sounds good. Thanks for testing! 100% looks like the issue is solved now :) |
|
Sorry to reopen the ticket, but I am receiving failed responses still only during the end of the night. Here is my configuration (might be a bit different from last time but still basically the same). EDIT: The version I'm using: The motis response: When using the following script: url = 'http://realtime.ripta.com:81/api/vehiclepositions?format=gtfs.proto'
from google.transit import gtfs_realtime_pb2
import requests
feed = gtfs_realtime_pb2.FeedMessage()
response = requests.get(url)
feed.ParseFromString(response.content)
open('dump.json','w').write(str(feed.entity))I receive the following GTFS data: test.log at around the same time. When mapping them, the following trips seem to fail: For trip id 3795513, the bus is done for the night (route 20) and the current_status is STOPPED, (at the Kennedy Plaza in Rhode Island), but the route 11 (actually the R-line) seems to keep on going for another hour and is currently moving, though motis is failing to align it. The bus starts at 22:38 and ends at 23:17, so I'm unsure what's happening here. It's really not a worry and you can push this back if you need be. I only use this for commuting to/from work since motis is better than google maps for my specific need. So motis having resolving issues near the midnight boundary doesn't affect me, but hopefully I can help give more test data. Thanks! |
|
I added your first failing trip to the test suite in this commit and the problem cannot be reproduced. The previous ones from your first post were reproducible with test cases. So my guess is that your GTFS-static and GTFS-RT might not be in-sync? What's the update cycle of the GTFS-static data? If a new GTFS-static dataset is released during the night but MOTIS uses still the old one, it's to be expected that some trips can't be matched. Regarding vehicle positions: MOTIS currently does not parse them. What you see on the map is a linear interpolation between stop positions. |
|
GTFS-static gets updated once every few months, so I don't believe that's an issue there. Here's an email I sent RIPTA when I was importing the data into OpenStreetMaps:
In case this is helpful, I set up an instance of motis on https://sjwhitak.net and I am dumping the logs into https://sjwhitak.net/log.txt . Just please don't pan around too much in this instance since it will dirty the logs with a bunch of "tile not found" errors. I only have the Rhode Island map downloaded and I'm saving the logs to a file. I should receive ~100% accuracy throughout the day and then once it gets around 10-11pm EST, it starts to falter. -- One thing that may be an issue is that there are multiple paths in a single route. For instance, bus route 60 has 3 configurations: via west main, via east main, and via west main w/ NUWC stop. But I don't see this issue during the day, only at night. Either way, maybe you can see something I can't once the logs starts to get show something. |
|
I guess there are also problems on the producer side. At least the latest problem that |
Hello, thank you for making this project!
I'm currently trying to set up a live bus position for Rhode Island and nothing else. I followed the installation and configuration setup you set up which is very nice. My configuration,
config.iniis minimal:The
osmandcoastlinedata is from: http://download.geofabrik.de/north-america/us/rhode-island.htmlI commented out
dataset.no_schedule=truebecause no matter what, I get:But if I comment it out, motis runs just fine. I don't know what's going on there but if it works, it works.
When I run motis, I get the map displaying and the buses work just fine! But I currently only have display for only 4-5 buses using the RIPTA GTFS feed. When I directly pull from the real-time feed, I see a few more buses. I believe this is an issue with RIPTA's possibly poor following with their GTFS data and maybe motis is expecting a different format (some of their GTFS bus stop positions are 15+ meters off or completely missing! I need to talk to RIDOT again). I get the following errors:
Now, this issue is being posted way past midnight now, but during the day I was getting 40% or 20% success rate with much more buses failing to resolve.
I guess it's not the end of the world if this can't be fixed, and if it won't, I'd like to be able to figure out the root cause of this so I can intercept the GTFS-RT data and modify it to format properly for motis for these broken buses. Thanks!
The text was updated successfully, but these errors were encountered: