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.shield...@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.dj...@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 <winfi...@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.dj...@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 <winfi...@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.dj...@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.dj...@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.dj...@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 <winfi...@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.dj...@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.dj...@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.dj...@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 <winfi...@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 < >>>>>>>>>>>>> 354...@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 >>>>>>>>>>>>>> tagg...@openstreetmap.org >>>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/tagging >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Tagging mailing list >>>>>>>>>>>>> tagg...@openstreetmap.org >>>>>>>>>>>>> https://lists.openstreetmap.org/listinfo/tagging >>>>>>>>>>>>> >>>>>>>>>>>> > > _______________________________________________ > Talk-transit mailing > listTalk-transit@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-transit > > >
_______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
