[Tagging] New Tag "Departures" voting results.
pla16021 at gmail.com
Sun Mar 3 00:42:09 UTC 2019
On Sun, 3 Mar 2019 at 00:06, Graeme Fitzpatrick <graemefitz1 at gmail.com>
> On Sun, 3 Mar 2019 at 00:21, Paul Allen <pla16021 at gmail.com> wrote:
>> On Sat, 2 Mar 2019 at 08:14, Warin <61sundowner at 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
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
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
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
I'm hoping somebody will come up with a better tagging scheme...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging