[Talk-transit] [Tagging] Public Transport Timetables

Wed Nov 7 12:41:16 UTC 2018

Hello !

Ok for a google hangout ! I’m also available tonight and on Friday evening.

Julien « djakk »

Le mer. 7 nov. 2018 à 12:53, Jo <winfixit at gmail.com> a écrit :

> Hi Tony,
>
> Could you also have a look at the proposal I created?
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> At the moment I'm looking into how to represent that in meaningful ways
> using MapCSS in JOSM, but I don't think that makes too much sense.
>
> For your use case where you want to do routing. The timetable relations
> give the possibility to calculate when a bus passes at a particular stop at
> a given time of day. And it's possible to see how long it takes to get from
> there to another stop or calculate at what time one arrives there. For
> complex routing involving transfers this will involve quite a bit of
> recursion, but it should be feasible.
>
> At the moment I'm looking how this can be rendered in meaningful ways and
> how data entry can be made as convenient as possible. (I think we need
> spreadsheet like functionality to accomplish that, I made an attempt here:
> https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
> .
> But we need more possibilities for indicating where a specific time on the
> schedule came from.
>
> Right now I have the following:
>
> Line (route_master relation)
>    contains several:
>      Itineraries composes of (longest) stop sequences including ways
> (route relation)
>         if referred to by 1 or more
>            Actual stop sequences with time deltas (timetable relation)
>                The stops in these relations are always a subset of the
> referre route relation
>
> I would also include a public_holidays relation in each route_master
> relation to avoid duplication but still enable which days get Sunday
> schedules and which days are in school holiday periods.
>
>
> If anyone feels like doing a Google Hangout to discuss this, let me know.
> I have time tonight and Friday evening
>
> Polyglot
>
> Op wo 7 nov. 2018 om 12:24 schreef Tony Shield <tony.shield999 at gmail.com>:
>
>> Hi
>>
>> I have worked in data analysis for many years, recently become interested
>> in PT and added routes to my locality. I look at PT timetables frequently
>> as much of my travel is by PT.
>>
>> My use case is that I want to find times and routes from A to B, I do not
>> know the route numbers or their actual route. I expect the system to be
>> able to give times and routes and any interchanges.
>>
>> As a system I fail to see how putting the timing detail on each stop will
>> enable me to efficiently perform that use case. From what is described
>> system would have to identify route, then iterate route to check if
>> destination is on route, if on route then  select time entry in A then a
>> time entry in B and ASSUME that they both relate to the same journey and
>> have been updated correctly. For connections/interchanges the same rules
>> apply. Those assumptions make storing the data against a stop
>> extraordinarily unreliable, the proposed method does not take shortened
>> journeys - eg school or factory journeys where the whole route is not
>> travelled  - into account.
>>
>> I suggest that the best way to get timetable data is to replicate the
>> present system that most PT organisations do - a table related to the
>> route. A timetable could be associated with an OSM route. A system will be
>> required to generate meaningful times and itineraries, so should we be
>> asking those existing OSM routing people what  is their preferred way to
>> store timetable data that can be updated reliably.
>>
>> Here in the UK timetable data is in the public domain - is that the case
>> in other places?
>>
>> TonyS
>>
>>
>>
>> On 06/11/2018 19:59, Jo wrote:
>>
>> Indeed, a mapper who wants to add this and who can't find the information
>> on the internet or in a booklet, would have travel to the first stop, take
>> note of all the departure times and then establish the deltas between all
>> the stops of the itinerary.
>> If that's the case, such a mapper would probably better use the tags
>> based method on the route relations.
>>
>> It all depends on how much detail you want to add (and maintain in the
>> long run).
>>
>> Another weakness of the relation pet stop/route pair method is that it
>> will be very hard to encode the exceptions; not on Wednesdays, only on
>> Fridays, etc.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 20:22 schreef djakk djakk <djakk.djakk at gmail.com>:
>>
>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
>> _______________________________________________
>> Talk-transit mailing listTalk-transit at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20181107/6aa3f3b9/attachment-0001.html>