On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski <[email protected]> wrote:
> > Again, frankly - approximately zero general-purpose apps will support > whatever scheme we could come up with in OpenStreetMap to tag the > situation "this stop is served by a route that has two separate > timetables that are both valid, and is also served by another route, > and here are the links to PDFs of these three timetables". If we don't come up with a sensible tagging scheme we can guarantee that no app will support it. Yes, url=* would work for a timetable. But what if we also want to link to GTFS? What if a user clicks on a url=* expecting a timetable and gets a GTFS? Let's make it user- and app-friendly, not user- and app-unfriendly. It costs us nothing to have specific keys for these things (except the time spent arguing here) and has no downside; going with url=* and finding out later that it was a bad idea would cause problems. Routes do exist with more than one operator. They've happened around here in the past when the county council wanted to split subsidized routes between two operators. I also encountered such routes between a large town and a city when both population centres had town/city councils who ran their own bus services, on the route between the two localities. I encountered it in a large city after government deregulation meant that a national operator and the city's own bus service competed on some routes to nearby commuter villages. So even if we restrict this to routes and don't put it on stops, we need to handle the case where two (or more) operators put up partial timetables or partial GTFS data. This isn't an edge case, it's what happens. Again, the cost of dealing with it now (even if it's rarely needed) is minimal; the cost of changing it later (if we find it's not a rare thing) will not be. Bad tagging decisions never die, and they rarely fade away. -- Paul
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
