Proposal:Public transport timetables
| Public Transport Schedules | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | Polyglot |
| Tagging: | public_transport=timetable |
| Applies to: | 
|
| Definition: | Public Transport Schedule data on route relations. |
| Statistics: |
|
| Draft started: | 2018-11-05 |
Rationale
Timetable data, while crucial information, is probably too volatile for adding to OpenStreetMap.
This proposal was made to figure out whether it would be feasible on a technical level to go into complete detail regarding storing timetable information.
There is one advantage to doing this:
- At the moment route relations only describe the longest variations of telescopic lines, as it is cumbersome to maintain the ways in them, this way of doing things was chosen as an optimisation. The timetable relations would show for any bus that passes a stop at a specific time what its end destination would be.
There are several disadvantages:
- Lots of additional data
- Subject to regular changes
- Lots of exceptions to cater for
- I tried it with a few lines I know. For a line running 18h a day with an interval of around 10' we hit the 255 characters limit of tag values.
Proposal
This proposes adding 2 new relations to OSM:
Agency description
I'm moving this to a separate proposal page, because I think it makes sense to describe the agencies/operators/networks for the simpler proposal as well. When pointing to a GTFS feed, it is still necessary to describe which tags in OSM correspond to which fields in the GTFS files.
The timetable relation
A new type of relation, tagged with type=public_transport and public_transport=timetable which can be used to indicate the departure times at the first stop in the tags for each and the differentials between the stops in the roles. Mostly these differentials will be equal across the timetable. If they do have variance for peak hour which differs more than say 5%, a separate timetable relation would be required describing those trips.
The normal case is that there is one timetable for each sequence of stops forming an itinerary.
| Tag | Description | Example |
|---|---|---|
| type=public_transport | type=public_transport | |
| public_transport=timetable | Timetable information for an itinerary variant | public_transport=timetable |
| from=* | Name of first stop | from=Stop Name |
| to=* | Name of last stop | to=Stop Name |
| via=* | Name of important stop somewhere along the itinerary. | via=Stop Name |
| departures:*=* | To indicate the times at which vehicles depart from the first stop of the itinerary. | departures:MoTuThFr=08:40,09:40,17:40,18:10,18:40,19:40,20:40
departures:schoolholidays:Mo-Fr=08:40,09:40,17:40,18:10,18:40,19:40,20:40 departures:Sa=08:50,11:50,13:50,15:50,17:50 |
| Role | What object? |
|---|---|
| xx:xx | All platform or stop position objects that this timetable applies to in the order the vehicle serves them. It may happen a stop is served more than once, but the same stop should not appear more than once without stops in between. The timetable contains all the stops of an itinerary variation in order. The role contains how long it takes to get from the start of the trip to this stop. The sequence of stops in a timetable relation should always be a subset of the stops in the corresponding route relation.
In case the vehicle stays for a longer time at this stop, this could be shown as xx:xx-yy:yy. |
| route | The public transport route that this timetable applies to. Only one single route should be included as part of a timetable relation. But for a complete schedule of a line several timetable relations will be needed. Each route relation will have at least one timetable, but more are possible in case of telescopic itineraries. The route relations contain the longest possible variants. No route relations are needed for itinerary variations that are shorter, but a timetable relation will be necessary for each possible itinerary variant, as they will always have deviating days/hours that they are valid. The shorter variants are usually for evening fares, or during the weekend. |
Examples
Line 1
Line 5
Normal northbound: https://www.openstreetmap.org/relation/8886015
Shortened northbound: https://www.openstreetmap.org/relation/8886014
I used the same route relation twice, because for telescopic lines I only mapped the longer variants.
Normal southbound: https://www.openstreetmap.org/relation/8886013
Shortened southbound: https://www.openstreetmap.org/relation/8886011
This one refers to another route relation than the previous one, as it does something different for the last 2 stops, so the bus is ready to start again on the northbound journey.
Last fare on Saturday evening only goes to the railway station: https://www.openstreetmap.org/relation/8886012
Comments
This proposal adds 3 new keys:
departures:*=*: Used for describing when departures happen for the public transport route of interest at the stop/station of interest when used on timetable relations.
Discussion
Please use the talk page. Any comments for improving the proposal would be highly appreciated! The goal is to create a system that will serve everyone's needs.