<div dir="ltr"><div dir="ltr"><div dir="ltr">On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski <<a href="mailto:jarek@piorkowski.ca">jarek@piorkowski.ca</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Sat, 2 Mar 2019 at 19:42, Paul Allen <<a href="mailto:pla16021@gmail.com" target="_blank">pla16021@gmail.com</a>> wrote:<br>
> As I said, I'd prefer not to use url=* because it could be for anything - a page about the history of<br>
> the bus stop (maybe the shelter is a listed building),<br>
<br>
That would rather be website=* though.</blockquote><div><br></div><div>Not necessarily. I'd use website=* for domains like <a href="http://www.foo.com">www.foo.com</a> but url=* for a specific page</div><div>within a website.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> And to keep it simple, you can do a lot worse than putting an "upcoming buses from this <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> stop" page URL into the website=* for vast majority of stops out there. Only<br>
problem is that doesn't scale very nicely to 10000 stops.<br></blockquote><div><br></div><div>There are other problems.</div><div><br></div><div>1) Many services around here don't have an "upcoming buses from this stop" page. We're lucky</div><div>they've finally managed to put the timetables on the web.</div><div><br></div><div>2) Upcoming buses are useful if you find yourself stranded near a bus stop. If you're planning</div><div>a future journey you want a timetable.</div><div><br></div><div>3) You can always figure out the upcoming buses if you have a timetable; you cannot figure out</div><div>the timetable from upcoming buses.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> or a timetable or whatever web page the<br>
> mapper happened to think relevant. I'd prefer to distinguish between a human-readable timetable<br>
> and raw GTFS data (not really human-readable but could be parsed by an app). For lack of anything<br>
> better, I'd be happy with timetable=* and gtfs=* but I expect somebody will be along shortly to explain<br>
> why those are a very bad idea.<br>
<br>
I'd be happy with gtfs=<url to the gtfs zip> on a possibly high-level<br>
relation that ultimately includes stops, and timetable=<url> or<br>
departures=<url> on stops where available as HTML page.<br></blockquote><div><br></div><div>Again, "upcoming buses" just doesn't cut it for me. Great for big towns and cities. Not so good</div><div> for rural routes. Great for when you're unexpectedly stranded near a bus stop. Not so good for</div><div>planning a journey in advance.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think the Berlin tagging makes sense:<br>
<a href="https://osm.org/node/1137469153" rel="noreferrer" target="_blank">https://osm.org/node/1137469153</a> with website=<a href="http://qr.bvg.de/h309003" rel="noreferrer" target="_blank">http://qr.bvg.de/h309003</a>.<br>
Other pages I'm familiar with are<br>
<a href="https://nb.translink.ca/text/stop/50167" rel="noreferrer" target="_blank">https://nb.translink.ca/text/stop/50167</a> or<br>
<a href="http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed" rel="noreferrer" target="_blank">http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed</a></blockquote><div><br></div><div>I'm not sure what point you were making there. They're web pages, not tagging schemes. If</div><div>you wanted me to admire the pretty web pages, that's nice. If you want to see what I have to</div><div> put up with, here's what one operator has:</div><div> <a href="https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf">https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf</a> and here's the</div><div> county council's version of the same route (showing more stops):</div><div><a href="https://www.ceredigion.gov.uk/media/4410/408.pdf">https://www.ceredigion.gov.uk/media/4410/408.pdf</a></div><div>There is no "next 3 buses" info. These pages are not updated live. They're just PDFs.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From Canadian English perspective, "timetable" would be more likely to<br>
be interpreted as all departures for the whole week (as on the TTC<br>
page). "departures" matches the "next 3 buses" case a bit closer. But<br>
perhaps it's different in British English.<br></blockquote><div><br></div><div>From the perspective of a Brit who uses (but doesn't operate) buses, that sounds about right.</div><div>Where we differ is which is most useful. We probably need tags for both (for when both</div><div> are available), rather than leave it to the mapper to decide.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Whatever we go for, we have to cater to the fact that a particular route may have more than one<br>
> operator (I'm not talking about super-routes here). Around here there are many small local operators,<br>
> and longer routes sometimes split the service between two operators (i.e., the route X to Y might<br>
> be split between an operator based in X and another operator based in Y).<br>
<br>
GTFS as a format is operator agnostic (the operator information is not<br>
in the data at all, only "agency", but each route must be tied to<br>
exactly one agency). It is more of a question whether a full timetable<br>
is provided in a given GTFS file or if it is a partial timetable and<br>
we want to support merging timetables.<br></blockquote><div><br></div><div>Good question. On the routes I have in mind, the county council and one operator</div><div> provided full timetables but the other operator provided a partial timetable. The operator</div><div> who provided full timetables has managed to produce broken GTFS for some routes</div><div> (it works, but the answers it gives are silly). I have seen no indication that the county council</div><div> has even heard of GTFS.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What I have seen in transit data collection is one physical stop<br>
served by multiple agencies which provide separate GTFS files, and<br>
sometimes they reference the stop using different stop IDs. But in<br>
that case it would be using different routes, and it should be doable<br>
with ref:<agency_1>=123 + ref:<agency_2>=abc (where agency_1 and<br>
agency_2 preferably match the GTFS agency IDs...)<br></blockquote><div><br></div><div>Ummm, wouldn't that mean GTFS data about every route by that agency?</div><div><br></div><div>However, you've made me abandon hopes of adding this information to stops. Yes, it</div><div>means more steps when using the query tool on standard carto, and some users won't</div><div>be able to handle that, but trying to cater to them by adding the info to stops isn't</div><div>feasible.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But stops can be used by<br>
> more than one route. So then we'd need timetable:route-number:operator=link.<br>
<br>
Different route operators with separate timetables is probably in the<br>
"use departures_1 for departures that don't fit" territory. We don't<br>
need to support every edge case to be useful, just the majority of<br>
real world use.<br></blockquote><div><br></div><div>But we do have to be careful not to assume that our own experiences represent the majority</div><div>of real-world use. Many cities/towns I've lived have bus services to other cities/towns where each</div><div>town has their own local operator and the route between them is shared by both operators. It's</div><div>kinda normal. Many bus stops within a town are common to more than one route. It's kinda</div><div>normal. So having a stop with more than one route, and one of those routes having more than</div><div> one operator may not be common, but it's not so rare that it can be dismissed as an edge case.</div><div><br></div><div>And, whilst writing this, I stumbled upon what UK gov't is trying to do. They've come up with</div><div>a superset (ish) of GTFS: <a href="http://naptan.dft.gov.uk/transxchange/gtfs.htm">http://naptan.dft.gov.uk/transxchange/gtfs.htm</a> They're trying to get</div><div> operators to comply and Europe to adopt it: <br></div><div><a href="https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/722573/bus-services-act-2017-open-data-consultation.pdf">https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/722573/bus-services-act-2017-open-data-consultation.pdf</a></div><div>Some people within OSM are trying to figure out how to import it: </div><div><a href="https://wiki.openstreetmap.org/wiki/NaPTAN">https://wiki.openstreetmap.org/wiki/NaPTAN</a> (left hand, meet right hand).</div><div><br></div><div>My head hurts. I have a new proposal. Let's NOT map bus timetables. Or bus routes. Or bus</div><div>stops.</div><div><br></div><div>-- <br></div><div>Paul</div><div><br></div><div><br></div><div><br></div></div></div></div>