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:
Deprecate the gtfs_* namespace for the gtfs:* namespace
Deprecate gtfs_id and gtfs:id for gtfs:stop_id and other GTFS column names
Add a new feed relation with the features contained in that feed.
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, …
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.