> 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 > significantly. > > 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 > noticeable > way. Data consumers will not have to worry about any changes to public > transport details. > > https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
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, Tijmen/IIVQ _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
