Comments (6)
How is a producer supposed to cancel let's say a stop for a month? Or, cancel it for this weekend? In a way where route planner can effectively cancel those stops. Providing a trip update of all the trips with one stop time SKIPPED is definitely possible but it's not efficient at all.
It's a case where a producer will have very simple information "Stop X is closed for 3 months", and will create an alert with that exact information. Instead we're proposing that we expand that simple information to all the trips affected, then a consumer parse potentially hundreds of trip update to make sure that stop is cancelled for a laps of time.
Additionally, to me a SKIPPED stop on a trip update doesn't mean the stop is cancelled. It might be skipped for other operational reason (bus bunching, etc). And as an app I would want to display those two cases differently (one is a cancelled stop for a time period, the other is just a skipped stop for one or some trips).
Some might argue that we should parse those trip updates, then figure out that there's a pattern of skipped stops for a sufficient length of time (ex : 5 trips in a row skipped this stop, then we should mark it as cancelled). Even if we ignore the complexity making this process happen, creating the heuristics to figure out if it's one type of cancellation or an other doesn't seems like it's a productive work when the agency already has that information in hand.
Finally, I agree this behaviour should be clarified and formalized, but I don't think saying NO_SERVICE
alerts should not change planner/app behaviour without any replacement way of achieving this feature is the way to go.
from transit.
We should also consider what is the time span for cancelling things through realtime updates. If you want to close a stop for 3 months, maybe it makes sense to edit the scheduled data (GTFS) to not have the stop in the schedules for any route. Although, I can see how it can make sense to include the "skipped" stop in the schedules for longer periods of time to clearly communicate to the users that a stop is skipped.
This also touches the topic of planned cancellations. NETEX (as far as I'm aware) has possibility to include cancellations in the planned data, GTFS does not. Planned cancellations in the static data would be a good fit for these longer disruptions.
from transit.
One challenge with the proposed clarification is that producers need to support RT Trip Updates feeds.
Not all data producers have the technical capabilities to produce a Trip Updates feed (or produce it with an acceptable level of quality).
Therefore cancelling services with a service alert happens to be the only available option in their disposal.
Besides, data providers who want to display information to customers can choose other effect values, e.g. MODIFIED_SERVICE.
from transit.
cc @whitneys-pm
from transit.
It is a question between presentation and factual information. Factual information - there is no service at a stop / route / agency, etc. It is a decision for an app developer on how to deliver this information to their users and how to react to the factual information. Different apps have different capabilities and presentations, it is not a data provider decision here unless we want the spec to dictate presentation of transit information.
from transit.
@IvanVolosyuk While I agree with that sentiment, the point of the spec is to facilitate communication between producers and consumers. Since there are competing approaches to achieve a stop being excluded from routing, I think it would be proper to add some language to the spec that manages the reasonable expectations that producers might have.
from transit.
Related Issues (20)
- Make UTF-8 the mandatory GTFS encoding HOT 6
- GTFS Fares 2.0: Manage fare change HOT 2
- Moving Realtime Best Practices into the Spec: Phasing Plan
- [DRT] After the adoption of GTFS-Flex, stops.txt should no longer be a required file. HOT 1
- Using StopTimeEvent.uncertainty for non-timepoints HOT 4
- Addition of vehicles.txt to GTFS static HOT 6
- Make Shapes a recommended file in GTFS HOT 11
- Make bikes_allowed a recommended field in GTFS HOT 10
- Global trip id HOT 10
- The recommended discussion HOT 1
- Proposed Best Practice: always including trip_id in TripDescriptor for SCHEDULED trips HOT 6
- Add cars_allowed field to trips.txt HOT 8
- Inconsistency in trip update example vs. reference documentation? HOT 1
- 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 1
- Sample Feed HOT 1
- Make headsigns a recommended GTFS field HOT 10
- Scheduled reinforcement trips HOT 18
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.