[Tagging] New Tag "Departures" voting results.
jarek at piorkowski.ca
Tue Mar 5 01:40:05 UTC 2019
I've gotten paid for wrangling GTFS worldwide before - happy to tell
you some of my experiences.
On Sat, 2 Mar 2019 at 19:42, Paul Allen <pla16021 at gmail.com> wrote:
> 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),
That would rather be website=* though. And to keep it simple, you can
do a lot worse than putting an "upcoming buses from this stop" page
URL into the website=* for vast majority of stops out there. Only
problem is that doesn't scale very nicely to 10000 stops.
> 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.
I'd be happy with gtfs=<url to the gtfs zip> on a possibly high-level
relation that ultimately includes stops, and timetable=<url> or
departures=<url> on stops where available as HTML page.
I think the Berlin tagging makes sense:
https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
Other pages I'm familiar with are
>From Canadian English perspective, "timetable" would be more likely to
be interpreted as all departures for the whole week (as on the TTC
page). "departures" matches the "next 3 buses" case a bit closer. But
perhaps it's different in British English.
> 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).
GTFS as a format is operator agnostic (the operator information is not
in the data at all, only "agency", but each route must be tied to
exactly one agency). It is more of a question whether a full timetable
is provided in a given GTFS file or if it is a partial timetable and
we want to support merging timetables.
Having done some work on merging GTFS, I am afraid the latter is a
deep rabbit hole very few data consumers will go down.
What I have seen in transit data collection is one physical stop
served by multiple agencies which provide separate GTFS files, and
sometimes they reference the stop using different stop IDs. But in
that case it would be using different routes, and it should be doable
with ref:<agency_1>=123 + ref:<agency_2>=abc (where agency_1 and
agency_2 preferably match the GTFS agency IDs...)
Feel free to ask for more technical info about GTFS :) Or for
real-world usage - I've looked at GTFS for most major metros in Canada
and U.S., some smaller metros, data where available in Europe, and a
bit of Australia.
> But stops can be used by
> more than one route. So then we'd need timetable:route-number:operator=link.
Different route operators with separate timetables is probably in the
"use departures_1 for departures that don't fit" territory. We don't
need to support every edge case to be useful, just the majority of
real world use.
More information about the Tagging