Proposed features/Public transport schedules/Interval
|Public Transport Schedules|
|Definition:||Public Transport Schedule data on route relations and ferry ways.|
While full schedule data could be very useful in OpenStreetMap, it comes with a very large cost. Maintenance, complexity, and other issues make adding exact departure times very difficult. Adding an interval, however, has none of these disadvantages. It would allow for data consumers to show more information about, for example, a bus route stopping at a stop. Rather than just showing that the bus stops at the stop, the information "every 10 minutes" could be displayed. This information could also be useful for consumers interested in the importance of a railway route or bus route. A bus that runs every 3 minutes is much more "important" than one running every other hour.
- Allows for very useful information to be added to public transport routes.
- Easy to update
- 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.
- It may be hard to know whether the information is still up to date. Unlike full timetables, however, arrival frequencies (intervals) don't change very often, so this will be only a very minor issue.
This is a simplified version of Proposed features/Interval, which was previously proposed, but never voted on. This proposal was independently created without the knowledge of the other proposal's existence.
This proposal proposes adding the tag interval=<number of minutes between departures at any given stop on the route> to state how frequently buses, trains, ferries, trams, or others run on a certain line. It also proposes the use of the tag interval:conditional=* to describe differing frequencies, or arrival intervals, during different times of day.
|A bus route that operates from 08ː00 to 18ː00, Mo-Fr with an interval of 10 minutes in the mornings and 20 minutes in the middle of the day.||interval=00ː10,
interval:conditional=00ː20 @ Mo-Fr 10ː00-16ː00,
|The main interval is 00ː10 minutes, with reduced service from 10ː00-16ː00. The normal opening hours are expressed with the existing tag opening_hours=*. Note that the conditional tag overwrites the interval tag.|
|A subway route that operates 24/7 with a frequency of 5 minutes during rush hour, 15 minutes during the day, and 30 minutes at night.||interval=00ː05,
interval:conditional=00ː15 @ Mo-Su 10ː30-16ː30; 00ː30 @ Mo-Su 19ː30-06ː30,
|The main frequency of the subway is 5 minutes (interval=00ː05), with exceptions between 10ː30 and 16ː30 and between 19ː30 and 06ː30. This leaves the interval at 00ː05 during 06ː30-10ː30 and 16ː30-19ː30.
|A ferry route that operates hourly from 07ː00 to 19ː00 every day.||interval=01ː00,
|The interval is 01ː00 during the day with opening hours of 07ː00-19ː00.|
This is only for the interval tag. Other proposed features, including timetable relations and ferry route schedules will be voted on separately in the near future.
- I approve this proposal. -- Let's make it clear that these tags are to be used in places where there is no other public source of data Smaffulli (talk) 22:52, 15 December 2018 (UTC)
- I approve this proposal. -- I agree that this will be quite helpful in the many towns and whole countries without published timetables, and it would be useful for rendering public transit maps that show the more frequent buses prominently. --Jeisenbe (talk) 04:33, 16 December 2018 (UTC)
- I oppose this proposal. beside of rendering the "importance" of a route, I don't see any sense in this key. An interval of 1 or 2 hours (normal interval for a bus in my area) without a exact time is ... useless. And for a sub with 5min frequency I don't need an app! --Waldhans (talk) 21:42, 16 December 2018 (UTC)
- I approve this proposal. good simplification over previous proposal. Thank you Fanfouer (talk) 00:49, 17 December 2018 (UTC)
- I approve this proposal. This is the beginning of what the careful and thoughtful development of a tag system looks like --Arlo James Barnes (talk) 00:58, 17 December 2018 (UTC)
- I approve this proposal. I feel very usefull to indicate if a night bus is roughly coming every 5 mn or every hour. --Zorglubu (talk) 12:44, 20 December 2018 (UTC)
- I have comments but abstain from voting on this proposal. --Polyglot (talk) 13:29, 20 December 2018 (UTC) I added some comments and questions on the talk page which weren't responded to.
- I have comments but abstain from voting on this proposal. I like the idea of the proposal, I find it very useful, in fact I use the original proposal. However, I do not understand why the 00:00 format is used, it seems unnecessarily complicated and too exact, I do not think it's the idea. On the other hand I do not find it comfortable to use on routes with long intervals like 2 times per week, interval = 84: 00 ?, 2_per_week of the original proposal is easier. And why do not we improve the original proposal that was not voted on? --AgusQui (talk) 03:51, 21 December 2018 (UTC)
- I approve this proposal. I like this proposal - they can be used for small (city)-shuttle services in Belgium too. However, it should still be clearly stated that these are not replacement for more advanced tables. A text should still be added which says something like "If a GTFS-feed or link to the operators website with timetables is available, these should be added instead." Pietervdvn (talk) 14:05, 21 December 2018 (UTC)
- I oppose this proposal. Far from all public transport networks run on a fixed frequency, making this tagging scheme useless on many occasions. --TangoEast (talk) 16:19, 21 December 2018 (UTC)
- I have comments but abstain from voting on this proposal. For the same reasons as Waldhans. --SelfishSeahorse (talk) 17:31, 21 December 2018 (UTC)
- I oppose this proposal. to difficult to stay update, useless when there is an internet service whith timetables Mga geo (talk) 07:04, 22 December 2018 (UTC)
- I have comments but abstain from voting on this proposal. It would be better to link to a GTFS, as this standard is more precise to reflect reality than this proposal. If there is no official GTFS, an unofficial one may be created and maintained by the users, maybe even hosted on a OSMF server if needed. The needed GTFS's could be attached to .osm/.pbf files to be used by offline apps. Kresp0 (talk) 09:37, 22 December 2018 (UTC)
- I approve this proposal. --User:manfredbrandl (User talk:Manfred Brandl) 13:35, 22 December 2018 (UTC)
- I approve this proposal. Singing-Poppy (talk) 17:13, 22 December 2018 (UTC)
- I approve this proposal. --Gendy54 (talk) 22:30, 22 December 2018 (UTC)
- I approve this proposal. --EneaSuper (talk) 09:46, 23 December 2018 (UTC)
- I approve this proposal. This is a good way to get approximate information about the schedule of services. Compared to precise timetable information (which I don't like to see in OSM), this is a simple scheme and doesn't change too often. --Mueschel (talk) 10:08, 24 December 2018 (UTC)
- I approve this proposal. I have some comments (see the discussion page) --Djakk (talk) 10:59, 24 December 2018
- I approve this proposal. --Overflorian (talk) 12:24, 24 December 2018 (UTC)
- I approve this proposal. --JB (talk) 12:39, 24 December 2018 (UTC)
- I approve this proposal. Useful --Enock4seth (talk) 16:29, 24 December 2018 (UTC)
Please use the talk page for discussions about the interval tag and its use. Use the main proposal talk page for discussion regarding the entire proposal.
While the proposal accidentally uses a special phonetics character 'ː', this was fixed in the feature page. Use the regular colon ':' instead.