Comments (4)
I think the uncertainty
is more about the accuracy of the prediction, which sounds like it is high in your case.
It appears that the scheduled times on non-timepoint stops have low certainty (or none at all). I would rather try to improve how to communicate this to passengers, perhaps by not publishing a time or making it otherwise more obvious that times on these stops can vary a bit.
from transit.
Is it common to have non-timepoint trip stops for transit agencies?
For us, it is not possible to designate every stop as a timepoint since not all stops are suitable for the operator to stop and catch up back on schedule. Timepoint locations are selected by Planners and Schedulers to be safe locations for the bus to be able to wait out of traffic. These are also selected by their proximity to major travel generators or near major streets and transfer locations. It is not industry best practice to designate every stop at a timepoint because this also makes the service more difficult for the road supervisors to manage.
Perhaps an uncertainty seconds field inside GTFS-Static stop_times.txt would be a better solution to this. The data would be beneficial to all data consumers.
from transit.
Arrival times at time points can be just as uncertain as at non time points particularly if the bus is running late. The bus can be held to match the scheduled departure time if its running hot. So, it depends on how the data in the GTFS static files is to be used. Since the GTFS static files are used for multiple purposes and not just to provide predicted times to riders, I would much rather the scheduled times for all stops be included in the GTFS static times and the time point boolean filled out to show which stops are timepoints. For non time points the scheduled time can be done as simply as interpolating based on distance travelled or distance traveled and average traffic speed on the road segments traversed, or to improve accuracy by using a more sophisticated method based on the AVL and trip traces to interpolate using the historical patterns of the time between stops by time of day, direction, or even trip.
Jim Bunch
from transit.
You are right in that uncertainty affects both timepoints and non-timepoints alike. Pauses at timepoints for early vehicles can realign schedule adherence while late vehicles have no means for realignment without speeding or off-route shortcuts. As we use the more sophisticated method as you mentioned for setting non-timepoint stop times, they are often limited by number of patterns and the manual creation of turn-by-turn directions (due to base map changes from scheduling to AVL systems).
Having thought about this more, you are right in that historical data can automatically generate the accuracy spread for [non]timepoints, although this takes an algorithm instead of a lookup table. One of the nice things about GTFS-Static is pre-calculating these types of data points so data consumers do not need to also do them. In fact, the arrival/departure times similarly can all be calculated using historical vehicle positioning analysis without need to put them into stop_times.txt, but that is compute inefficient.
My point is that having an accuracy range inside the stop_times.txt can help solve confusion in riders when the schedule is running as designed but the real-time information doesn't exist to explain the early/late-ness built into the system and making transfers less deterministic and thus frustrating.
from transit.
Related Issues (20)
- [DRT] After the adoption of GTFS-Flex, stops.txt should no longer be a required file. HOT 1
- Addition of vehicles.txt to GTFS static HOT 11
- Make Shapes a recommended file in GTFS HOT 11
- Make bikes_allowed a recommended field in GTFS HOT 12
- Global trip id HOT 17
- The recommended discussion HOT 1
- Proposed Best Practice: always including trip_id in TripDescriptor for SCHEDULED trips HOT 8
- Add cars_allowed field to trips.txt HOT 40
- Inconsistency in trip update example vs. reference documentation? HOT 1
- Proposed Best Practice: clarify intended use for CANCELED/SKIPPED TripUpdates VS NO_SERVICE Alerts. HOT 7
- Center coordinate or Bounding box definition in feed_info.txt HOT 6
- GTFS-R : destination display (dynamic)
- Best practice for the use of shapes HOT 6
- Sample Feed HOT 1
- Make headsigns a recommended GTFS field HOT 10
- Scheduled reinforcement trips HOT 18
- It is impossible to specify a different arrival_time and departure_time in a GTFS-RT trip modification object HOT 3
- Have a way to explicitly communicate that a trip does not have any headsigns HOT 2
- Allow specifying both the scheduled time and delay in StopTimeEvent for added and duplicated trips. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from transit.