I agree that it would be useful and reasonable to have frequency (headway’s) and the days a route is served.<br><br>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.<br><br>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” <br><br>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.<br><br>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.<br><br>Joseph<br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert <<a href="mailto:osm-ml@michreichert.de">osm-ml@michreichert.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.<br>
Please store them outside of OSM and link them using foreign keys.<br>
<br>
<br>
Hi Leif,<br>
<br>
Am 31.10.18 um 00:54 schrieb Leif Rasmussen:<br>
> I recently wrote up a proposal page for public transport schedule data.<br>
> This information would allow OpenStreetMap to store information about when<br>
> or how often certain buses or trains arrive at a platform.<br>
> <br>
> <a href="https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules" rel="noreferrer" target="_blank">https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules</a><br>
<br>
I think that the frequency and the days a route is served is sufficient.<br>
There should not be any more details about the timetable in OSM beyond<br>
that. While public transport looks simple :-) if you look at urban<br>
areas, it becomes difficult to model if you go to the boundary of urban<br>
areas or even into rural areas or developing countries.<br>
<br>
OSM already struggles to model route relations for bus lines which have<br>
15 trips per day but 12 different variants (e.g. bus lines in rural<br>
Germany). How do you deal with train lines which run on days matching<br>
the following specification only?<br>
<br>
> nur Fr, So<br>
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,<br>
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., <a href="http://11.VI" rel="noreferrer" target="_blank">11.VI</a>., 2.X., 30.X.<br>
> nicht 21.IV., 31.V., <a href="http://1.VI" rel="noreferrer" target="_blank">1.VI</a>., <a href="http://9.VI" rel="noreferrer" target="_blank">9.VI</a>., <a href="http://21.VI" rel="noreferrer" target="_blank">21.VI</a>., 4.X.<br>
><br>
> Fr = Friday<br>
> So = Sunday<br>
> nur … = on … only<br>
> auch … = also on …<br>
> nicht … = not on …<br>
<br>
This specification changes every year and it can't be simplified to "Fr,<br>
Su and public holidays in at least two German states". Currently, many<br>
route relations don't have to be modified every year but your tagging<br>
schema would force mappers to do so. And the example above is quite<br>
simple. In practice, the specification is even longer because many<br>
constructions to refurbish the railway network a running and lead to<br>
different departures nearly every second weekend or trains don't serve<br>
the whole line from start to end because parts of the line are closed on<br>
some weekends/weeks during the year due to constructions.<br>
<br>
How would you deal with lines which have a clear interval of 60 minutes<br>
if you round all depatures and arrival times? There are a lot of train<br>
lines where the times differ by a +-3 minutes through the day. Peak vs.<br>
off-peak is not the reason.<br>
<br>
OSM was designed to be a database for geometries with attributes. The<br>
database design of OSM has some issues but I am sure that database<br>
designed for public transport timetables would not require the timetable<br>
to be encoded into relation membership roles and relation tags.<br>
<br>
Using OSM to encode timetables looks more like a ugly hack and should be<br>
solved by having some kind of foreign key as tag of the route relation<br>
which is used by a separate database project under a free and open<br>
license which is designed for and used to store timetable information.<br>
<br>
Nobody forbids anyone to run a project for crowdsourced timetable<br>
information. But it is out of scope for OSM.<br>
<br>
Your tagging proposal suggests to use relation membership roles to store<br>
depatures in a way like that:<br>
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,<br>
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"<br>
<br>
Aren't membership roles limited to 256 characters, too?<br>
<br>
In addition, your tagging schema is incompatible with the current public<br>
transport tagging schema and probably all recently discussed proposals<br>
which aim to replace or improve it. All of them know a role "platform".<br>
>From my point of view, relation membership roles are keys. Keys should<br>
not contain value information.<br>
<br>
Best regards<br>
<br>
Michael<br>
<br>
<br>
-- <br>
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten<br>
ausgenommen)<br>
I prefer GPG encryption of emails. (does not apply on mailing lists)<br>
<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>