I agree that it would be useful and reasonable to have frequency (headway’s) and the days a route is served.
Here in Indonesia, most local buses do not run on a timetable, but it would be very useful to know if there is one bus a day, one per hour, or one per minute. This makes a huge difference, and can be verified without needing to copy an official timetable, if you know the local routes. Even back in the USA it would be useful and reasonably maintainable to record the frequency of transit vehicles at different times. Something like “Mo-Fr every 30m 5:30-7:00; 10m 7:00-9:00; 15m 9:00 to 15:00; 10m 15:00 to 18:00; 30m 18:00 to 22:00” This gets you most of the information you need to make a good public transit map, because you can have more frequent routes render with wider lines or brighter colors. And it even provides enough info for approximate route planning. In developing countries this would probably be the highest level of detail available. There are no GTFS databases for most of the non-Western world, so it would be useful. Joseph On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert <osm...@michreichert.de> wrote: > TL;DR I am agains this proposal. Timetables in OSM are an ugly hack. > Please store them outside of OSM and link them using foreign keys. > > > Hi Leif, > > Am 31.10.18 um 00:54 schrieb Leif Rasmussen: > > I recently wrote up a proposal page for public transport schedule data. > > This information would allow OpenStreetMap to store information about > when > > or how often certain buses or trains arrive at a platform. > > > > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules > > I think that the frequency and the days a route is served is sufficient. > There should not be any more details about the timetable in OSM beyond > that. While public transport looks simple :-) if you look at urban > areas, it becomes difficult to model if you go to the boundary of urban > areas or even into rural areas or developing countries. > > OSM already struggles to model route relations for bus lines which have > 15 trips per day but 12 different variants (e.g. bus lines in rural > Germany). How do you deal with train lines which run on days matching > the following specification only? > > > nur Fr, So > > auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II., > > 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X. > > nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X. > > > > Fr = Friday > > So = Sunday > > nur … = on … only > > auch … = also on … > > nicht … = not on … > > This specification changes every year and it can't be simplified to "Fr, > Su and public holidays in at least two German states". Currently, many > route relations don't have to be modified every year but your tagging > schema would force mappers to do so. And the example above is quite > simple. In practice, the specification is even longer because many > constructions to refurbish the railway network a running and lead to > different departures nearly every second weekend or trains don't serve > the whole line from start to end because parts of the line are closed on > some weekends/weeks during the year due to constructions. > > How would you deal with lines which have a clear interval of 60 minutes > if you round all depatures and arrival times? There are a lot of train > lines where the times differ by a +-3 minutes through the day. Peak vs. > off-peak is not the reason. > > OSM was designed to be a database for geometries with attributes. The > database design of OSM has some issues but I am sure that database > designed for public transport timetables would not require the timetable > to be encoded into relation membership roles and relation tags. > > Using OSM to encode timetables looks more like a ugly hack and should be > solved by having some kind of foreign key as tag of the route relation > which is used by a separate database project under a free and open > license which is designed for and used to store timetable information. > > Nobody forbids anyone to run a project for crowdsourced timetable > information. But it is out of scope for OSM. > > Your tagging proposal suggests to use relation membership roles to store > depatures in a way like that: > "platform: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" > > Aren't membership roles limited to 256 characters, too? > > In addition, your tagging schema is incompatible with the current public > transport tagging schema and probably all recently discussed proposals > which aim to replace or improve it. All of them know a role "platform". > From my point of view, relation membership roles are keys. Keys should > not contain value information. > > Best regards > > Michael > > > -- > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten > ausgenommen) > I prefer GPG encryption of emails. (does not apply on mailing lists) > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
