Proposal:Public transport schedules/Departures
< Proposal:Public transport schedules(Redirected from Proposed features/Public transport schedules/Departures)
Jump to navigation
Jump to search
| Public Transport Schedules/Departures | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | LeifRasmussen |
| Tagging: | departures=* |
| Applies to: |  
|
| Definition: | Public Transport Schedule data on route relations and ferry ways. |
| Statistics: |
|
| Draft started: | 2019-01-01 |
| Vote start: | 2019-02-13 |
| Vote end: | 2019-03-01 |
Rationale
The recently approved tag interval=<number of minutes between departures at any given stop on the route> provides valuable information about how often buses / trains / ferries / etc. arrive at any given stop along the routes. The tag does not, however, provide information about when buses / trains / etc. arrive. This proposal hopes to allow for a simple way to add this useful information.
This information would, when used on ferries, help navigation software route along ferries. For example, many ferries only run 3 times per day, and anyone who misses a ferry will have a 4-5 hour wait. Adding departures information could allow people to plan their trips more efficiently.
Proposal
This is a much simplified version of the original timetable relations proposal, which would have been very difficult to add / maintain.
This proposal proposes the following:
- The new tag departures=*, to be added to a route relation (not a route master or platforms) for adding a list of departure times from the first stop of a route. When used together with duration=*, it will be possible to accurately calculate the arrival times for any given stop along a route. This should have the same format as collection times, which is a variation of the opening hours syntax.
- The new tag departures:check_date=* for describing when the departures was last verified to be correct.
- departures:forward=*, and departures:backward=*, for use on ferry routes mapped as ways.
Some ferry routes only run a few times per day. Departure data would be very useful in those cases. See this example ferry route for more information.
Advantages/Disadvantages
Advantages
- Allows for very useful information to be added to public transport routes.
- Easier to update than complicated "timetable relations" - this is just one tag.
- Uses existing syntax that is familiar to most OSM contributors.
- Only one or two tags are needed to add this information. This system won't break anything or cause any damage whatsoever to the OSM database.
Disadvantages
- This data (the departure times for the first stop of a route) could become out of date very quickly on some public transport routes. Fortunately, this data will only be stored in a single tag, meaning that it is very easy to remove when out̠ of date.
- The proposed tag departures=* does not provide perfect schedule information, due to an effort to simplify the proposal. When used with the tag duration=*, the exact arrival times for any stop along the route will be possible to calculate with roughly 2 minute accuracy. This means that data consumers may show arrival times that are about 1 - 2 minutes off the actual arrival times.
Examples:
| Situation | Tagging (to add to a route relation) | Explaination |
|---|---|---|
| A bus route with departure times of "Mo-Fr 07:00, 08:30, 10:00, 12:00, 13:30, 15:00" from the first stop and a duration of 44 minutes. |
|
The departures from the first stop along the route are tagged with the same format as collection times. The duration is tagged with the existing tag duration=*. departures:check_date=* can be added to help future mappers know when the departures tag was known to be valid. |
| A subway route that operates 24/7 with a frequency of 10 minutes with no real "timetables", just "every 10 minutes". | Don't use the departures tag for cases like this — use the approved interval=00:10 instead. | Trains arrive every 10 minutes, so adding a full departures list would be difficult and hard to maintain. |
A ferry route mapped as a way that departs Mo-Fr at times:
|
|
The list of departures is added with the existing collection times format in the new tags departures:forward=* & departures:backward=*. |
| A bus route that has a list of departure times of
Mo-Fr 6:20, 6:30, 6:40, 6:55, 7:05, 7:15, 7:30, 7:40, 7:50, 8:05, 8:15, 8:25, 8:40, 8:50, 9:00, 9:15, 9:25, 9:35, 9:50, 10:00, 10:15, 10:35, 10:50, 11:10, 11:45, 12:20, 12:55, 13:30, 13:05, 14:40, 15:15, 15:50, 16:05, 16:15, 16:25, 16:40, 16:50, 17:00, 17:15, 17:25, 17:40, 17:50, 18:00, 18:15, 18:25, 18:50, 19:00 |
departures=Mo-Fr 06:20, 06:30, 06:40, 06:55, 07:05, 07:15, 07:30, 07:40, 07:50, 08:05, 08:15, 08:25, 08:40, 08:50, 09:00, 09:15, 09:25, 09:35, 09:50, 10:00, 10:15, 10:35, 10:50, 11:10, 11:45,
departures_1=Mo-Fr 12:20, 12:55, 13:30, 13:05, 14:40, 15:15, 15:50, 16:05, 16:15, 16:25, 16:40, 16:50, 17:00, 17:15, 17:25, 17:40, 17:50, 18:00, 18:15, 18:25, 18:50, 19:00 |
It is better to use the tag interval=* here, however it is still a possibility to use departures. In order to overcome the 255 char limit, 2 different tags can be usedː departures=* and departures_1=* (basically, just use departures_n=* and replace n with the number being used).
If the 255 char limit is solved in the future, this scheme will no longer be necessary. See this example bus route for details.. |
Overcoming the 255 character limit
If the list of departure times is longer than 255 characters, use the tags departures_1=*, departures_2=*, departures:forward_1=*, departures:forward_2=*, departures:backward_1=*, and departures:backward_2=*. Each additional departures_n=* tag should have a list of times in the same format as the first. See the example above for more information, or check out this example bus route.
The departures tag is not just for bus routes
In fact, it may be discouraged from use in some areas due to very frequently changing schedules. Many bus routes' schedules are changed every few months, making maintaining this information very hard. Some bus routes, however, as well as many ferry routes and railway routes could greatly benefit from this data. Just because some areas wont work with this tag does not mean it should not be possible to add.
Real life examples of the tag departures=*
Discussion
- For discussion about public transport schedules in general (the entire proposal), use Talk:Proposed features/Public transport schedules.
- For discussion about this proposal (the tag departures=*), use this proposal's talk page. Please share your ideas for how to improve this proposal.
Voting results
I approve this proposal. --LeifRasmussen (talk) 16:15, 13 February 2019 (UTC)- I approve this proposal. In the final wiki should not be mentioned departures_1 to avoid confusion. --AgusQui (talk) 22:11, 13 February 2019 (UTC)
- I will keep the departures section out of the main explanation, and instead include it in a section near the bottom of the page. --LeifRasmussen (talk) 16:18, 16 February 2019 (UTC)
- I approve this proposal. I approve this proposal and already use it. However, we need to develop this idea and fully integrate OSM with GTFS, NeTEx and others. --Mazda05 (talk) 16:59, 15 February 2019 (UTC)
- That sounds like a great ideaǃ Another proposal would be necessary for that I think. --LeifRasmussen (talk) 16:18, 16 February 2019 (UTC)
- Yes, most likely, not just one proposal. Although there are lazy people in the community who, on the basis of a number of prejudices, protest against the schedules in OSM, I believe that they cannot assert their position except being lazy to update information and correct their own mistakes. As for schedules - the available tools are not enough to describe them as accurately as possible. And until these tools are available, some people will shout that they are too lazy to fill out information about schedules, and others that the schedule with such tags is incorrect. This is not a reason to block the proposal and develop the tagging of public transport. As for the frequent proposals not to make schedules in the OSM, but to use the route binding to GTFS data - this contributes to the monopoly of the “evil” corporation and ignores alternative sources such as NeTEx, SIRI, TransXChange and others. Integration should be, but not exclusively with GTFS or based on GTFS. In addition, the data of these systems are not comprehensive and are mainly available only in the largest cities of the world (with the exception of the USA).--Mazda05 (talk) 19:37, 16 February 2019 (UTC)
I oppose this proposal. I do not see any benefit for OSM. It is so difficult to keep public transport data up to date. EDIT: The connection with a departure monitor (website / QR code) is in my opinion more useful. https://www.openstreetmap.org/node/4703803199 --Geri-oc (talk) 16:34, 16 February 2019 (UTC)- I approve this proposal. --Dr Centerline (talk) 16:49, 16 February 2019 (UTC)
- I oppose this proposal. This violates the principle not to map temporal and seasonal features. Such timetables are due to change every half a year or so, and editing/checking it for every stop on a line is extremely error-prone. --Polarbear w (talk) 19:18, 16 February 2019 (UTC)
- By the way, this tag will only be used on route relations, and not on every stop, meaning that editing it for every stop would not be necessary. Also, adding timetables to routes that change every six months would not be a good idea, and would not be encouraged by any future wiki page. --LeifRasmussen (talk) 23ː14, 16 February 2019 (UTC)
- I oppose this proposal. and we need to rethink whether OpenStreetMap really is the right database to add public transport information that goes beyond the infrastructure on the ground (tracks, bus stops etc.) Just the fact that this proposal "proudly" claims to break the 255-character limit on k=v pairs shows that this information cannot be appropriately conveyed by the OSM database which was originally meant for geographic information and not for public transport schedules. Fact is, we're going nowhere with PTv2, no external reuser of OSM data can do anything useful with PTv2 and what we are doing is just a huge waste of time. The Google way, importing bus schedules externally and linking them to OSM objects with the appropriate tags to calculate a trip from stop to stop, seems a lot more worthwhile in the long run. -- Prince Kassad (talk) 22:26, 16 February 2019 (UTC)
- I oppose this proposal. Useless data because there is no guaranty that the data is always uptodate -- chris66
- I oppose this proposal. Sorry, but to tag PT departures or timetables is a level of details that is not achievable to be maintained up-to-date. Introducing tags for data that are very quick outdated is bad data quality by design. Rather tag a link to the operator's timetable or the QR code, if available or the UIC ref of the PT stop. Today ther are much better ways to retrieve departure times at a PT than by design outdated data in OSM. A clear no from my side. --Rainero (talk) 10:42, 17 February 2019 (UTC)
- I approve this proposal. --Santamariense (talk) 11:21, 17 February 2019 (UTC)
- I oppose this proposal. I am against mapping this level of detail, there's no way it can be kept current at least in my country where changes are frequent. The idea of using departures_x to overcome size limits shows how this kind of data is not a good match for OSM. Additionally it will lead to import orgies by people in areas where timetable information is public. Don't even start. --Woodpeck (talk) 13:26, 17 February 2019 (UTC)
- I oppose this proposal. Many bus routes have yet to be mapped. Some bus routes that have been mapped were replaced by different services with different routes many years ago but have yet to be corrected. I very much doubt we could ever keep timetable information up to date if we can't even keep the routes up to date. OSM is the wrong database for this. What we need is a tag to link to GTFS feeds where available (something other than url=* which may be needed for another purpose). Not all routes have GTFS feeds but there are several GTFS servers which permit members of the public to create a feed for a bus route where the operator of that route has yet to do so (and the operator can later take it over and maintain it). Failing that, just tag a link to the operator's online timetable (again, it would be better to have a specific tag rather than use url=*). --Brian de Ford (talk) 14:18, 17 February 2019 (UTC)
- I oppose this proposal. This is not the kind of data that should be in the OSM database. 1) It's volatile, changing several times a year. 2) In many places this data is not available under a ODbL compatible license. 3) OSM data structure doesn't support this huge amount of data (see 'departures_2'). 4) Adding only the time of departure at the first stop doesn't help at all. Buses regularly take different amounts of time between stops at different times of the day and sometimes stop for many minutes to wait for connections to other services. Instead, references to actual public transit databases should be established. These are exactly made for this kind of data and are kept up-to-date by the operators. --Mueschel (talk) 14:40, 17 February 2019 (UTC)
- I oppose this proposal. I fear this tag only appears sleek at first sight. I think Mueschel sums it up well. The up-to-date schedules should rather be linked to than copied Westnordost (talk) 14:47, 17 February 2019 (UTC)
- I oppose this proposal. The chapter "Overcoming the 255 character limit" should set off alarm bells that this kind of data may not be suitable for the OSM data model. Mmd (talk) 15:59, 17 February 2019 (UTC)
- I oppose this proposal. For the same reasons as Mueschel. However, i were fine to store departures of car ferries if they change less than once every few years and fit into our 255 character limit. –SelfishSeahorse (talk) 16:08, 17 February 2019 (UTC)
- I oppose this proposal. Sorry, but I must also vote no, as it is way to complicated to try to maintain. I can see that it would good for some situations, such as the examples shown above, when there are only a handful of trips (maybe max 10?) per day, but for "normal" busy routes, then it will just bog down. --Fizzie41 (talk) 21:32, 17 February 2019 (UTC)
I have comments but abstain from voting on this proposal. Was using the half-long IPA mark (w:en:vowel length#IPA) for the forward/backward affixes intentional? Arlo James Barnes (talk) 00:08, 18 February 2019 (UTC)
- I approve this proposal. I would also like to see something that allows a link to a file following the General Transit Feed Specification format, specifically so that departure information can be quickly updated (assuming that the GTFS is under a compatible license), e.g. `departure:gtfs="https://example.org/gtfs.zip"` or something similar that allows for other transit specifications --Vorpalblade77-kaart (talk) 15:25, 20 February 2019 (UTC)
- I approve this proposal. While the change in schedules for public transit may become cumbersome, at this time the benefit outweighs the downside. Particularly for ferries, but potentially for other modes of public transit as well. Tourism stands to benefit significantly over the long run. --Unicorn Ostrich (talk) 15:03, 18 February 2019 (UTC)
- I oppose this proposal. These values will go obsolete very quickly, and the proposal does not cover complex cases, which happen quite often. This should be done with an outside database. --Zverik (talk) 11:10, 19 February 2019 (UTC)
- I approve this proposal. Though I don’t like the idea, we can give it a try and see if it dies itself or not :-) --Felis Pimeja (talk) 16:33, 19 February 2019 (UTC)
- I approve this proposal. This is important for apps to use PT routing based solely on OSM data. Many voters seem to be ignorant of the situation in other countries. Namely -
1. They suggest external data sources, not realizing that these may be non-existent (there is no freely licensed PT data for Delhi, and I'd rather spend time mapping and expanding the community than convincing government agencies), and they don't permit ground users to take part in improving them.
2. They complain of data changing too often - the answer is "expand the local mapper community" and "maybe don't use it in such areas, but don't prevent other areas from using it (e.g. I'm pretty sure Delhi bus routes and timings haven't changed in years)." Going by this logic, shops change very often too, and are very often out of date in Delhi (due to a nearly non-existent mapping community) - should we not map them either? -- Contrapunctus (talk) 19:36, 19 February 2019 (UTC)
I would like to express a degree of incredulity at this proposal. Richard (talk) 18:18, 20 February 2019 (UTC)
- I approve this proposal. Thanks for the proposal. I support it because particularly in rural and less developed areas, PT timetables are often not even published at stops but simply of local knowledge. It's useful to have a way of introducing this data into OSM. Still, given the rather high volatility of PT timetables, the final goal should be some sort of automatic import of timetable data from the service provider (not just linking to the corresponding data source, because this doesn't help if you don't have internet, e.g. when being abroad). --Grimpeur78 (talk) 20:00, 24 February 2019 (UTC)
- I approve this proposal. While the concern about this being hard to keep current are valid, the same could be said about any aspect of public transportation in OSM. There here are many transportation systems do not have published schedules and OSM may be one of the few sources to organize and catalog this data. --Mds08011 (talk) 21:10, 24 February 2019 (UTC)
- I oppose this proposal. Too hard to keep up-to-date. Changes too often. --Rmikke (talk) 23:06, 24 February 2019 (UTC)
- I oppose this proposal. Not the right place for this topic. --geozeisig (talk) 08:00, 25 February 2019 (UTC)
- I oppose this proposal. It is already very hard to keep opening hours for restaurants and shops up-to-date. Keeping departure times up-to-date will be impossible except with an automated approach, in which case the same automation could be used to add this data in a later step during data consumption. --scai (talk) 13:42, 25 February 2019 (UTC)
- I oppose this proposal. Maintenance will be almost impossible. I think global timetable data is a project separate to OSM --TonyS (talk) 21:13, 25 February 2019 (UTC)
- I oppose this proposal. I work in the public transport sector and can tell you that this is a bad idea. At least in Europe timetables change (at least) every year. --Amilopowers (talk) 21:16, 25 February 2019 (UTC)
- I oppose this proposal. This is not the kind of data that should be in the OSM database. 1) It's volatile, changing several times a year. 2) In many places this data is not available under a ODbL compatible license. 3) OSM data structure doesn't support this huge amount of data (see 'departures_2'). 4) Adding only the time of departure at the first stop doesn't help at all. Buses regularly take different amounts of time between stops at different times of the day and sometimes stop for many minutes to wait for connections to other services. Instead, references to actual public transit databases should be established. These are exactly made for this kind of data and are kept up-to-date by the operators. (Yes, that's a copy-paste job from another user's vote, which I totally agree with!) --smz (talk) 00:29, 26 February 2019 (UTC)
- I oppose this proposal. In my opinion this data should be fetched by the data comsumers using the API of the transport operators. We should not include this data in OSM. --Zartbitter (talk) 08:00, 26 February 2019 (UTC
- I oppose this proposal. Too hard to keep up-to-date. Currently even keeping routes up to date is generally not manageable. Updating requires significantly more effort than for opening hours (see "Overcoming the 255 character limit") and typically changes more often. --Mateusz Konieczny (talk) 11:00, 26 February 2019 (UTC)
- I have comments but abstain from voting on this proposal. Thanks for thinking about this, and for creating the proposal. I support parts of it and would like to see it simplified and brought for a new vote (much like railway=separately_mapped became embedded_rails), but can't support the whole thing:
- I wish the proposal simply said "if the list of departures exceeds 255 characters, it is too complex to include in OpenStreetMap". That would have covered the "five bus departures a day" and "4 hour ferry wait" problems without getting into messy situations.
- Anything more frequent than half an hour or more than 10 trips a day should probably be done with interval instead. I would have preferred to see the bus route example with departures_1 implemented by estimating it with interval and interval:conditional for different time periods.
- And if you have schedules so precise or detailed that estimating departures with interval or varying travel time between stops creates accuracy problems, it's time to use a more suitable format. It'd be easier to crowd-source and crowd-publish a GTFS feed than to stuff every departure into OSM. Anyone can use a public, freely licensed GTFS feed and many different public transit routers do.
- I don't see getting out of date as an issue. Yeah, schedules change. But so do stores, or their opening hours, and we still have those. This is a matter of tooling: have tools that check when a tag was last updated, check for a check_date tag, and produce a list of items to verify when it gets too old. --Jarek Piórkowski (talk) 18:33, 26 February 2019 (UTC)
- I have comments but abstain from voting on this proposal. I agree with Jarek above.
- I like that you put in a possibility for us to mark the last update. If this proposal is approved then I think we should make a validation rule rendering use of departure=* without departures:check_date=* an error. These dates enables data-consumers to easily add confidence-level-indicators to the routes they plan.
- I liked the argument from above about Delhi. There seem to be a need now for simple route planning and while we work on the side creating central open databases with data.--PangoSE (talk) 12:18, 28 February 2019 (UTC)