Proposal:GTFS Tagging Standard
| GTFS Tagging Standard | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | Spaanse |
| Tagging: | gtfs:(gtfs_column):(gtfs_feed_code)=* |
| Applies to: | type |
| Definition: | Properties of an object in a GTFS feed |
| Statistics: |
|
| Draft started: | 2023-11-07 |
| RFC start: | 2023-11-09 |
| Vote start: | 2023-11-30 (aborted)
2024-02-11 |
| Vote end: | 2023-12-14 (aborted)
2024-03-11 |
Proposal
I want to standardise the way of tagging GTFS.
This proposal consists of multiple parts:
- Make the gtfs:*=* namespace the standard, deprecate the gtfs_*=* namespace.
- Deprecate gtfs_id=* and gtfs:id=*, prefer tags with the GTFS column names
- Propose gtfs:*:(feed_code)=* to distinguish the feed that this property belongs to. This allows an object to store their ID's in different feeds.
- Maintain a list of feeds and their codes on this wiki (List of GTFS feeds) using templates that can be read by machines.
How this proposal is formulated
Any requirements will be underlined and formulated using MUST, SHOULD, MAY, ... as they are defined in RFC 2119
These requirements are meant for implementation of validators, import tools and data consumers.
These requirements are interspersed with the reasoning for them.
Rationale
I want that apps that use OpenStreetMap, like OSMAnd, to be able to do proper public transit routing.
There have been many discussions on ways to include timetables in OSM.
However these have all led to the following conclusion: too much data that is too volatile.
Google developed GTFS (General Transit Feed Specification) to solve this problem for their products
This is now an open standard, and pretty much all operators offer such a feed - often under a public license.
Therefore I believe that we should standardise a way to link to those feeds.
Furthermore, this proposal also wants to resolve the issues raised on the GTFS wiki page.
Background: How does GTFS work?
GTFS is a standard that describes how public transport agencies should publish timetables and other information so that they can be used by public transit applications. GTFS data is published as a zip file, containing multiple csv files. The transit agencies make this zip file available at a fixed URL - the GTFS feed. When things change in the network, agencies make a new zip and update the version in the feed.
| File | Description | Column | Type | Description |
|---|---|---|---|---|
| stops.txt | Describes physical locations | stop_id | ID | Unique identifier for a location |
| stop_code | Text | Public-facing identifier for a location | ||
| stop_name | Text | Name of the location | ||
| stop_lat | Float | Location, for stops on the pole. | ||
| stop_lon | Float | |||
| location_type | Enum | 0: stop / platform
1: station; contains multiple stops/platforms 2: entrance / exit 3: generic node 4: boarding area | ||
| parent_station | ID | the station it belongs to | ||
| platform_code | Text | Identifier for the platform | ||
| routes.txt | Describes a service
OSM equivalent: route_master |
route_id | ID | Unique identifier for a route |
| agency_id | ID | Id of the agency running this route (agency.txt) | ||
| route_short_name | Text | Short identifier of the route - e.g. bus number | ||
| route_long_name | Text | Full name of route, often with destinations | ||
| route_type | Enum | What sort of transportation is used (bus/train/...) | ||
| trips.txt | Describes a sequence of stops, at a particular time.
In OSM, a route (variant) refers to a sequence of stops. Thus the difference with a trip is the inclusion of time. |
route_id | ID | The route the trip belongs to |
| service_id | ID | The days of operation for the trip (calendar.txt) | ||
| trip_id | ID | Unique identifier for the trip | ||
| trip_headsign | Text | Displayed destination of the trip | ||
| trip_short_name | Text | Public facing text to identify the trip | ||
| direction_id | Enum | 0/1, distinguish direction of trips | ||
| shape_id | ID | The path the vehicle travels (shapes.txt) | ||
| shapes.txt | The path that a vehicle travels
This is closer to a route variant as it is in OSM. Does not include the sequence of stops. |
shape_id | ID | Unique identifier for a shape |
| shape_pt_sequence | Int | Place of point in the shape | ||
| shape_pt_lat | Float | Position of a point | ||
| shape_pt_lon | Float | |||
| stop_times.txt | Describes the times that a trip stops at each stop | trip_id | ID | The trip this stop time is for |
| stop_id | ID | The stop this stop time is for | ||
| stop_sequence | Int | Place of stop in trip | ||
| arrival_time | Time | Time of arrival/departure at this stop | ||
| departure_time | Time | |||
| pickup_type | Enum | Whether pickup or dropoff is available
0: yes, 1: no, 2: call required, 3: ask driver | ||
| drop_off_type | Enum |
| PTv2 concept | GTFS concept | GTFS Description |
|---|---|---|
   public_transport=platform (preferred)
|
stop (stops.txt)
location_type=0 |
Place where passengers board/disembark |
public_transport=station public_transport=stop_area
|
station (stops.txt)
location_type=1 |
Physical structure or area with one or more platforms |
| railway=subway_entrance
|
entrance/exit (stops.txt)
location_type=2 |
A location where passengers enter/exit a station |
| type=route
|
trip (trips.txt)
shape (shapes.txt) |
A sequence of stops, at a specific time |
| type=route_master
|
route (routes.txt) | Group of trips displayed as a single service |
| type=network
|
- | - (only used for cascading membership) |
The examples below indicate how we could make use of both OSM and GTFS, and what we need for that.
Example: how to find departure times for a particular route and stop
- Download the feed and unzip it
- Determine the right row in stops.txt and remember its stop_id
- Determine the right row in routes.txt and remember its route_id
- Find all trips with that route_id and remember their trip_id
- Find all stop times with the stop_id and route_id to get the departure times
If we want to initiate this from OSM, we need the following information in OSM:
- Where can we download the feed?
- Enough information about the stop to determine the right row in stops.txt
- Enough information about the route to determine the right row in routes.txt
Example: how to find the route variants for these departure times
- In OSM: look at all route variants of the route we used
- See if they match with one of the trips
Or alternatively:
- In OSM: look at all route variants that contain the stop
- See if they match with one of the trips
So for this we need enough information to see if a trip matches with a route variant.
Tagging
We have the following list of things that this proposal should achieve:
- A way to discover where to download the GTFS feed
- A way to determine the right row in a GTFS file for stops, stations, route variants and routes.
- Resolve the namespace that is used for GTFS tagging; currently both gtfs_*=* and gtfs:*=* are in use.
- Create a way to handle features that are part of multiple feeds.
GTFS Namespace
I propose to make the gtfs:*=* namespace the standard.
I prefer the syntax since it is clearer that it is a namespace.
Furthermore there are more existing wiki pages for gtfs:*=* (see list at the end) than for gtfs_*=* (only Key:gtfs id)
A comparison of usage for both namespaces can be found further down in this proposal.
I suspect that a decision either way will be the same amount of work.
All tags about GTFS MUST be placed in the gtfs:*=* namespace
Tags MAY use underscores after the namespace prefix
Tags SHOULD use GTFS column names where applicable
This last rule also makes it clear which file of the GTFS feed is referred to; most columns start with the object's type.
In particular, the tags gtfs_id=* and gtfs:id=* should be deprecated.
Instead tags like gtfs:stop_id=*, gtfs:trip_id=*, gtfs:route_id=* and gtfs:shape_id=* should be used.
Tags for referencing a GTFS object
Referencing a GTFS object is done using any combination of the following tags:
| Type | Tags |
|---|---|
| stop | gtfs:stop_id=*, gtfs:stop_code=*, gtfs:stop_name=*, gtfs:location_type=0, gtfs:platform_code=* |
| station | gtfs:stop_id=*, gtfs:stop_code=*, gtfs:stop_name=*, gtfs:location_type=1 |
| entrance | gtfs:stop_id=*, gtfs:stop_code=*, gtfs:stop_name=*, gtfs:location_type=2 |
| route | gtfs:trip_id=*, gtfs:trip_id:sample=*, gtfs:shape_id=* |
| route master | gtfs:route_id=*, gtfs:route_long_name=*, gtfs:route_short_name=* |
The combination of tags used SHOULD reference an unique object in the GTFS feed
Other columns MAY be tagged as well, but are ignored for the rule above
The GTFS standard recommends that ID's should persist between versions. This may not always be the case.
Therefore, analyse historic versions of the feed to see which combination of tags is the most stable.
It may be that gtfs:stop_code=* is more stable than gtfs:stop_id=*, in which case it is recommended to only use gtfs:stop_code=*.
ref:IFOPT=* SHOULD NOT be used as a replacement for gtfs:stop_id=* and friends. (contrary to the current GTFS wiki page)
adding gtfs:stop_id=* communicates that it is needed for matching and gives the exact value that is present in the feed.
ref:IFOPT=* may not match exactly, for example ref:IFOPT=NL:Q:50201120 and gtfs:stop_code=50201120.
It is allowed to tag both ref:IFOPT=* and gtfs:stop_id=* with the same value.
gtfs:name=*, gtfs:short_name=*, gtfs:long_name=* SHOULD NOT be used as a replacement for the full column names
These tags do not exactly match a GTFS column name.
Using these means that the data consumer needs to guess which table to use and which columns to match.
This also makes the semantics of referencing a unique object unclear.
Finding the feed
Currently there is no way to find the feed download URL from an object of that feed in OSM.
PTNA uses gtfs:feed=* to distinguish between feeds, but there is no list of their values and the corresponding URL's
I propose that we document these values on List of GTFS feeds, along with properties about the feed.
There I use a template for each feed so that a machine can extract the feed codes and their URL.
Handling multiple feeds
An object can be part of multiple feeds, in which case it is unclear which feed a GTFS tag belongs to.
To solve this, I propose to use gtfs:*:(feed_code)=*, where feed_code is one listed in List of GTFS feeds.
It is adviced to start these feed codes with the ISO 3166-2 code for the region.
The current combination of gtfs:*=* and gtfs:feed=(feed_code) will be deprecated in favour of gtfs:*:(feed_code)=*.
Example
I will use the OVApi GTFS feed as an example. It covers all public transport in The Netherlands.
To start I have added the following to List of GTFS feeds:
Feed Information NL-OVApi
| |
| Name | OVapi |
| Operator | Stichting OpenGeo |
| Links | Feed Conditions |
This tells us that the feed code is NL-OVApi
Tags on a route_master
Look at the route master Bus 10 (Nijmegen):
The corresponding row in the GTFS feed looks like:
| rotue_id | agency_id | route_short_name | route_long_name | route_desc | route_type | route_color | route_text_color | route_url |
|---|---|---|---|---|---|---|---|---|
| 87966 | BRENG | 10 | Nijmegen CS - Heyendaal | 3 (bus) | ||||
| 87987 | BRENG | 10 | Nijmegen CS - Heyendaal - CS | 3 (bus) |
Note: there should not be multiple rows. I will use the second row since it has 19450 rides instead of 2821
I have determined that the route ID is quite stable, so adding gtfs:route_id:NL-OVApi=87987 suffices.
Another option would be to tag gtfs:route_long_name:NL-OVApi=Nijmegen CS - Heyendaal - CS
Tags on a route
Look at the route Bus 10: Ringlijn Nijmegen Centraal Station => Universiteit HAN
There are many trips for this route, a couple of them:
| route_id | service_id | trip_id | trip_headsign | trip_short_name | trip_long_name | direction_id | shape_id | ... |
|---|---|---|---|---|---|---|---|---|
| 87987 | 457 | 177374763 | Heyendaal | 79 | 0 | 1127909 | ||
| 87987 | 457 | 177374758 | Heyendaal | 69 | 0 | 1127909 | ||
| 87987 | 457 | 177374753 | Heyendaal | 59 | 0 | 1127909 |
In my analysis of different feed versions I found that the trip_id's are not stable, most of them change between versions.
The shape_id is more stable, so I will add gtfs:shape_id:NL-OVApi=1127909
If I would have used the trip_id, it would look like gtfs:trip_id:sample:NL-OVApi=177374763
Tags on a station
Look at Station Nijmegen.
The corresponding row in the feed:
| stop_id | stop_code | stop_name | location_type | parent_station | platform_code | ... |
|---|---|---|---|---|---|---|
| stoparea:17857 | nm | Nijmegen | 1 (station) |
I have determined the stop_id's to be quite stable, so I can add gtfs:stop_id:NL-OVApi=stoparea:17857
However, in this case the stop_code is fixed for the station and printed on timetables.
So in this case gtfs:stop_code:NL-OVApi=nm (and railway:ref=nm) is preferred.
Tags on a bus station
Look at Nijmegen bus station
The corresponding row in the feed:
| stop_id | stop_code | stop_name | location_type | parent_station | platform_code | ... |
|---|---|---|---|---|---|---|
| stoparea:122872 | Nijmegen, Centraal Station | 1 (station) |
In this case we can do: gtfs:stop_id:NL-OVApi=stoparea:122872
Or gtfs:stop_name:NL-OVApi=Nijmegen, Centraal Station with gtfs:location_type:NL-OVApi=1 (to exclude platforms)
Tags on a bus platform
Look at Nijmegen Centraal platform M
The corresponding row:
| stop_id | stop_code | stop_name | location_type | parent_station | platform_code | ... |
|---|---|---|---|---|---|---|
| 2547419 | 60001013 | Nijmegen, Centraal Station | 0 (platform) | stoparea:122872 | M |
Again we can use the stop_id: gtfs:stop_id:NL-OVApi=2547419.
However, we have ref:IFOPT=NL:Q:60001013, so we see that stop_code is part of the IFOPT and thus stable.
Therefore we will tag with both ref:IFOPT=NL:Q:60001013 and gtfs:stop_code:NL-OVApi=60001013
Another alternative would be gtfs:stop_name:NL-OVApi=Nijmegen, Centraal Station and gtfs:platform_code:NL-OVApi=M
Considerations
Existing tagging and projects
| Namespace | Nodes | Ways | Relations | Total | Overpass |
|---|---|---|---|---|---|
| gtfs_*=* | 115647 | 846 | 4376 | 120869 | https://overpass-turbo.eu/s/1D43 |
| gtfs:*=* | 50682 | 1190 | 22882 | 74754 | https://overpass-turbo.eu/s/1D44 |
This shows that the gtfs_*=* is more common on stops and gtfs:*=* on relations.
| gtfs_*=* | gtfs:*=* | gtfs_*=* | gtfs:*=* | |
|---|---|---|---|---|
The stops in gtfs_*=* have tags for all columns in stops.txt, likely from an import
In contrast gtfs:*=* seems to be more aimed at linking to a GTFS feed
An overview of tools that do something with both GTFS and OSM:
Neither: Osm2Gtfs [1], OpenTripPlanner [2]
Transitional period
Currently there are a lot of objects using both namespaces.
If this proposal is approved, we can start the process to approve an automated edit changing gtfs_*=* to gtfs:*=*.
I think it is also a good idea to change gtfs_id=* to gtfs:stop_id=*, but that requires more care and looking at feature type and related tags.
There are some (but few) route relations that use gtfs_id=*.
I don't think this edit would be problematic since:
- There is no semantic difference for the namespace change, and minor difference for the gtfs_id=* change.
- GTFS tags are not (or at least should not) be rendered.
- I suspect most of these tags were originally imported anyway
Licensing (not part of the proposal, many open questions)
I think that feeds mentioned in List of GTFS feeds should be OSM compatible.
The reason for this is that those feeds are likely going to be used to maintain routes in OSM (likely as a diff tool).
If licensing information should be part of the machine-readable template is a tricky question.
Other ways of dealing with multiple values
Existing schemes for dealing with multiple values :
- (deprecated) numbering the multiple values: name_1=*, name_2=*, ...
- Multiple values seperated by a semicolon (
;): name=foo;bar - More specific tags: old_name=*, official_name=*, alt_name=*, ...
These do not address cases where
- We want to know which feed corresponds to which value.
- The values can be arbitrary strings, making the use of seperators troublesome.
- The domain of keys is not predefined (like 1,2,3 or old,official,alt)
Keeping GTFS tags separate from normal tags like ref, name, ...
Normal tags serve a different function than the gtfs:*=* tags, neither is a replacement of the other. The goal of normal tags is to be displayed to the user. The goal of gtfs:*=* tags is to allow easy lookup of the corresponding GTFS object and associated timetables. Because they have different goals, there are different requirements for their values. Normal tags should be optimized for humans - proper capitalisation - and match what is on the ground. gtfs:*=* tags should match exactly with the value in the GTFS feed. This makes them incompatible to have them in the same tag. Imagine the following scenario:
The following bus stop (osm) is imported from OVApi (stop_id=1329998), and stop_name is placed in name=Huis ter Heide, Pr. Alexanderstichting. Suppose that we defaulted gtfs:stop_name=* with the value of name=*, and this is required to find the right GTFS object (no stable id/stop code). Now a mapper sees this on the map and fixes this to name=Prins Alexanderstichting, now we cannot lookup the GTFS object anymore. You may argue that the mapper should have added gtfs:stop_name=Huis ter Heide, Pr. Alexanderstichting, but how could they have known this? Instead, the original import should have added this tag - even if it has exactly the same value - to allow the mapper to change name=* without affecting the GTFS lookup.
The other direction can cause even more grief. Imagine that a name/id has changed in a GTFS feed and an mechanical edit changes name=* to fix this. This can undo a proper change by a mapper. Therefore, any such mechanical edit would get a lot of push-back from the community. If instead the mechanical edit changes gtfs:stop_name=* nothing breaks, and then a QA tool can ask mappers to review if this change should also be pushed to name=*.
Other ways of linking the feed
In a previous version of this Proposal, I used a relation for all objects of a feed that contained the URL.
However, this would hit the limit on relation size and solving that removed a lot of the benefits of this relation (having it easily findable and having the data in OSM).
Another alternative that was suggested: tag the feed URL on all objects of the feed.
In that case the feed code suffix would have the same function as :1, :2, ...
The downside of this approach is that when the URL changes (for example, ch-alle publishes a new feed each year) it needs to be changed on all objects.
Features/Pages affected
- GTFS to describe the standardised tagging scheme
- Key:gtfs id to deprecate in favour of specific tags
- Key:gtfs:stop id to describe the feed code suffix
- Key:gtfs:trip id to describe the feed code suffix
- Key:gtfs:trip id:sample to describe the feed code suffix
- Key:gtfs:route id to describe the feed code suffix
- Key:gtfs:shape id to describe the feed code suffix
- Key:gtfs:name to describe the feed code suffix
- Key:gtfs:feed deprecate in favour of the feed code suffix
- Public transport to add that there is a standardised way of tagging feeds
- List of GTFS feeds and Template:GTFS feed
External discussions
https://community.openstreetmap.org/t/draft-feature-proposal-gtfs-tagging-standard/105763/2
Comments
Please comment on the discussion page.
Voting
Live vote (2024-02-11 - 2024-03-11)
Voting on this proposal has been closed.
It was approved with 9 votes for and 3 votes against.
I approve this proposal. A GTFS tagging standard is very needed in OSM. Even if this is a technical change it will be very useful for tools that make use of that data for GTFS data matching. -- Gabenarni (talk) 22:57, 17 February 2024 (UTC)- I approve this proposal. -- Something B (talk) 23:12, 16 February 2024 (UTC)
- I approve this proposal. Agree to what has been said by Gabenarni above. --ToniE (talk) 13:22, 18 February 2024 (UTC)
- I approve this proposal. Welcome to a very necessary standard in OSM.--Yopaseopor (talk) 18:26, 20 February 2024 (UTC)
- I approve this proposal. --Flo Edelmann (talk) 09:33, 26 February 2024 (UTC)
I oppose this proposal. This still looks like it is duplicating a large part of the GTFS feed data in OSM. --Lonvia (talk) 10:00, 26 February 2024 (UTC)
- I approve this proposal. This is a very needed change for public transit apps built on OSM --AmOosm (talk) 10:31, 26 February 2024 (UTC)
- I oppose this proposal. While I like your effort to better harmonize the tags, I feel this complex proposal is not ready, yet. The sections about the projects which are effected by these changes is incomplete. How can I code presets with the feed as part of the key? It is not clear which new keys are introduced and voted on. It even sounds like an invitation to add everything. A transition from OSM tags to GTFS columns is always needed therefore the established gtfs:name=* can be use for
stop_nameandroute_long_nameplus no duplication of ref:IFOPT=* and gtfs:stop_id=* in case of identical values. There is no need to deprecate gtfs:feed=* if only one GTFS-feed is available. --Skyper (talk) 13:08, 26 February 2024 (UTC)
- projects affected - It is not required for a proposal to list all projects affected. It is there to show that I looked at some projects to decide whether to use underscores or colon's. Which projects are missing and would that influence the choice of seperator? --Spaanse (talk) 17:03, 26 February 2024 (UTC)
- presets - I don't know how to do that. I feel like that may be a shortcoming of presets rather than this proposal. You can raise the same issue for
name:(language code)which is accepted usage. Also: most objects that have GTFS tags got these using an import rather than someone manually adding them with a preset. --Spaanse (talk) 17:03, 26 February 2024 (UTC)- Exactly, as the common editing software do not support it the changing parts of a tags are in the value. In my eyes,
name:(language code)is different as I can easily write a preset for a specific language or even all. Better take a look at traffic_sign=*. --Skyper (talk) 14:42, 1 March 2024 (UTC)- I think my point about the imports got lost. Editors will not contribute significantly to the adoption of GTFS tagging, so I see no reason to make the standard more complicated for them. The proposal is aimed at making imports easy and low risk (by having the gtfs namespace and seperating tags for different feeds), and to make it easy to consume the data (no parsing, exact matches with columns).
- having key-value pairs in the value of a tag has been considered. But unlike regional traffic signs the GTFS tags have to support 1. a set of feed codes that is not known beforehand and 2. arbitrary values since the GTFS columns can contain anything. Something like gtfs:stop_id=NL-OVApi:stoparea:122872 is confusing. Furthermore, having multiple key-value pairs in one tag may have international hubs going over the 255 character limit on values. So for your scheme to work it would need to define escape sequences and ways to overflow into a new tag, at which point it becomes unnecessarily complicated.
- "common editing software" = JOSM? iD supports changing parts of tags in the value. You can add localised names where you have a dropdown for the language and a field for the name. For GTFS tags there could be something similar - but with a single text field that changes the feed code for multiple tags.
- --Spaanse (talk) 19:38, 4 March 2024 (UTC)
- Exactly, as the common editing software do not support it the changing parts of a tags are in the value. In my eyes,
- keys voted on - The vote is for the general scheme of
gtfs:(column name):(feed code)with the specific tags listed under "Tags for referencing a GTFS object" used for identification. --Spaanse (talk) 17:03, 26 February 2024 (UTC)- Thanks for the clarification. I am still against e.g. gtfs:location_type=*. --Skyper (talk) 14:42, 1 March 2024 (UTC)
- keys introduced - A proposal does not need to introduce keys. In this case the proposal aims to standardize a set of tags to be used for referencing GTFS feeds and deprecate other keys that would not conform to that standard. To use the column name in the key is not new, some imports have imported all columns to
gtfs_(column name). What is new is the feed code suffix to allow referencing multiple feeds. --Spaanse (talk) 17:03, 26 February 2024 (UTC) - invitation to add everything - The
gtfs:(column name)scheme is meant to exclude tags that are not column names since they are harder to match. For what this proposal encourages to add is one or two tags that suffice to identify a specific object. --Spaanse (talk) 17:03, 26 February 2024 (UTC) - transition to GTFS columns - That the transition is necessary does not mean that we can't make it as simple as possible. Each of your proposed changes complicate this process. --Spaanse (talk) 17:03, 26 February 2024 (UTC)
- I approve this proposal. Agree with the statements from Gabenarni -- CaldeiraG (talk) 14:23, 26 February 2024 (UTC)
- I approve this proposal. -- Dmfr (talk) 18:04, 26 February 2024 (UTC)
- I oppose this proposal. Parts of this proposal are certainly useful, but I still think it's a very bad idea to approve tags like gtfs:stop_code=* & gtfs:location_type=* which intentionally duplicate tags like ref=* & public_transport=station. You said earlier this is because you want your import to be "separate" from the OSM data that everyone else edits... Wouldn't it be better to carefully review other mappers' edits, rather than inventing new tags to prevent anyone from touching your imported data? Other cities are trying to clean up these duplicate or contradictory tags which you're about to approve. I tried to discuss this previously but apparently our discussion is "resolved"... --Kylenz 03:15, 10 March 2024 (UTC)
- The tags are also in their own namespace to prevent automated edits from touching mappers edits.
- Any tag that you want to have a default outside of the
gtfsnamespace needs to (1) rarely change and (2) have a clear method to translate into the value of the GTFS column. For gtfs:location_type=* this should be doable; (1) objects don't often change what they fundamentally are (2) the table in the "How does GTFS work" section could decide the value. We only need a way to decide what to do if something contains multiple of the listed tags (rare edge case). gtfs:stop_code=* fails on criterium (2). The train station example shows that it should use the exact value of railway:ref=*. The bus platform example shows that it should use a stripped version of ref:IFOPT=*. The method would need to describe how to strip, and what happens when both are present. Furthermore - no GTFS feed is the same, so you would need to look at all feeds how they use theirstop_codecolumn and account for that as well. The simpler solution is to add gtfs:stop_code=*, even if it would match exactly with other tags. - The edit you mention also shows that gtfs:stop_name=* does not satisfy criterion (2), try to describe how to revert their process of renaming. Also, I think you misrepresent the issue that edit solved. Instead of cleaning up duplicate tags it fills the standard tags based on the imported tags. Then the imported tags are removed which I could raise an objection to. Any data consumer that used them is forced to reconstruct them from the new set of tags, which is impossible.
- As for resolving that discussion: On the 26th of November I added a section to the proposal explaining my reasoning for avoiding normal tags and keeping them in the GTFS namespace. I also asked if you had any counterarguments to that section. On the 28th of November I marked that discussion as resolved because it had been incorporated into the proposal and there were no further comments by you in those two days. I could have waited a bit longer to resolve the discussion. On the other hand, you are allowed to (re)open a discussion you feel like has been resolved inadequately.
- Spaanse (talk) 13:24, 10 March 2024 (UTC)
- I approve this proposal. GTFS data is needed in OSM, and I hope that this proposal will lead to better integration of public transportation routing. --Ÿnérant (talk) 08:47, 30 November 2023 (UTC)
Aborted vote (2023-11-30 - 2023-12-14)
- There is currently no good way to figure out which feeds an bus stop belongs to. And if you found the feed you can only really determine the object based on location, which could give you the stop on the other side of the road.
- With this proposal the process is: look at all the parent relations to find the GTFS feed relation. Then follow the URL to download the feed. Then find the line in `stops.txt` with the matching `gtfs:stop_id`, `gtfs:stop_code` or similar.
- For keeping it in sync - before adding the `gtfs:*` tags someone should look at the feed and it's historic version to determine which combination of columns is the most stable. This should ensure that the references are quite stable. A bot could monitor changed objects in the feed/OSM and fix automatically or ask a mapper.
- If it goes out of sync it becomes much less useful.
- Spaanse (talk) 10:29, 30 November 2023 (UTC)
Aborted the vote to allow for more discussion