That’s true even in parts of the developed world. It would be useful! Sent from my iPhone
> On Oct 31, 2018, at 4:18 PM, Joseph Eisenberg <[email protected]> > wrote: > > 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 <[email protected]> >> 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 >> [email protected] >> https://lists.openstreetmap.org/listinfo/tagging > _______________________________________________ > Tagging mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
