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 list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
