:) Le mar. 6 nov. 2018 à 20:55, Yves <yve...@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.dj...@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 <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
