[Talk-transit] [Tagging] Public Transport Timetables

djakk djakk djakk.djakk at gmail.com
Tue Nov 6 16:08:42 UTC 2018


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/f7d68b39/attachment-0001.html>


More information about the Talk-transit mailing list