Add GTFS extended route_types

[naxxfish]

Proposed by Google https://developers.google.com/transit/gtfs/reference/extended-route-types

Discussed (in 2008) at length here: https://groups.google.com/g/gtfs-changes/c/keT5rTPS7Y0/m/LH4G0R9iCQAJ

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[gcamp]

Can you explain a bit how those all route types would be useful? There's a lot of service that I don't see being used in GTFS ever.

[naxxfish]

The Google proposal does provide examples for many of the route types, derived from this (now defunct) BBC page, which in of itself was proposed by TPEG.

They are being used by producers, e.g. 109 in VBB in Germany to represent Suburban Railways, or in 700 in Timetable Feed for NSW
Buses to represent busses.

The original list was derived from the TPEG specification and has been pared down since then. It could be reduced further (to remove more unusual types like "Post Bus Service" or "Aerial Lift Service", however by doing so there would be holes in the sequence which may increase confusion. Renumbering the list would risk overloading existing interpretations of the route_types.

Since the proposed extension has been publically available for so long, and datasets have been built that use them, despite the fact that the meaning of these types are relatively well known and supported in many consumers (e.g. Google Transit and , GTFS produced using these values fails validation in many implementations of validators as it is not part of the reference specification.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[skinkie]

I don't support these kind of changes. Google Maps is not the exclusive user of these datasets.

[naxxfish]

From cursorary observation of a small sample of datasets, these seem to be the more popular ones.

Very happy to revert that commit if these (official but unofficial) extensions are actually in use in the real world.

[skinkie]

I would say, these values should be update to recent TPEG changes, and then use all the TPEG values. It is a hierarchy anyway.

[naxxfish]

If it's desirable to synchronise with TPEG2-PTS (TS 21219-13:2020), that seems like a logical course of action. However, I don't personally have access to this specification (it comes at a cost of 178 CHF from the ISO webshop or £260 from the BSI webshop) to know the new values, and as far as I know they aren't publically available in isolation from the standard anywhere. I'm also unsure on the terms of the copyright for that standard and whether it'd be permissible to replicate a part of it in the GTFS specification.

Also, it may not be desirable to simply replicate the TPEG standard list of vehicle types, but actually only a subsection of it that is likely to be useful for data export in GTFS format. The intended uses of the two are different - TPEG is primarily interested in transmission of transport related information for immediate consumer use (e.g. traffic alerts in DAB radios, where it originated) - rather than describing a schedule or changes to it. The types of vehicle represented may not all be relevant to GTFS.

Then again, transit providers may already have systems which use the TPEG codes for use in different areas (e.g. issuing service alerts to broadcasters), so making the two instantly compatible may be beneficial.

Hard for me to know from my viewpoint! Would welcome thoughts from others.

[skinkie]

I think SIRI should be / is going to be updated. Already with a limited scope.

[naxxfish]

SIRI modes for the most part seem to be compatible here. The only difference is they don't have numeric values (they've just enums) - so in order to preserve compatibility with providers implementing the defacto Google extension, the original numbers would need to be preserved and any additions to be assigned new numbers.

[skinkie]

Can you explain a bit how those all route types would be useful? There's a lot of service that I don't see being used in GTFS ever.

Also in Swiss data this exists. Specifically differentiation between rail modes are very prominent.

[sccmcca]

If I may reference @aababilov's (@ Google) thoughts on this matter from #174:

I find extended route types dreadful. Many of them are unclearly defined (say, what is the difference between metro and underground?!) and many types are simply missing there (no way to tell between tram and light rail etc). I am supporting the GTFS-Modes proposal which gives the full flexibility to data providers and consumers (http://bit.ly/gtfs-modes-and-networks). I would like to keep the list of route_types short and dense.

As mentioned, the GTFS-ModesAndNetworks proposal may be a favorable solution as it allows distinction between what a mode is locally called and a stable wikidata identifier describing what it is. This avoids the exhaustive listing proposed in this PR.

[abyrd]

A few observations:

• Although TPEG codes are regularly encountered "in the wild" and are used by Google, as far as I know this was never officially adopted as an extension. It is reasonable to expect producers and consumers employing an unofficial extension to adapt their data when the functionality is finalized through an official process.
• It may be problematic to officially embed a non-open standard (TPEG) inside an open one (GTFS). Are we certain that there are no legal constraints on embedding even a pared down form of an early draft?
• If there are no legal concerns, a subset of TPEG codes is convenient because like the existing route_type field they are numbers, they are hierarchical, and some feeds already use them.
• It is very useful that the codes are hierarchical. This allows GTFS producers to micro-categorize their routes if desired, while making it straightforward for GTFS consumers to collapse these down into 10 or so high level categories.
• With such a hierarchical code system, it's more or less harmless to have some unused or ill-defined modes.

Placing the entire list of modes inline in the description of route_type is quite verbose and puts them on par with the original 7 modes. Even if extended mode codes are adopted, I think there is still a clear hierarchy: the original 7 modes are very widely used and much more likely to be handled exhaustively by consumers; the many additional codes are clearly an extension, and consumers are very likely to handle them by mapping them down to a smaller set, or handle a few as special cases. (Some of the original modes like "cable car" might also get second-class support, but the core idea remains.) The reference for all available mode codes should probably be pulled out into a separate section and referenced from the route_type description.

It is somewhat appealing to just scrap any exhaustive list of codes, and make modes and networks fully producer-defined as suggested by @scmcca. The GTFS-ModesAndNetworks proposal looks promising, but it might benefit from a few revisions. For example, it seems like producers would be required to define a route_type on every route even when they have also defined a mode. I'm also unclear on why the modes would be tied to an ID in a predetermined database (mobilitydatabase.org or wikidata), as opposed to a URL. URLs are used elsewhere in GTFS, and are themselves globally unique IDs.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.

[skinkie]

Keep open.

[sccmcca]

@skinkie As defined in article 8 of the Specification Amendment Process, it is up to the advocate (@naxxfish) if they wish to continue the proposal.

Article 8 reads:

Any pull request remaining inactive for 30 calendar days will be closed. When a pull request is closed, the corresponding proposal is considered abandoned. The advocate may reopen the pull request at any time if they wish to continue or maintain the conversation.

If you have a counter proposal or wish to advocate this PR yourself, I think this would be easiest done by opening a separate one.