[Tagging] Public Transport Timetables

djakk djakk djakk.djakk at gmail.com
Tue Nov 6 19:22:18 UTC 2018


Ok I see.

I am still a bit reluctant to your proposal since the travelling time
between 2 stops can vary during the day, especially for train routes.
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with
your proposal (it needs to know the timetable for the whole line), we’ll
depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo <winfixit at gmail.com> a écrit :

> Yes, very hard to debug and we already established some change every few
> months. So after a change from the operator. One traveler will update one
> of those schedules, Another may do so for 3 stops down the line, in the
> mean time the stops in between and after are not updated yet. A maintenance
> nightmare. The way I proposed it, suffers less from that problem. When
> timetables change it's usually that trips are added or removed or their
> start time changes slightly. The time to get from one stop to the next will
> remain constant, most of the time.
>
> Jo
>
> Op di 6 nov. 2018 om 18:40 schreef djakk djakk <djakk.djakk at gmail.com>:
>
>> I don’t get it ...
>>
>> With my point of view, one route with 15 stops has 15 timetables, each
>> timetable describes the arrival time and the departure time of several
>> trips at the stop.
>>
>> There must be the same number of trips along the stops’ timetables.
>> (Otherwise this is an other route).
>>
>> You mean, if somebody messed up and add an extra trip inside a timetable,
>> this would be hard to figure ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 18:30, Jo <winfixit at gmail.com> a écrit :
>>
>>> If you have a single one for a stop/route pair, no problem. As soon as
>>> you have a few hundred and the information in them starts to conflict with
>>> other another timetable relation for the same route it will be extremely
>>> hard to figure out where it went wrong.
>>>
>>> Polyglot
>>>
>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk <djakk.djakk at gmail.com>:
>>>
>>>> In which case a timetable per stop and per route is unmaintable ?
>>>>
>>>> Julien “djakk”
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk <djakk.djakk at gmail.com> a
>>>> écrit :
>>>>
>>>>> I think it is important to have an osm object describing the timetable
>>>>> user-oriented for simple editing without any tool.
>>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>>> import it later in osm without the need of any extra tool.
>>>>> Validator can be inside a tool.
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk <djakk.djakk at gmail.com> a
>>>>> écrit :
>>>>>
>>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>>> timetable, the user have to refer to the closest previous bus stop having
>>>>>> an official timetable. So this kind of bus stop may not have a timetable in
>>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>>> habits the schedule).
>>>>>>
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:28, Jo <winfixit at gmail.com> a écrit :
>>>>>>
>>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>>> relations! It seems to me that it would be a nighmare to try and maintain
>>>>>>> it that way. At first sight it seems simpler, but with the new proposal i
>>>>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>>>>> together.
>>>>>>>
>>>>>>> If the vehicle remains in the station longer, the roles could become
>>>>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>>>>> the vehicle left at its first stop.
>>>>>>>
>>>>>>> Seeing the stops in the timetable relation in the order they are
>>>>>>> served also enables comparing this with the stops sequence in the route
>>>>>>> relation they refer to, adding additional possibilities for validation of
>>>>>>> the data.
>>>>>>>
>>>>>>> The stops in a timetable sequence should always be a subset of the
>>>>>>> stops in a route relation and appear in the same order.
>>>>>>>
>>>>>>> Polyglot
>>>>>>>
>>>>>>>
>>>>>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk <
>>>>>>> djakk.djakk at gmail.com>:
>>>>>>>
>>>>>>>> I’ll agree with Leif, having a timetable relation per stop is
>>>>>>>> better.
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>>>>>> arrival-departure pair of time.
>>>>>>>>
>>>>>>>> Julien « djakk »
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk <djakk.djakk at gmail.com> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> In order to reduce the length of the value of the departures= tag,
>>>>>>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>>>>>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>>>>>>
>>>>>>>>> Julien « djakk »
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk <djakk.djakk at gmail.com>
>>>>>>>>> a écrit :
>>>>>>>>>
>>>>>>>>>> Martin, maybe locals do know their bus stop timetable, as they
>>>>>>>>>> always use the service they may memorize the schedules ... ?
>>>>>>>>>>
>>>>>>>>>> Julien
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le lun. 5 nov. 2018 à 17:08, Jo <winfixit at gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> Hi Leif,
>>>>>>>>>>>
>>>>>>>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>>>>>>>> creating a new one. It differs in rather important ways from your proposal,
>>>>>>>>>>> so I preferred not modifying your wiki page. I also think it's important to
>>>>>>>>>>> decouple the (voting for a) full timetable solution from the solution where
>>>>>>>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>>>>>>>> which is a lot more likely to be accepted.
>>>>>>>>>>>
>>>>>>>>>>> So here goes:
>>>>>>>>>>>
>>>>>>>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>>>>>>>>
>>>>>>>>>>> Please let me know what you think. What I still haven't figured
>>>>>>>>>>> out yet is how to differ weekdays that fall in school holiday periods from
>>>>>>>>>>> "normal" weekdays. So work in progress.
>>>>>>>>>>>
>>>>>>>>>>> Polyglot
>>>>>>>>>>>
>>>>>>>>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <
>>>>>>>>>>> 354lbr at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Polyglot:
>>>>>>>>>>>>
>>>>>>>>>>> I think that having a timetable relation for each stop is less
>>>>>>>>>>>> complicated than having one per route.  There are several advantages to
>>>>>>>>>>>> this:
>>>>>>>>>>>> 1) People can easily add a single relation at a time, rather
>>>>>>>>>>>> than having to do the entire line at one time.  This could make it much
>>>>>>>>>>>> easier to, for example, have a StreetComplete quest asking "What are the
>>>>>>>>>>>> arrival times of bus X at this bus stop?"  iD could also have a field at
>>>>>>>>>>>> bus stops with "arrivals for each parent bus route" that would allow people
>>>>>>>>>>>> to seamlessly create timetable relations.  It also makes more features
>>>>>>>>>>>> possible in the future, such as additional tags to each timetable.
>>>>>>>>>>>> 2) The system is easier for newbies to learn to use.
>>>>>>>>>>>>
>>>>>>>>>>>> The disadvantage is that there are now a ton of relations per
>>>>>>>>>>>> bus / train / subway route.  Creating these could made easier by a new JOSM
>>>>>>>>>>>> plugin.  Also, if someone wanted to delete all timetable relations that are
>>>>>>>>>>>> part of a route, they could simply use this overpass query to download the
>>>>>>>>>>>> data into JOSM and then delete all of the timetable relations:
>>>>>>>>>>>> https://overpass-turbo.eu/s/Dlf
>>>>>>>>>>>>
>>>>>>>>>>>> If people really prefer a single timetable relation for each
>>>>>>>>>>>> route, then I will go with that.
>>>>>>>>>>>>
>>>>>>>>>>>> Julien:
>>>>>>>>>>>> Why not have a "delay"="<amount of time between arrival and
>>>>>>>>>>>> departure at this platform>" tag instead of separate arrivals/departures
>>>>>>>>>>>> tags?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Leif Rasmussen
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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/20181106/5112fb56/attachment-0001.html>


More information about the Tagging mailing list