[Voting] Feature Proposal - GTFS Tagging standard

Voting has started for a GTFS Tagging standard.

The aim of the proposal is to have a standardized way to reference objects in GTFS feeds. This is needed because OSM does not - and likely will never (not maintainable) - contain timetable data.
By making a GTFS feed discoverable from OSM and pointing from OSM objects to GTFS objects, we allow data consumers to find timetables.

A short summary:

  1. Deprecate the gtfs_* namespace for the gtfs:* namespace
  2. Deprecate gtfs_id and gtfs:id for gtfs:stop_id and other GTFS column names
  3. Add a new feed relation with the features contained in that feed.
  4. Add gtfs:stop_id:(feed_ref) schema for features in multiple feeds.

Changes since RFC start:

  • Use gtfs:url instead of gtfs:feed_url
  • Add cascading membership to solve issues with regards to relation size
    • List more OSM objects for each type of GTFS object
    • Allow network as a member
  • Allow URL’s that redirect tot the latest version of the GTFS feed
  • Make the characterset of gtfs:feed less strict
  • Explain the difference between network:guid and gtfs:feed
  • Explain the benefit of a relation
  • Explain why it is a good idea to keep the gtfs:* tags seperate from ref, name, …

RFC thread: [RFC] Feature Proposal - GTFS Tagging standard

Aborted the vote, people wanted room for more discussion

I have started a new vote for this proposal.
Voting will end on the 25th of February 2024.
Old votes do not count to the result as they were for a significantly different version of the proposal. To indicate that I have put them in a separate section and but a line through them.

Changes since aborted vote:

  • Remove the feed relation
  • Add a wiki page to manage the feed codes and their download URL’s

Two weeks have passed and there were only 4 votes cast.
If you haven’t voted, I encourage to read through the proposal and vote.
I will extend the deadline by another two weeks.
The new deadline is March 11th


Voting has closed.
The proposal has been approved with 9 votes for and 3 votes against.
I will clean up the proposal tomorrow.

Because some of the oppose votes did not like gtfs:location_type, I will add a description on how to derive a default value based on the type of OSM object. Essentially this will correspond to the table in the background section of the proposal.

They also would like gtfs:stop_id/gtfs:stop_code to be defaulted based on ref/ref:IFOPT. This was also brought up in RFC and I included a section in the proposal on why I believe it is better to keep them seperate, even if that may cause duplicate tags.

For the deprecated tags I will mention that their use is discouraged and which tags should be used instead. The tags will still be in use for a while, so additionally I will describe how they should be interpreted as a fallback for when the approved tags are not present.


Relevant pages have been edited and the proposal has been archived.

1 Like

Thanks for taking care and compiling the stuff.