[Tagging] Public Transport Timetables Proposal RFC
osm-ml at michreichert.de
Wed Oct 31 10:02:49 UTC 2018
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.
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.
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.
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
I prefer GPG encryption of emails. (does not apply on mailing lists)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Tagging