For the coordinated schedule, as an example there is a route that departure at the following time: 08:00, 08:00, 08:03, 08:06, 08:09, 08:12, 08:15, 08:18, 08:22, 08:25, 08:29, 08:33, 08:38, 08:38, 08:38, 08:41, 08:44, 08:47, 08:51, 08:54, 08:57, 09:01, 09:05, 09:09, 09:13, and of these departures, 08:00-08:15 departures are operated by operator A, 08:18-08:33 departures operated by operator B, 08:38-08:54 departures operated by operator A, and then 08:57-09:13 departures are operated by operator B.
I would say if you map them as multiple relationship then end users would have no idea which relationship is the one they want. It's also unnecessarily increasing the number of route variants that need to be maintained by the order of magnitude of hundreds. 在 2019年3月7日週四 22:17,Martin Koppenhoefer <dieterdre...@gmail.com> 寫道: > > > sent from a phone > > > On 7. Mar 2019, at 15:02, Phake Nick <c933...@gmail.com> wrote: > > > > The route us currently operated by two different operators on > coordinated timetable and each operator have their own ETA system. While > they do not provide a GTFS feed for now, it can be expected that each of > them will provide their own feed if they would like to do so in the future. > However it doesn't make sense to have multiple relationship for them as > they run on exact same route with exact same route number and run on a > coordinated schedule > > > IMHO it could make sense to have multiple relations, we will also have > multiple GTFS urls in this case. There are route master relations which can > group route variants and could be used here as well. A coordinated schedule > means they have completely different schedules, right? (although the > customers might not care). > > Cheers, Martin > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging