Open scrudden opened 5 years ago
vsperez
commented
5 years ago Sean, I think that I might take a look at this bug. What solution are you thinking about:
I think the first one shoud not be difficult except for the first or last stop.
vsperez
commented
5 years ago Sean, I am taking a look at that part of the code. I have a question, does the issue occurres because the stopId of a route does not have its time in the stop_times? Or it is just because the stop_times.txt has null values in arrival time or departure time? As far as I can see it is the first case. Regards
scrudden
commented
5 years ago Hi Vicente,
I came across the issue when using this GTFS file.
http://www.golynx.com/lynxmap/GoLYNX_data/google_transit.zip
Cheers, Sean.
vsperez
commented
5 years ago Thanks
El sáb., 11 de may. de 2019 14:23, Sean Óg Crudden notifications@github.com escribió:
Hi Vicente,
I came across the issue when using this GTFS file.
http://www.golynx.com/lynxmap/GoLYNX_data/google_transit.zip
Cheers, Sean.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TheTransitClock/transitime/issues/135#issuecomment-491529475, or mute the thread https://github.com/notifications/unsubscribe-auth/AJUAAGEW6ESKZ3SXMTRZOG3PU36IXANCNFSM4HD5XYTQ .
vsperez
commented
5 years ago Hi
Today I commited to tc_issue_135. It is working, but I believe it might be more efficient. One related issue I found is how to treat the field stoptime in GtfsStopTime. I believe it is not giving the right value when null.
nselikoff
commented
5 years ago @vsperez I'm working with this same GTFS data. I checked out your tc_issue_135 branch to try it out. I'm seeing the following new types errors when importing the data:
ERROR - TripPattern null for trip [trip_id] when interpolating. This shoud not be ERROR - Schedule based travel time is invalid... ERROR - Found invalid travel time match for tripId=...
Also, I'm not sure if always interpolating arrival/departure times is the best move here - I think we should start by fixing the broken API calls, and also make interpolation optional. What do you think? /cc @scrudden
scrudden
commented
5 years ago Perhaps it might be an option to hand;e this outside of TheTransitClock with a custom onebusaway gtfs transformer which could use this as a starting point.
nselikoff
commented
5 years ago Yes, I'm looking at that option as well. There's also an ArcGIS plugin: https://github.com/Esri/public-transit-tools/tree/master/interpolate-blank-stop-times
vsperez
commented
5 years ago The API is broken because of null stop times, so we could change the api reponse on those cases, but it might be very little information for the interfaces.
Of course, fixing the data before loading it is a very good choice.
The errors when importing migth be because of I had to generate twice that information (Gtfs_stop_times). That is because of how the data is processed, but I need to check how to improve it. I agree, we could make that interpolation optional.
vsperez
commented
5 years ago By the way, What do you think about the field stoptime in GtfsStopTime?. Is correct the current implementation?
nselikoff
commented
5 years ago I haven't looked closely at all the code yet, but I think what you're doing with isTimepointStop and timepointStop is correct.
It only arrival_time and departure time are set for timepoints then this causes an issue for TheTransitClock. This breaks some of API calls and specifically those that require block information.
The best example is on the block assignment screen. The "load all" button calls 127.0.0.1:8084/api/v1/key/f78a2e9a/agency/1/command/activeBlockByRouteNameWithVehicles and this fails with a 400 error saying the syntax of the request is incorrect.
The problem is on the server side of the IPC call and is caused the dbTrip.getScheduleTime(i) call returning null for stops_times.txt trip entries that have no arrival_time or departure_time set.