Proposed features/Public transport schedules
|Public Transport Schedules|
|Status:||Proposed (under way)|
|Definition:||Public Transport Schedule data on route relations and ferry ways.|
- 1 Rationale
- 2 Proposal
- 2.1 First proposed feature:
- 2.2 Second proposed feature
- 2.3 Third proposed feature (ferry routes)
- 3 Comments
- 4 Discussion
Public transport data in OpenStreetMap is improving rapidly. People all over the world are mapping local bus lines, ferries, railways, etc. Some do this manually, while others import General Transit Feed Specification data. Unfortunately, adding timetables, one of the most important aspects of such data, is not possible.
Timetable data, or schedule data, is the last crucial feature yet to be approved for making public transport data in OpenStreetMap useful to riders. Almost every other specification (including adding separate relations for different variations of public transport routes and opening hours) has already been approved. So why not schedule data?
Schedule data in OpenStreetMap would allow for applications such as OsmAnd and Maps.me to create public transport based routing services that would be useful to users. People could use OpenStreetMap instead of individual operators' maps when navigating new places. Services similar to Google transit could be created, all using OpenStreetMap.
Unfortunately, many mappers in the OpenStreetMap community consider any method of adding schedule data to public transport features to be too complicated. They believe it to be messy and impossible to maintain.
These are valid concerns, which are all considered are mediated to the maximum extent possible in this proposal. Overcoming complexity is easy. Overcoming the issue of maintainability is much more difficult.
This proposes adding three new features to OSM:
- An interval=* tag for marking the frequency of a public transport feature
- A new type of relation that would represent the arrival times at a single bus stop for a single route relation
- A system for marking the departure times and duration of a ferry route
First proposed feature:
- Main article: Proposed features/Public transport schedules/IntervalUsing the tag interval=<number of minutes between departures at any given stop on the route> to state how frequently buses or trains (or ferries) run on a certain line. In the example photo on the right, the tag interval=01:00 would be added to the "Mid-Day Connector To Mebane" bus route relation. The existing tag opening_hours=* could also be used.
The tag interval=* can be added to the route relation or ferry route way according to this proposal.
Second proposed feature
This is used on normal public transport features (not including ferry routes). This idea was suggested by Polyglot on the talk page. It is much simpler than screwing with existing relation roles, and can be deleted much more easily in the case that the data is outdated.
Each public transport platform or stop position can have one timetable relation for each public transport route that serves the platform or stop position.
|type=public_transport||To indicate that this relation has something to do with public transport.||type=public_transport|
|public_transport=timetable||To indicate that this public transport relation is a timetable relation||public_transport=timetable|
|departures=*||To indicate the times at which trains, trams, buses, etc. arrive at this station.||departures=Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40, 16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40;Sa 08:50, 11:50, 13:50, 15:50, 17:50|
|route||The public transport route that this timetable applies to. Only one single route should be included as part of a timetable relation.|
|stop||The platform or stop position that this timetable applies to. Only one single platform or stop position should be included as part of a timetable relation.|
1) The bus stop in the image above: A new timetable relation is created with the following tags: type=public_transport, public_transport=timetable, and departures=Mo-Fr 10:45, 11:45, 12:45, 13:45, 14:45. The bus stop, or platform, is included in this new relation with the role "stop". The bus route is included with the role "route".
This method would not modify existing public transport features in any way or form.
Third proposed feature (ferry routes)
Ferry routes mapped as relations with two stops should use the second proposed feature, timetable relations.
Ferry routes which are not mapped with separate relations for the two directions of the route have no platform members. This makes the above methods of using a relation for each bus route serving each stop unusable on them.
Rather than using this proposal, it has been suggested that ferry routes mapped as ways should simply be converted into relations and use timetable relations instead as to reduce complexity. If timetable relations are approved, this feature will be abandoned in favor of timetable relations. If they are rejected, this proposal will move forward.
If the ferry route has no schedule system at all
If the ferry route operates every X minutes, with unpredictable departure times throughout the day.
schedule_type=interval and interval=* used similarly to standard public transport routes. interval:forward=* and interval:backward=* can be used on ferries that have different intervals for the two directions.
If the ferry has a fixed departures timetable.
Because this proposal is for ways, forward and backward tags will work well.
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.
- interval=* for describing the time between arrivals at every stop of a public transport route. This key, although not approved, is widely in use in the exact same way as is proposed in this proposal. On ferry routes, this will indicate the time between departures as an alternative to full timetables.
- schedule_type=* Possibly used on ferry ways.
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.