[Tagging] Public Transport Timetables Proposal RFC

Wed Oct 31 11:28:07 UTC 2018

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 <joseph.eisenberg at gmail.com> 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 <osm-ml at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181031/a46adf7c/attachment-0001.html>