On Sun, 3 Mar 2019 at 00:06, Graeme Fitzpatrick <graemefi...@gmail.com> wrote:
> > On Sun, 3 Mar 2019 at 00:21, Paul Allen <pla16...@gmail.com> wrote: > >> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote: >> >>> >>> So a documented way of including GTFS link in routes? >>> >> >> Yep. We could just use url=* >> > > When I've been adding bus stops, I've been using timetable= linked to the > GTFS data for that stop eg https://www.openstreetmap.org/node/6251012182 > links to https://jp.translink.com.au/plan-your-journey/stops/300772, > which shows the buses for about the next hour, on both routes that service > that stop. That page (which, incidentally, we have explicit permission to > use, plus a waiver!) then also links to the full timetable for today & > other days. > That is not the raw GTFS data but a human-readable, active (it uses web 2.0 magic) timetable based (presumably) on the GTFS data. When I've looked at stop info via OSMAND on my phone, the URL is there as a > clickable link so it would appear to work? > I'd guess that OSMAND (and the standard carto, which also treats it as a link) is using a heuristic along the lines of "If I don't know what the key means AND the value looks like a URL then treat the value as a link." Which is reasonable, but it would be nice to formalize it. If for no other reason than to allow verification tools to know that the value ought to be a link to a working web page and that they should check it. As I said, I'd prefer not to use url=* because it could be for anything - a page about the history of the bus stop (maybe the shelter is a listed building), or a timetable or whatever web page the mapper happened to think relevant. I'd prefer to distinguish between a human-readable timetable and raw GTFS data (not really human-readable but could be parsed by an app). For lack of anything better, I'd be happy with timetable=* and gtfs=* but I expect somebody will be along shortly to explain why those are a very bad idea. Whatever we go for, we have to cater to the fact that a particular route may have more than one operator (I'm not talking about super-routes here). Around here there are many small local operators, and longer routes sometimes split the service between two operators (i.e., the route X to Y might be split between an operator based in X and another operator based in Y). In the cases where this has happened one of those operators produced a timetable showing all of the services irrespective of the operator whilst the other operator's timetable showed only its own services. Since the route was subsidized by local gov't, there was also a council timetable. Actually, the route was between locations in two counties, so there were probably two council timetables. But there could have been only two operator timetables that showed only their own services on that route. So maybe we need timetable:operator=link. Further complication if we want to add this information to bus stops as well as routes. An app ought to be capable of finding the route from a query about a stop and then getting the appropriate timetable. But using the query tool provided by standard carto may require more smarts than many data consumers have, so adding the timetable to stops would be nice. But stops can be used by more than one route. So then we'd need timetable:route-number:operator=link. I'm hoping somebody will come up with a better tagging scheme... -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
