You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like #50, there is another (optional) distance value in GTFS. And to no surprise, RTD's gtfs is not populating those values. So as part of the post-process, we should also populate stop_time's shape_dist_traveled
Ideas:
I guess we could do the 'as-the-crow-flies for stop-to-stop pairs too. That would be easier, and maybe a good first pass (and just good enough in general).
a second idea would be to refer to the shape points to determine the stop_time distance (thinking this might be more accurate and more logically
with this idea, we'd populate shapes first, then stop_time next, since stop_time will rely on those initial values (so this would be executed within shape's post process)
the idea is to spatially match stop X to an entry in shape which matches both the trip's shape_id and also the nearest query. Thus we'd get our distance value. The problem here would be where a trip / shape visits a stop multiple times in the trip...would then be doing some gymnastics on which distance value to use--could be both slow and complicated.
The text was updated successfully, but these errors were encountered:
Like #50, there is another (optional) distance value in GTFS. And to no surprise, RTD's gtfs is not populating those values. So as part of the post-process, we should also populate stop_time's shape_dist_traveled
Ideas:
The text was updated successfully, but these errors were encountered: