<div dir="ltr"><div><div>That is why I think it's important not to go with ref:gtfs, but use ref:operator1, ref:operator2. Where operator1 and operator2 are the names or short names for the different operators. In many cases you'll find that these refs are also what the public sees on the stops (if the operators decide to put it there) or in internet urls when using the operator's website.<br><br></div>Here in Belgium, we have 3 operators extending into the other operator's mostly served area and some lines extend into neighbouring countries, so we had to namespace the ref tag a few years ago, already.</div><div><br></div><div>Polyglot<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-16 22:07 GMT+01:00 Stephen Sprunk <span dir="ltr"><<a href="mailto:stephen@sprunk.org" target="_blank">stephen@sprunk.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:12pt;font-family:Verdana,Geneva,sans-serif">
<p>AFAIK, the operator ID is only guaranteed to be unique within a single GTFS feed, but it's reasonably safe to assume they'll also be unique between feeds with overlapping geographical areas. It's probably not safe to assume that's transitive.</p>
<p>Where operators don't cooperate and produce a single joint feed, you'll inevitably face the "same" stops appearing in multiple feeds. Imagine a single roadside bus stop pole with signs from two or three different bus operators on it, and that pole would have a different ID and probably even different lat/long in each feed. Ideally, a local OSM editor would be able to merge them into a single stop object--and that merger would survive later bulk imports from all those GTFS feeds. This would cut down on map clutter and allow routing apps to more easily recognize transfers, but I'm not sure how to design such a schema.</p>
<p>It's been a while since I read the spec, but I think GTFS also has a similar concept to stop_areas, and that will probably have similar problems to stops.</p>
<p>Routes appear simpler to deal with since they're unique to each operator, but they're inherently built on top of stops (or stop_areas), so they may present new problems when we get there.</p><span class="HOEnZb"><font color="#888888">
<p>S</p></font></span><div><div class="h5">
<p><br></p>
<p>On 2018-01-16 14:35, Jo wrote:</p>
<blockquote type="cite" style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">
<div dir="ltr">
<div>
<div>
<div>Is there a common pattern to these GTFS IDs? Are they guaranteed to be unique across operators?<br><br></div>
Or is that not important and is it only important that they are stable between versions of GTFS files for a region?<br><br></div>
Adding a ref:gtfs tag would not be very hard to do, but I would prefer a scheme with ref:OPERATOR, because some stops may be served by multiple operators and thus be present in multiple GTFS feeds.<br><br></div>
Polyglot</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2018-01-16 21:07 GMT+01:00 Stephen Sprunk <span><<a href="mailto:stephen@sprunk.org" target="_blank">stephen@sprunk.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>On 2018-01-16 08:30, Mike N wrote:<br></span></span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/16/2018 7:37 AM, Yash Ganthe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What caught my attention is a project called Go Sync <a href="https://wiki.openstreetmap.org/wiki/GO-Sync" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/GO-Sync</a><br> The description indicates that it is for syncing GTFS with OSM. But I am not sure what type of account is needed for that.</blockquote>
<br> <br> From what I recall, Go-Sync only synchronizes stops but not the GTFS<br> route paths with OSM route relations.<br> <br> The routing samples on the OpenStreetMap web site will not<br> automatically give public transport trip routing because the full GTFS<br> schedule information is not in OSM. It would require a separate<br> local site such as OpenTripPlanner which automatically combines full<br> GTFS with OSM data. There are some companies providing large scale<br> instances of OpenTripPlanner which may cover your area.</blockquote>
What I'd like to see is some sort of tag on OSM objects (stops, routes, etc.) listing the GTFS ID numbers so that tools can more easily connect the two; that should be easy enough if someone defines a scheme and gets the few relevant tools to use it.<br> <br> The lat/long for stops in GTFS data is often questionable, so it would be good to have some way for folks to be able to fix the stop locations in OSM and not get overwritten by another import later. In many places (especially in the US), GTFS data will change every few months, so if we want it in OSM at all, we need a scheme that can deal with regular bulk imports without losing quality where local OSM editors have improved things by hand.<span class="m_-1412878767085905475HOEnZb"><span style="color:#888888"><br> <br> S<br> <br> -- <br> Stephen Sprunk "Those people who think they know everything<br> CCIE #3723 are a great annoyance to those of us who do."<br> K5SSS --Isaac Asimov</span></span>
<div class="m_-1412878767085905475HOEnZb">
<div class="m_-1412878767085905475h5"><br> <br> ______________________________<wbr>_________________<br> Talk-transit mailing list<br> <a href="mailto:Talk-transit@openstreetmap.org" target="_blank">Talk-transit@openstreetmap.org</a><br> <a href="https://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-transit</a></div>
</div>
</blockquote>
</div>
</div>
<br>
<div class="m_-1412878767085905475pre" style="margin:0;padding:0;font-family:monospace">______________________________<wbr>_________________<br> Talk-transit mailing list<br> <a href="mailto:Talk-transit@openstreetmap.org" target="_blank">Talk-transit@openstreetmap.org</a><br> <a href="https://lists.openstreetmap.org/listinfo/talk-transit" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-transit</a></div>
</blockquote>
<p><br></p>
<div>
<div class="m_-1412878767085905475pre" style="margin:0;padding:0;font-family:monospace"><span class="m_-1412878767085905475sig">-- <br> Stephen Sprunk "Those people who think they know everything<br> CCIE #3723 are a great annoyance to those of us who do."<br> K5SSS <wbr> --Isaac Asimov</span></div>
</div>
</div></div></div>
</blockquote></div><br></div>