Hello, 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 <pla16...@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 https://nb.translink.ca/text/stop/50167 or http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed 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. --Jarek _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging