[Tagging] Public Transport Timetables

djakk djakk djakk.djakk at gmail.com
Tue Nov 6 20:00:10 UTC 2018


:)

Le mar. 6 nov. 2018 à 20:55, Yves <yvecai at mailbox.org> a écrit :

> Are you looking for a general transit feed specification?
> :)
>
> Yves
>
> Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk <djakk.djakk at gmail.com>
> a écrit :
>>
>> 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/8c368b83/attachment.html>


More information about the Tagging mailing list