google / transit Goto Github PK

The current specification does not offer a straightforward way for feed producers to provide, and feed consumers to monitor the lifecycle of an alert based on information provided in the alerts feed. For example, there is no field related to when an alert was created, last modified, or closed. This means that consumers must monitor every incremental file to infer these values, which may cause errors. This can be especially important for alerts that are continuously modified by the producer to provide timely information related to the developing impacts of an unscheduled service disruption.

To solve this issue we propose that three fields are added called “created_timestamp”, “last_modified_timestamp”, and “closed_timestamp.” All three fields would be optional and comprised of uint64 data type containing POSIX time. The created_timestamp field would include the date and time for when the alert was first generated. The last_modified_timestamp field would be populated with the date and time when the alert is updated. The closed_timestamp field would include the date and time when the alert is closed.

Producers will need to keep alerts that have been closed in their feed for a certain amount of time so that consumers can use the closed_timestamp field in their applications. Currently, feed consumers infer when an alert is active using the active_period start and end time fields. However, both of these fields are conditionally required. If the end time is not provided, consumers can use the closed_timestamp to know when the alert is closed. If the end time is provided, consumers should infer that an alert is no longer active when the closed_timestamp field is found in the feed because a feed producer may close an alert before the active period end time (for example, traffic delays subside earlier than expected). In this case, producers should remove the active time period from the feed.

Incorporating these three fields in the specification will improve consumer and transit customer confidence in the producer’s alert information, and help producers ensure they are publishing up-to-date alerts within their feed.

1. gtfs-realtime.proto in Spanish and probably README.md should include disclaimer that the Spanish version is for information only, and English version takes precedence in case of differences.
2. ScheduleRelationship::REPLACEMENT should be deleted from Spanish version of gtfs-realtime.proto
3. EntitySelector fields should get some descriptions in reference.md.

In transportation apps, riders search for O to D trips, check the different options, and choose among them the one they want to take.

But once their decision is made, a ticket has to be bought to make the ride. A growing number of public transit agencies already have ticketing apps allowing the rider to pay for such a ticket, but currently, links between transportation apps and ticketing apps have to be ad-hoc.

The goal of this proposal is to standardize the deep links between transportation apps and ticketing apps or websites, allowing the rider to have the following smooth experience:
• Search for O to D in transportation app.
• Choose the option they want in the transportation app.
• Be redirected in the ticketing app to buy the ticket, without having to re-enter the information about the OD nor the choice they made.
• Buy the ticket (or book).

=> bit.ly/gtfs-ticketing

(Note: it used to be called GTFS-DeepLinks)

Hi everyone,

I've been working with GTFS recently and I've realized that the Spanish translation of the GTFS-realtime spec might need a revision.
If nobody else is currently working on it, as a native Spanish speaker I wouldn't mind doing it myself in the following days/weeks; but I've been advised to ask here first just in case somebody's already on it.
I'm looking forward to reading your opinions,

Eduardo

The intended meaning of an empty stop_times.timepoint value may be unclear. Quoted below from trips.txt. See, in particular, statements that are somewhat at odds with each other in bold italic below.

Field Name	Required	Details
timepoint	Optional	The timepoint field can be used to indicate if the specified arrival and departure times for a stop are strictly adhered to by the transit vehicle or if they are instead approximate and/or interpolated times. The field allows a GTFS producer to provide interpolated stop times that potentially incorporate local knowledge, but still indicate if the times are approximate. For stop-time entries with specified arrival and departure times, valid values for this field are:
		* empty - Times are considered exact.
		* 0 - Times are considered approximate.
		* 1 - Times are considered exact.
		For stop-time entries without specified arrival and departure times, feed consumers must interpolate arrival and departure times. Feed producers may optionally indicate that such an entry is not a timepoint (value=0) but it is an error to mark a entry as a timepoint (value=1) without specifying arrival and departure times.

If there are no times provided and stop_times.timepoint is empty, then should feed consumers therefore assume that times should be interpolated? Is there any way of indicating times should not be interpolated, and would that ever be necessary?

location_type=1 is currently defined as:
Station. A physical structure or area that contains one or more platform.

Given that for anything like an entrance or generic node for an on street bus stop a parent_station would be required. I could argue that the wording of location_type=1 should be more generic. I would suggestion something like:

Group. A logical entity that contains multiple stops, entrances/exits, boarding areas or generic nodes.

Lets have a discussion with Noun should be used.

Hi GTFS community!

Most of you already know it, but we are working on a set of GTFS extensions allowing to make trips for people in wheelchairs, taking in account elevator downtimes, entrance closures, full buses and more. By describing stations and vehicles, we also get some often-requested data, like occupancy, AC...

After a few months of work, we have two complementary sets of extension. The logic behind slicing the extensions is to allow each agency to use only the portion which is useful for it. E.g. if an agency just want to say which buses have AC or how full are the buses, they won't have to even read the extensions about giving train composition or boarding areas in train stations.

GTFS-Pathways extensions (bit.ly/gtfs-pathways)

• GTFS-Stations (already added to the specification) defines stations & entrances (It contains the concepts of “station” and “entrance” defined using the fields location_type and parent_station in the stops.txt file. For more information, see the official specification).
• GTFS-Pathways & GTFS-Levels describes the inside of the station schematically (i.e. as a graph), between its entrances/exits and its platforms, to route riders using trip planning software (e.g. routing somebody in wheelchair with a step-free journey from entrance to platform, or somebody with a stroller with journey with as step as possible).
• GTFS-PathwayClosures describes the evolution of the station thru time (e.g. which pathway is being closed at which time for construction, or what are the opening schedule of an entrance linked to a mall).
• GTFS-PathwayUpdates describes the real-time evolution of the station (e.g. an elevator is down, if entrances are closed because of a demonstration or event).

GTFS-Vehicles extensions (bit.ly/gtfs-vehicles)

• GTFS-Vehicles describes the vehicles themselves (e.g. Does the vehicle have A/C? Is there a ramp for riders in wheelchair? Is the bus full?). This extension is the core of the proposal and is required for every other extension.
• GTFS-VehicleCouplings describes the coupling of vehicles into composed vehicles like trains (e.g. Which carriage is the restaurant carriage? Which one is First Class? In which one can I go with a wheelchair?).
• GTFS-VehicleBoardings describes where the vehicle stops on a platform (e.g. Where should I wait on the platform? Combined with VehicleCouplings, this tells where will stop my carriage, or in which carriage I should to alight in front of the exit).
• GTFS-VehicleDoors describes the properties of each door of a vehicle (e.g. Can we board or alight at this door? Is this door wheelchair accessible?).

I'm planning to keep on working on Google Docs for now instead of opening a Pull Request, because I think that the interface is more user friendly. Therefore you can provide feedbacks on the Google Doc directly.

Thoughts?

Excerpt from current definition of routes.route_color (https://github.com/google/transit/blob/46f9ddc08a4f0872b8fe2350efc1de7585b9d275/gtfs/spec/en/reference.md#routestxt):

If no color is specified, the default route color is white (FFFFFF).

This seems like an unnecessary prescription for consuming applications. I suggest that we consider a change proposal to remove this.

It has been discussed several times in the mailing list [1][2] that the limitation on single feed entity type per feed is artificial and can be removed.

I propose to reflect this in the GTFS RT Specification: #7

[1] https://groups.google.com/d/msg/gtfs-realtime/_HtNTGp5LxM/VvDLkV4wTnAJ
[2] https://groups.google.com/forum/#!topic/gtfs-realtime/VCKRVEWZbUE

Many feed producers including transit agencies deploy Interactive Voice Response (IVR) systems with Text-to-Speech (TTS) technology that allows their customers to dial a number and receive information including service alerts in audio format. This is particularly useful for transit customers who do not have access to smartphones or computers, or who do not have the ability to read text (due to visual impairments or illiteracy).

The current specification for Service Alerts provides useful options for disseminating and summarizing alert information in text format via the header_text and description_text fields, and allows producers and consumers of the feed to disseminate this information in specific languages by incorporating the TranslatedString data type. However, this is not compatible with IVR/TTS systems because there is no field to disseminate text that is properly formatted for input into a TTS generator. For example, a feed producer may want to publish text with phonetic spelling if the TTS generator would otherwise mispronounce the word, or a feed producer may want to add spaces between numbers if the intent is for the TTS generator to pronounce each number (for example, “one two three” instead of “one hundred twenty three”).

To solve this issue we propose that a field is added called “tts_ivr” that contains a text description of the alert formatted for input into a TTS generator. The tts_ivr field would be optional and comprised of TranslatedString data type.

Incorporating the tts_ivr field in the specification will enable producers and consumers to better support IVR/TTS systems.

This concept can be extended beyond IVR, and can be useful for accessibility in public address systems, virtual assistants and other applications. For example, a parallel field providing TTS text could be added so that consumers can disseminate alert information via public address systems located at transit stops and stations. Such a field could be titled “tts_pa.” Other examples are TTS-compatible fields for the header_text and description_text fields (i.e. tts_header_text, tts_description_text).

We have a system that doesn't provide accurate GPS co-ordinates of the train, but a requirement to show at a station B between A and C that the train coming in platform X isn't actually going to stop at the platform but pass through. Is there some means by which this can be sent as a realtime update? One option we were thinking of is if VehicleStopStatus could have an additional parameter PASSING_THROUGH to indicate the train is in between station A and B but only going to stop next at C. Once it crosses B then VehicleStopStatus becomes IN_TRANSIT_TO station C. Or it there an existing way to do this?

I have been trying to find the best way to add connections via footpath that are only available at certain times of the day.

My use case is that there are some footpaths around London that are quicker at certain times of the day because a station or footpath is open.

My understanding is that footpaths should be added as transfers but it doesn't contain fields to add this information. I looked at using the frequencies but they need a route and there is no route type for Walking.

What is the best practice in this scenario?

Hi GTFS Community,

A decision has to be made regarding service changes, and the feedback of everybody is heavily needed.

Currently, many things cannot be done in real-time, including:

• Case A: Updating time of scheduled arrival/departure
• Case B: Updating trip_headsign, trip_short_name, wheelchair_accessible or bikes_allowed
• Case C: Adding a new stop, a new shape, a new route or a new transfer.
• Case D: Have unactivated trips in the GTFS, that we trigger when needed.

What we currently have on the table are:

• Existing GTFS-TripUpdates (allowing to provide real-time update for arrival & departure).
• A proposal to extend GTFS-TripUpdates (#111 , including UPDATE_SCHEDULE) by @TransitApp, handling case A.
• A proposal to define a new feed, called GTFS-ServiceChanges, using the CSV GTFS structure, handling cases A, B, C & D (bit.ly/gtfs-service-changes).

So what do we do?

Option 0: Use only the existing formats. Update static GTFS more often.

Will require overhaul of GTFS consumer GTFS pipeline to be able to process GTFS every hour or more.

Option 1: We beef up GTFS-TripUpdates to support the cases A, B, C & D (Cc @Stefan)

We already have a proposal for case A (#111 ), we could easily extend the TripUpdate object to handle case B, but no proposal so far to handle case C.

Advantages:

• Small change to existing pipeline for case A & B.

Disadvantages:

• Handling cases C & D forces us to redefine almost every GTFS concepts slightly differently, therefore duplicating the spec.

Option 2: We keep GTFS-TripUpdates for real-time update only, and use GTFS-ServiceChanges to change schedule data (aka cases A, B, C & D)

This is what I had in mind when I drafted GTFS-ServiceChanges, and this is the current state of the GTFS-ServiceChanges proposal.

Advantage:

• It makes a clear distinction between schedule updates and real-time updates
• It keep TripUpdate implementation as they are
• As branding, it pushes agency to adopt this new feed as a new feature for their rider
• It doesn’t increase the size of the TripUpdates feed (but it may be not an issue @Stefan @gcamp)

Disadvantage

• Some overlapping for adding feed with GTFS-TripUpdates
• It’s a distinct feed, and force to open a new endpoint, with a new URL

Option 3: Middle ground proposed by Transit (Cc @gcamp & @juanborre)

• Extend GTFS-TripUpdate for case A
• Use GTFS-ServiceChanges for cases C & D.

=> What about case B (trip headsigns, short names…)? Should we extend TripUpdate also for this or not?

(Link to the GTFS-ServiceChanges proposal: bit.ly/gtfs-service-changes)

drop_off_time should be drop_off_type in the header row of stop_times.txt:

https://github.com/google/transit/blob/master/gtfs/spec/en/examples/sample-feed-1/stop_times.txt#L1

Currently, GTFS supports bike_allowed as attribute for trips.

However, very often, bike allowance is either time-dependent (e.g. disallowed on workdays between 6am and 8:30am) or stop-dependent (e.g. boarding only allowed at first stop, unboarding only at the last).

I'd like to suggest to extend StopTimes.txt by two new attributes "bikePickupType" and "bikeDropoffType", with the following values:

For bikePickupType:

NO_BIKES_PICKUP_INFORMATION = 0
BIKES_PICKUP_ALLOWED = 1
NO_BIKES_PICKUP = 2 

For bikeDropoffType:

NO_BIKES_DROPOFF_INFORMATION = 0
BIKES_DROPOFF_POSSIBLE = 1
NO_BIKES_DROPOFF = 2
BIKES_DROPOFF_MANDATORY = 3

If this is a need felt by others as well, I'd prepare a PR to discuss this further. If there are already ongoing efforts I'm not aware of, please let me know.

From @abyrd in #176 (comment):

I would prefer a blanket statement that feeds are not ordered, higher up in the document hierarchy outside any particular topic like blocks of trips. Or if people find it confusing to say that the data structure is unordered (if they see files and streams as inherently ordered), then just a statement that the order does not have any meaning.

And my response:

I agree that it would be useful to state somewhere at the top that entities aren't assumed to be ordered unless otherwise stated. However, I do think it's useful to call this out specifically for trip updates. The reason for the question here is that stop_time_updates ARE required to be ordered within a trip_update. Because trips have an order in a block in GTFS, it's reasonable to ask if the ordering of stop_time_updates in GTFS-realtime extends beyond the trip_update to the entire block (i.e., multiple trip_updates).

Given the vote for this passed, I'll go ahead and merge and then work on another proposal for this.

This sentence appears twice in the specification in the stop_times.txt section.
Isn't it supposed to be 8 characters? Or 6 digits?
As far as I know the colon is not a digit.

The original site, https://developers.google.com/transit/gtfs/reference, does not contain a reference to this new location.

Most agencies referring to the Spec refer to the original site.

Google Transit seems to have received a private extension to have an agency_id added in fare_attributes.txt, in similar fashion how a conditionally required agency_id exists in routes.txt. I assume this is done in order to allow multiple agencies sharing the same route_id. But that does not make sense since trip_id does not have an agency_id either.

A fare attribute was found in the fare_attributes.txt file without an agency_id value. In a feed with multiple agencies defined in the agency.txt file, each fare attribute must specify an agency_id value to indicate which agency the fare applies to.

Discussion on #139 made me think about a case we were unsure how to handle.

When a SCHEDULED stop time update has a StopTimeEvent with only a time value and no delay, should propagation happens on later stops?

We have seen agencies (YRT if I remember correctly) assume propagation would be done, but that requires the consumer to check the schedule time for that trip, find the delay and then propagate that delay, which might be very involved for some clients. That's the current behaviour in Transit.

@barbeau would be interested in your feedback, also curious what Google is doing.

As explained in the issue #138 on Jan 29th 2019, we drafted a GTFS-Translations proposal (bit.ly/gtfs-translations), which is based on Google's old private GTFS translation extension.

Since then, and after a few modification of the proposal (see the Google doc), Google has shifted to use it internally, deprecating their old private GTFS translation extension, as described in their documentation (here).

But there is currently no publicly available dataset using this extension, which prevents the opening of a vote for its adoption.

=> Does any of you know any GTFS producer which would be interested to have a translated dataset? Maybe in multilingual country (e.g. Belgium, Luxembourg, Switzerland). Thanks!

I see recently there's more movement in scripts part of this repository (which was empty before AFAIK), I'm trying to understand why it should be part of the same repository as specs.

Scripts seems to have a different review process than spec changes (is that specified somewhere?). Is that different for Google employee and non-Google employee? It should probably be specified in https://github.com/google/transit/blob/master/gtfs/CHANGES.md

It makes following this repo harder on Github, because now not all PRs and issues are relevant to specs (which I think most people following this repo are interested in).

If this is also a place where scripts should go, what is https://github.com/google/transitfeed role? It also includes scripts in addition to the library itself.

Ping @aababilov

The implementation of pathways goes into a discussion that will lead to a very complex standard and would certainly mean that operators require a separate topology editor to enhance their feeds. Many operators do have entrances and exits available but they are currently limited by the dogma that entrances would only apply for station like structures.

Outdoor stations with stairs and escalators have no single entrance or exit to reach both tracks but instead have an entrance that would go directly to the track. If the station is bundled via a parent_station the two entrances would suggest both tracks can be directly accessed via any entrance, which is not the case. This proposal would allow an entrance directly to be coupled to a track, without going via a physical station structure, and can be modelled in implementations that are not aware of pathways.

Systems that are not compatible to add entrances to stops should warn that the optional data can't be processed. Given the low number of systems that produce entrances and therefore consume I would like to explicitly ask for any system that would fail on this change.

Hi GTFS community,

As far as I know, the only publicly-available GTFS extension describing translations is the Google one:

https://developers.google.com/transit/gtfs/reference/gtfs-extensions#traductions

Is any of you aware of other internal or external extensions, used to defined translations and/or localizations?

Thanks!

In #105 we just updated the GTFS-rt change process docs to match the currently followed process as outlined by Brian Ferris in https://groups.google.com/forum/#!msg/gtfs-realtime/bWQAgGdj3f0/mdcKwR3J8xAJ.

@gcamp suggested two changes to the process, which we agreed to table until after the above PR was adopted - so now we can discuss in this issue.

First comment thread is at #105 (comment), although for some reason @gcamps comment doesn't appear there anymore (?). It was a suggestion to put a limited time window on experimental fields, and after than window expires they would be adopted (or potentially discarded). For example, OccupancyStatus has been experimental since 2015.

Second comment at #105 (review):

Should there be a definition of consensus? The amendment process is way more formal but it seems to me that if an experimental fields is approved, it becomes hard to change after the fact due to protobuf backward compatibility issues. My proposition would be same process as the spec amendment process but with a "strong majority vote (80%)" instead of unanimous.

@gcamp any further thoughts or proposals on the above?

GTFS-rt spec current says the following about differential messages:

currently, this mode is unsupported and behavior is unspecified for feeds that use this mode. There are discussions on the GTFS Realtime mailing list around fully specifying the behavior of DIFFERENTIAL mode and the documentation will be updated when those discussions are finalized.

Based on a discussion starting in opentripplanner/OpenTripPlanner#2516 (comment), differential feeds are being used in practice.

I've opened this issue to start to document behavior for deployed feeds using differential messages, with the goal of working towards a proposal/pull request to better define differential producer/consumer behavior in the GTFS-realtime spec.

In opentripplanner/OpenTripPlanner#2516 (comment), @abyrd says:

To summarize, our differential GTFS-RT uses trip-level granularity, and the effects of successive messages about the same trip do not accumulate.

An update about a trip is always cleanly applied to the base trip from the original static feed, with no consideration for any previously received message. The differential effect comes from accumulating changes to different trips across the whole data set.

If anyone else is producing/consuming differential messages, please add comments here for any design documentation for expected consumer/producer behavior.

[Apologies for posting this here; I know this is the spec repo and not Google's webmaster. However, I could not find any way to get feedback to Google. I tried to post to the transitfeed, gtfs-changes, and transit-developers mailing lists; they were all either completely hidden or bounced my message as an outsider.]

I've been working on some GTFS tools, and I noticed a confusing mistake in the GTFS reference on developers.google.com (parent_station is not defined for boarding areas, though from the example feeds it was clearly intended to be used for boarding areas). I tracked down how to submit changes to the spec on this repo, only to find that the spec here has already been updated to correctly define parent_station for boarding areas.

Reference spec on developers.google.com: https://developers.google.com/transit/gtfs/reference/
Reference spec here on GitHub: https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md

Does anyone know who updates developers.google.com, and if we can ask them to do so with the newest version of the spec from this repo? I spent the better part of an hour puzzling over the inconsistency, and I don't want others to go through the same thing.

Thanks so much for all the great work you do!

The "pathways and locations" pull request #143 introduced several new location_types for stops, generalizing stops into nodes for use in routable graphs of stations.

When talking to @t2gran today about the internal domain model of a GTFS consumer application (OTP) we realized neither of us really understood some new location_types, even after reading the spec. So I believe some definitions and explanations should be revised, especially if they are to be understood by first-time readers.

Specifically, location_type 4 "boarding area" and location_type 0 "stop" have very similar descriptions, and one can only guess at their different roles if one knows to read the descriptions of parent_station field and pathways.txt. Even then it is not entirely clear that location_type 0 is a "true" stop referenced in schedules, while 4 is a micro-mapping modeling node akin to type 3.

The location_type section should clearly state if only location_type 0 may be referenced by stop_times, and whether all the other location_types instead serve to model movement within stations and logical groupings of platforms into stations, and often only make sense in the presence of a pathways table. It must be apparent to the first time reader that only stops (location_type 0) are truly necessary and universally used, and that the rest of the types are set apart as conceptual generalizations of "stop" to "node" or "point".

Additionally, the section on parent_station implies that location_type 4 boarding areas are hierarchically under platforms (i.e. under stops, location_type 0) at the lowest level in a hierarchy. Further explanation is needed. It's not clear (at least on first reading, without piecing together disparate parts of the spec) how a GTFS consumer system would ever determine which boarding area a rider would need to pass through, because the transition into the public transit network happens at the location_type 0 level. Any movement via pathways to a location_type 4 is a movement to a leaf node, and therefore cannot be located along any path through the network.

I see some text in the platforms.txt section stating: "A platform that has boarding areas is treated as a parent object, not a point. It may not have pathways assigned. All pathways should be for boarding areas." This provides some hints about how pathways are connected, but it's still not explicitly stated how this relates to stop_times. The expressions "parent object" and "not a point" are not well-defined and it's difficult to know what they imply or require. My understanding is that by following pathways we can reach boarding areas only (never platforms), and that the routing system must then make the transition up the hierarchy from boarding location to platform when relating to schedule data from stop_times. This seems somewhat awkward to me, but I see how it could work. If this is the intended meaning and behavior, it should be explained more fully, and information included in all fields related to this structure.

Finally, based on recent discussions I think it would be best to avoid the aliasing of platform_type 0 "stop" as "platform". The spec should say that stops are effectively platforms when they are within a station (as a helpful mental image), but we should not introduce both of these as standard terms in the data model vocabulary - this rapidly leads to confusion by implying that they are distinct types that might have different type codes.

Hi GTFS community!

Some data producers told us they'd like to provide attribution of the data, and that the existing fields feed_publisher_url and agency_name weren't enough, because other stakeholders were implied... and were asking to be given credit.

Given the broad variety of such stakeholders (French "Autorité Organisatrice", German "Verbund", the SF Bay Area MTC which is "planning, financing and coordinating", aggregators like Danish Rejseplannen...), we ended up drafting a proposal allowing any kind of attribution (aka free text).

The draft is here: GTFS-Attributions bit.ly/gtfs-attributions

Since this question was closely knitted with the question of translation in GTFS, we also drafted a proposal for translations in GTFS. It is inspired of the Google's one, but stricter and improved.

The draft is there: GTFS-Translations bit.ly/gtfs-translations

As usual, I'm posting it as Issues to gather your impressions, and if we get closer to a consensus I'll move it as proposal.

Thanks!
Leo

I was curious if there was a language agnostic programmatic definition, similar to the proto definition for GTFS-Realtime, but for GTFS-Static, that can be used with an ORM for creating Class representation of the text files. This would simplify the coding process, and would eliminate the need to write code to represent each text file and possibly needing to update that code if/when the spec changes.

Summary:

Currently, the GTFS-realtime extension process:
https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md#extensions

...doesn't cover protocol buffer best practices.

Under the Protocol Buffers Language Guide:
https://developers.google.com/protocol-buffers/docs/proto

...in the "Assigning Field Numbers" section it says:

Each field in the message definition has a unique number. These numbers are used to identify your fields in the message binary format, and should not be changed once your message type is in use.

We should add this text to the GTFS-realtime extensions section to make sure that producers don't break their custom extensions (even if the field is just defined for a proposal) when they are in use.

For example, if Agency X uses field number 1 for an extension for a GTFS-rt proposal, then it can never use 1 again in the future for another field, even if the proposal was accepted and the field 1 is no longer in use.

We should also add a link to the "Assigning Field Numbers" section in the GTFS-realtime extensions section too:
https://developers.google.com/protocol-buffers/docs/proto#assigning-field-numbers

...as there are other guidelines there for selecting field number values.

The current GTFS-realtime change process docs:
https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md

...say (under the "Extensions" section):

To facilitate the testing of new features and to allow developers to add extra information to a GTFS Realtime feed, we will take advantage of the Extensions feature of Protocol Buffers.

However, in Nov 2013, Google changed the GTFS-realtime change process to a less formal approach that doesn't require extensions prior to a new GTFS-realtime proposal being merged:
https://groups.google.com/forum/#!msg/gtfs-realtime/bWQAgGdj3f0/mdcKwR3J8xAJ

A brief summary of the new process - if there is a group consensus that a feature is broadly useful and we can nail down an exact data type, then a feature is labeled as "experimental" and it is assigned a field value in the main .proto file. For an example, see the OccupancyStatus field that is still experimental:
https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/reference.md#enum-occupancystatus

The OccupancyStatus description says:

Caution: this field is still experimental, and subject to change. It may be formally adopted in the future.

At some point after the field is considered useful and there are real consumers and producers using it, then it's no longer labeled as experimental (an aside - to my knowledge we haven't yet had a field exit experimental status under this approach). If not, we set aside the .proto field value (it can't be re-used) and remove the field from the spec.

We should update the CHANGES docs to reflect the current process of using experimental fields instead of extensions for new features in GTFS-realtime.

Note that extensions will still exist as a method for agencies to publish fields that aren't considered useful for broader adoption.

Adding as issue rather than PR for now in case there are other producers or consumers who have already solved this problem a different way, that should be discussed prior to PR.

From stops.stop_code details in spec

The stop_code field contains short text or a number that uniquely identifies the stop for passengers.

Problem:
How does this reflect on use for stations? A customer providing a real-time app or SMS system a stop_code for a station with X bus bays likely wants to be returned arrival/departures for multiple routes, or might not want to remember a different stop_code depending on what route they want info for.

Easy answer for system that is consuming data is to have the same stop_code for multiple stop_ids in the station. However, this seems to violate spec.

Proposed solution: Remove the word "uniquely" from the spec details, in order to make it clear that this is allowed.

Current Spec refers to "service date". Trips occur on a particular "service date". The service date begins on a particular calendar date, and may continue to the next calendar date. (i.e. if there is transit service past midnight, trips may begin at 25:00:00, etc.).

It appears that "service day" is a more accepted term in transit, and this feels more intuitive to me.

Examples of the use of the term "service day":

• Sacramento Regional Transit (glossary of terms):

Service Span — The span of hours over which service is operated, e.g., 6 a.m. to 10 p.m. or 24 hr (owl). Service span often varies by weekday, Saturday, or Sunday.

Synonyms: Span of Service, Service Day

• King County Metro (Regional Day Pass):

The pass covers unlimited rides for a "service day" starting at first use and expiring at 3 a.m. the next day. Each Regional Day Pass covers rides with a one-way adult fare up to $3.50 ($1.75 senior/disabled).

Current Issue

Current specification gives two distinct definitions for the two language fields:

• agency_lang allows only two-letter language codes, using ISO 639-1 (e.g. "en" for English, "es" for Spanish or "de" for German);
• feed_lang allows the two letter-language codes, but also more complex language tags, using BCP 47 (e.g. "en" for English, but also "en-US" for American English or "es-419" for Spanish used in Latin America).

This implies that the high-level definition of the language (with feed_lang) can be specific more specific than the low-level one (with agency_lang), which is the opposite of what could be expected.

This distinction:

• forces producers to be less specific in the agency_lang than in the feed_lang, or discourage them to be specific in the feed_lang,
• forces consumers to handle two different field formats for validation, without knowing how they should handle a feed_lang more specific than an agency_lang one (e.g. "en-US" as feed_lang but "en" as agency_lang).

Options

Option 1: Unify the two definitions by allowing both fields to use language tags.

• This will reduce the complexity of the specification without reducing it's precision.
• This keeps all old datasets valid, since the two-letter language codes is are included in BCP 47.
• This will only require producers to simplify their code, by allowing agency_lang to be like feed_lang.

Option 2: Deprecated the agency_lang field once-for-all.

• This was the original intention when the field feed_lang has been added (see Joe Hughes 2010 message on the subject)
• This would reduce even more the complexity of the specification.
• Both fields are optional so we wouldn't be loosing required information.
• BUT, this wouldn't allow anymore to specify distinct languages for distinct agencies in the dataset. It it used?
  • Official dataset for Switzerland (which has four official languages) arbitrarily set the feed_lang as "DE" and then lists all agencies agency_lang at "DE" aka speaking German (see GTFS).
  • Official dataset for trains in Belgium (which has three official languages) set arbitrary the feed_lang as "NL" and do not provide language for agencies, since there is only one agency, the NMBS/SNCB (see GTFS)
  • => Are you aware of cases where that feature is used?

(I personally leans sightly toward option 2, but I would also be fine with option 1, rather than keeping the current inconsistency)

Background

This difference exists for historical reason. The two fields have not been added at the same time.

• About option 1, extending the definition of the agency_lang field has already been proposed in 2009: https://groups.google.com/forum/#!topic/gtfs-changes/mZHnGsHLPyw
• About option 2, discussing the usefulness of agency_lang when we have a feed_lang has already been done twice:
  • in 2010 by Joe Hughes: https://groups.google.com/d/msg/gtfs-changes/muxms00iBos/TrCb9YYteCMJ
  • and 2011 by Brian Ferris: and https://groups.google.com/d/msg/gtfs-changes/Sh0e4o9o2Gw/z91_sSyHXFsJ

Currently, TripDescriptor.ScheduleRelationship has an enum value of UNSCHEDULED, which is defined as:

A trip that is running with no schedule associated to it - this value is used to identify trips defined in GTFS frequencies.txt with exact_times = 0. It should not be used to describe trips not defined in GTFS frequencies.txt, or trips in GTFS frequencies.txt with exact_times = 1.

However, it's not clear what cooresponding enum value should be used for exact_times=0 trips for StopTimeUpdate.ScheduleRelationship, as it doesn't have an UNSCHEDULED value.

As a result, you could potentially have a feed that looks like this, which is not clearly labeled as incorrect in the current spec:

entity {
  id: "1121"
  trip_update {
    trip {
      trip_id: "5"
      start_time: "19:29:28"
      start_date: "20180910"
      schedule_relationship: UNSCHEDULED
      route_id: "C"
    }
    stop_time_update {
      stop_sequence: 1
      arrival {
        time: 1536609516
      }
      stop_id: "421"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 2
      arrival {
        time: 1536609552
      }
      stop_id: "425"
      schedule_relationship: SCHEDULED
    }

Furthermore, because SCHEDULED is the default value if schedule_relationship is left empty, we need a separate enum value to represent exact_times=0 trips.

Therefore, I believe an UNSCHEDULED enum value should be added to StopTimeUpdate.ScheduleRelationship to fix this, with a definition of:

The vehicle is proceeding in accordance with the order of stops defined in GTFS stop_times.txt for a trip with frequencies.txt exact_times = 0 or empty. It should not be used to describe a stop on a trip not defined in GTFS frequencies.txt, or for a stop on a trip in GTFS frequencies.txt with exact_times = 1.

The current alerts specification does not allow feed producers (agencies) to categorize alerts based on their severity. The severity of an alert often determines the channels through which an alert should be published, how an alert is displayed to customers, and the order in which alerts should be displayed (based on severity). Often, agencies use a combination of the alert attributes (such as its effect, duration, etc.) to determine its dissemination channels and display order. The SeverityLevel field encompasses all these attributes into one. Without a field to categorize the severity of the alert, feed consumers must determine severity on the fly and in an ad-hoc manner, which adds latency and reduces consistency in the alerts dissemination process.

To solve this issue we propose that a field is added called “SeverityLevel.” The SeverityLevel field would be optional and comprised of enum values. As an example, the set of enum values may be something like one of the sets below. We are not proposing these exact enum values but instead are including them as a starting point to get feedback on what the enum values should be.

“UNKNOWN_SEVERITY”
“OTHER_SEVERITY”
“INFORMATIONAL”
“ADVISORY”
“WARNING”
“CRITICAL”

Or:

“UNKNOWN_SEVERITY”
“OTHER_SEVERITY”
“INFORMATIONAL”
“DELAYS_OF_UP_TO_TEN_MINUTES”
“DELAYS_OF_UP_TO_TWENTY_MINUTES”
“DELAYS_OF_UP_TO_THIRTY_MINUTES”

Or:

“UNKNOWN_SEVERITY”
“OTHER_SEVERITY”
“LEVEL_1_SEVERITY”
“LEVEL_2_SEVERITY”
“LEVEL_3_SEVERITY”
“LEVEL_4_SEVERITY”
...

By incorporating the SeverityLevel field in the specification, feed consumers can predetermine the extent to which an alert is published based on the value of severity, and build it into their alerts management process. For example, an alert of SeverityLevel = “INFORMATIONAL” may be configured so that it is published only to Email/SMS subscribers of the particular service that is impacted, while an alert of SeverityLevel = “CRITICAL” may be configured so that it is published to all available outlets and shown prominently on the agency’s website and by other applications. Ultimately, this change would allow transit customers to receive alerts on a more timely and consistent basis.

First mentioned in #31 (comment).

Right now the GTFS and GTFS-realtime change processes don't say you should announce opening/closing votes on the Google Group:

• https://github.com/google/transit/blob/master/gtfs/CHANGES.md
• https://github.com/google/transit/blob/master/gtfs-realtime/CHANGES.md

We should add a step saying the opening and closing of the vote itself should be announced on GTFS Changes mailing list, as it could be a long period of time between when a proposal is first opened to when it's voted on.

@RachM @ca9 Could Google provide clarification for the GTFS/GTFS-realtime specification license?

The bottom of https://developers.google.com/transit/gtfs/reference/ says:

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.

But the LICENSE.md file at the root of this repository says it's Apache v2.0.

Does the LICENSE.md file in this repo count as "otherwise noted", meaning that the GTFS license is under Apache v2.0?

Asked by @mmorang in this post on the transit-developers list:
https://groups.google.com/forum/#!topic/transit-developers/kuhRnxAUR6A

Hi GTFS community!

As you know, to open the vote on a proposal, we currently need:

• a proposal
• a producer, producing a GTFS which uses the proposal
• a consumer, consuming GTFSs which uses the proposal

Some stakeholders complain that they have to implement new feature before having the proposal being voted. I think we should still wait to have producer & consumer to add to the core spec, but maybe we could have another vote, a kind of "vote on proposal", which would show that the community agrees on the current version, and that stakeholder can start considering implementations.

What are your thoughts on that?

Replace two references to pathway_type in pathways.txt::max_slope by pathway_mode.

Not sure if you guys have control of the developer site, but here there seems to be a space after the first field name in the example for agency.txt:

agency_id, agency_name,agency_url,agency_timezone,agency_phone,agency_lang

Should be:
agency_id,agency_name,agency_url,agency_timezone,agency_phone,agency_lang

Some trains are only scheduled to leave from "Main Station", without platform scheduled in advance. The platform is assigned only at the last minute, when the boarding starts.

In GTFS, platforms have location_type=0 and stations have location_type=1. Schedules can only be provided on platforms currently.

=> How should schedules be provided when the platform is not assigned in advance?

(Please note that the proposal GTFS-ServiceChanges v3 (discussed in issue #113 and available at bit.ly/gtfs-service-changes-v3) offers already a way to update platform in real-time. So this part of the conversation should be discussed in #113. This current issue is meant to be about the scheduled representation of unassigned platform, expecting GTFS-TripUpdates to provide the correct information in real-time.)

Option 0: Schedule on any platform, then update in real-time with the right platform.

Pro: It's likely what most data producers already do.
Con: The information is non-accurate, since riders might go to a platform (and maybe even board on a train) which is not the good one.

Option 1: Add a "fake" platform, and assign trip on it as long as the platform is not assigned.

Pro: It works with the current spec.
Con: This is a hack, and as soon as an agency will use GTFS-Pathways, they will either (i) not link this platform with pathways, leading the trip planner to declare it unaccessible or (ii) link it to everywhere in the station, leading wrong trip planner result.

Option 2: Assign stop times on station, until the platform is assigned

Pro: It is how riders think about it. The train is scheduled from "Main Station", without more indication.
Con: Without being strictly speaking non-backward-compatible, it will still require some change on data consumers that expect stop times to always be on platform and not on station.

=> What do you think? Should I open a PR to allow scheduling on station? Should we think about a more complex representation (describing waiting areas in station? Halls?)

Ping Andrew (@abryd) who asked me to open this issue.

Thanks!

Hi everybody!

MobilityData received the request to improve the representation of the boarding & alighting restrictions in GTFS.

Issue

Some bus or train intercity agencies are allowed to sell tickets only for intercity trips, but not for intra-city trips. GTFS currently cannot represent such limitation.

Example of trip which cannot be described using pickup_type & drop_off_type:

• Washington DC: pick up allowed, drop off forbidden.
• New York City Downtown: pickup allowed, drop off allowed.
• New York City Uptown: pickup allowed, drop off allowed if has boarded in DC.
• Boston: pickup forbidden, drop off allowed.

Proposal

The proposal is to normalize an existing practice: the stop_time_limitations.txt extension defined by Bileto (@jspetrak). Here is the proposal: bit.ly/gtfs-boarding-restrictions.

Thoughts?

As supplement to the examples on https://github.com/google/transit/tree/master/gtfs/spec/en/examples, add links to http://bit.ly/gtfs-examples (or entire contents).

Hi GTFS community!

Who (among both GTFS producers and consumers) would be interested into having a "Lite" GTFS-TripUpdate format, which would allow to call for the ETA for only one stop and one stop route.

It would be calling something like http://example.com/tripupdate.pb?route_id=ri1&stop_id=si1, and would contain only the StopTimeUpdate applying for this stop and route?

Why?

• For GTFS Producers: Currently providing GTFS-TU is a huge (& expensive) change for agency. They can do it only when there is a big RFP going out, and they cannot just add a converter at the output of their existing tools, since GTFS-TU requires the state of the whole system. Allowing a Lite GTFS-TU as described above would strive the adoption of the GTFS language in the real-time world.
• For GTFS Consumers: It would allow them to parse fewer different formats, and to push agencies to provide a standard and open source format.
• For the open source community: this allows to make converters from other format to Lite GTFS-TU (those formats could be standards like SIRI, or proprietary formats outputted by real-time providers)

Downsides?

• On the short term it would be a win, since we would have more GTFS-TU.
• On the long term it would be a win, because it would increase the momentum around GTFS-TU.
• On the mid-term though, it might be a small loose, because some agency could postpone the adoption of full GTFS-TU because they have a middle ground.

Thoughts? Especially big real-time consumers (@anatolip-rt, @gcamp, @slai, @TeXitoi, @Tristramg).

Today when working with the SEPTA GTFS-Rt feed, I found that the TripDescriptor hasScheduleRelationship() was returning false even for times when there were SCHEDULED schedule relationships present. SEPTA does not have any other statuses in their feed besides SCHEDULED, so that is all I was able to test. I'm unsure if this issue is present for other statuses.

When providing directions to users, it's important to
determine whether or not a certain pathway is accessible to people who use
wheelchairs.

When the pathway mode is Stairs or Escalator, it's clear that the pathway
is not accessible, but it's not obvious for Fare Gate or Exit Gate -- Ordinary
turnstiles are not, but there might a separate gate that can be opened to
allow a wheelchair to pass.

Has anyone else encountered this issue or developed a workaround, or should we (Transit) propose some additions to the spec to handle this case?

I was just looking at the developers.google.com GTFS reference site and noticed that it still hasn't been updated to reflect changes made to the GTFS specification via the proposal/vote/accept process used in this repo. For example, the first change we made using that process, adding location_type 2 to define a station entrance, still has not been added there.

Google, please update your site and keep it in sync!

Is anyone currently using the GTFS-rt TripDescriptor.ScheduleRelationship = ADDED value?

It's defined here:
https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/reference.md#enum-schedulerelationship-1

...as:

An extra trip that was added in addition to a running schedule, for example, to replace a broken vehicle or to respond to sudden passenger load.

And text above that says:

If a trip is done in accordance with temporary schedule, not reflected in GTFS, then it shouldn't be marked as SCHEDULED, but marked as ADDED.

Also posted to Google Group at https://groups.google.com/forum/#!topic/gtfs-realtime/W6bm2Xj3p-Q.