[Talk-transit] [Tagging] Public Transport Timetables

Jo winfixit at gmail.com
Tue Nov 6 18:27:41 UTC 2018


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/talk-transit/attachments/20181106/1b092f3f/attachment.html>


More information about the Talk-transit mailing list