[Tagging] New Tag "Departures" voting results.
pla16021 at gmail.com
Tue Mar 5 11:59:00 UTC 2019
On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski <jarek at piorkowski.ca> wrote:
> 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.
Not necessarily. I'd use website=* for domains like www.foo.com but url=*
for a specific page
within a website.
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.
There are other problems.
1) Many services around here don't have an "upcoming buses from this stop"
page. We're lucky
they've finally managed to put the timetables on the web.
2) Upcoming buses are useful if you find yourself stranded near a bus
stop. If you're planning
a future journey you want a timetable.
3) You can always figure out the upcoming buses if you have a timetable;
you cannot figure out
the timetable from upcoming buses.
> 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.
Again, "upcoming buses" just doesn't cut it for me. Great for big towns
and cities. Not so good
for rural routes. Great for when you're unexpectedly stranded near a bus
stop. Not so good for
planning a journey in advance.
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
> https://nb.translink.ca/text/stop/50167 or
I'm not sure what point you were making there. They're web pages, not
tagging schemes. If
you wanted me to admire the pretty web pages, that's nice. If you want to
see what I have to
put up with, here's what one operator has:
and here's the
county council's version of the same route (showing more stops):
There is no "next 3 buses" info. These pages are not updated live.
They're just PDFs.
>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.
>From the perspective of a Brit who uses (but doesn't operate) buses, that
sounds about right.
Where we differ is which is most useful. We probably need tags for both
(for when both
are available), rather than leave it to the mapper to decide.
> 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.
Good question. On the routes I have in mind, the county council and one
provided full timetables but the other operator provided a partial
timetable. The operator
who provided full timetables has managed to produce broken GTFS for some
(it works, but the answers it gives are silly). I have seen no indication
that the county council
has even heard of GTFS.
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...)
Ummm, wouldn't that mean GTFS data about every route by that agency?
However, you've made me abandon hopes of adding this information to stops.
means more steps when using the query tool on standard carto, and some
be able to handle that, but trying to cater to them by adding the info to
> But stops can be used by
> > more than one route. So then we'd need
> 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.
But we do have to be careful not to assume that our own experiences
represent the majority
of real-world use. Many cities/towns I've lived have bus services to other
cities/towns where each
town has their own local operator and the route between them is shared by
both operators. It's
kinda normal. Many bus stops within a town are common to more than one
route. It's kinda
normal. So having a stop with more than one route, and one of those routes
having more than
one operator may not be common, but it's not so rare that it can be
dismissed as an edge case.
And, whilst writing this, I stumbled upon what UK gov't is trying to do.
They've come up with
a superset (ish) of GTFS: http://naptan.dft.gov.uk/transxchange/gtfs.htm
They're trying to get
operators to comply and Europe to adopt it:
Some people within OSM are trying to figure out how to import it:
https://wiki.openstreetmap.org/wiki/NaPTAN (left hand, meet right hand).
My head hurts. I have a new proposal. Let's NOT map bus timetables. Or
bus routes. Or bus
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging