[Tagging] Public Transport Timetables Proposal RFC
mailinglists at iivq.net
Wed Oct 31 21:50:52 UTC 2018
> Thanks for the feedback on this proposal! Maintainability and corruption
> of existing features seem to be the two biggest concerns, both of which I
> have reduced in the new version of the proposal. I really like the idea
> that Polyglot expressed on the talk page of the proposal of using a
> completely separate relation to represent a single timetable. It is a
> completely different system that is much more elegant, versatile,
> practical, and simple. By using a relation similar in design to turn
> restrictions, the complexity of this proposal has been reduced
> The new version of the proposal will not affect existing public transport
> routes in any way or form. They will remain unchanged and uncorrupted,
> similarly to how turn restrictions do not affect highways in any
> way. Data consumers will not have to worry about any changes to public
> transport details.
As others, I strongly oppose having public transport timetables in OS
Maintainability and doubling of data are the main problems. Any data
consumer that could do something with this, could just as well source
their data from a GTFS or similar feed. I heard one commenter say he/she
hoped PT companies would add their data to OSM - I think they far earlier
would invest into having their data automatically exported into GTFS (or
another open data format, such as BISON in the Netherlands)
Another drawback is that many lines would very quickly hit the
256-character value limit. I work in public transit, and many of "my"
lines have 50 trips per direction per day (but 220 is no exception) all
leaving at slightly different minutes of the hour and having slightly
different travel times. Things aren't so simple anymore that we have a
peak, off-peak and evening/sunday service pattern, and I think you grossly
underestimate the complexity of PT timetabling.
In my view, Openstreetmap is a geographical database and in my view this
is too far from geographical data to be a valuable OSM addition.
I see one exception where timetables could be useful and valuable
addition: anywhere where a "portage" function exists, where another mode
piggybacks on a timetabled transport: Cars on ferries or train shuttles,
bicycles on public elevators, walkers on funiculars etc.
These usually have a very predictable route and timetable structure
(exceptions off course apply)
•between two nodes without intermediate stops
•Fixed start and finish times based on day and period of year
(=opening_hours, may be different per direction)
•Fixed going tmes (e.g. :20 from point a, :50 from b) ór fixed headways
(every 15 minutes)
•Very predictable transit times (e.g. always 20 minutes)
•Usually quite distinct in their use and operation from "traditional"
public transit like buses or ferries
In this way, a data consumer can make a prediction of say, an ETA of a
route that uses a ferry with tags that are not much more complicated than
an opening_hours tag.
Just my 2 cents,
More information about the Tagging