The repository contains specification to manipulate General Transit Feed Specification (GTFS) and GTFS Realtime:
Please visit https://gtfs.org for information.
Home Page: https://gtfs.org/
License: Apache License 2.0
The repository contains specification to manipulate General Transit Feed Specification (GTFS) and GTFS Realtime:
Please visit https://gtfs.org for information.
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!
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
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.
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.
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:
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.
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.
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.
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.
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?
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.
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:
What we currently have on the table are:
So what do we do?
Will require overhaul of GTFS consumer GTFS pipeline to be able to process GTFS every hour or more.
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.
This is what I had in mind when I drafted GTFS-ServiceChanges, and this is the current state of the GTFS-ServiceChanges proposal.
=> 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)
Hi GTFS community!
As you know, to open the vote on a proposal, we currently need:
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?
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
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?
Downsides?
Thoughts? Especially big real-time consumers (@anatolip-rt, @gcamp, @slai, @TeXitoi, @Tristramg).
Replace two references to pathway_type
in pathways.txt::max_slope
by pathway_mode
.
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.
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.
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.
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).
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?
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.
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.
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
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.)
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.
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.
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!
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.
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.
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
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:
agency_lang
than in the feed_lang
, or discourage them to be specific in the feed_lang
,feed_lang
more specific than an agency_lang
one (e.g. "en-US" as feed_lang
but "en" as agency_lang
).agency_lang
to be like feed_lang
.agency_lang
field once-for-all.feed_lang
has been added (see Joe Hughes 2010 message on the subject)feed_lang
as "DE" and then lists all agencies agency_lang
at "DE" aka speaking German (see GTFS).feed_lang
as "NL" and do not provide language for agencies, since there is only one agency, the NMBS/SNCB (see GTFS)(I personally leans sightly toward option 2, but I would also be fine with option 1, rather than keeping the current inconsistency)
This difference exists for historical reason. The two fields have not been added at the same time.
agency_lang
field has already been proposed in 2009: https://groups.google.com/forum/#!topic/gtfs-changes/mZHnGsHLPywagency_lang
when we have a feed_lang
has already been done twice:
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).
(Note: it used to be called GTFS-DeepLinks)
Hi everybody!
MobilityData received the request to improve the representation of the boarding & alighting restrictions in GTFS.
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:
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?
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.
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.
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?
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?
[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!
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":
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
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).
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!
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.
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
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.
@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
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.
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
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).
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?
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!
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.
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?
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.