<div dir="ltr">I believe OSM-Sync creates nodes with "gtfs_id" as the tag key. The value is typically something like "StopPoint:48:5001". <br><div class="gmail_extra"><br></div><div class="gmail_extra">In response to Jo/Polyglot's concern, the gtfs_id is not unique globally; it is unique within a GTFS feed. So, for instance, the Paris area's transport agency, STIF (now IDFM), has unique IDs within the Paris region. It is theoretically possible that these could be duplicated somewhere else in the world (though that likelihood is extremely small, given the numbering scheme they use). The STIF scheme is StopPoint:x:y, where x is the (internal STIF) code of the agency providing the stop times for each trip, and y is an arbitrary number guaranteed to be unique within the agency. (The agency codes are in the agency.txt file in the GTFS feed. It gets quite arbitrary; for instance the RATP, which runs the Paris transport system, has an agency code of 59 for purposes of bus StopPoints but a code of 100 for some other purposes. Weird.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I agree with Stephen Sprunk about the need to sync with a unique ID. I have begun using gtfs_id (easily changed to, for example, ref:FR:STIF:gtfs_id), with the idea that changes would first be synched against the existing ID. STIF does not guarantee that the gtfs_id for a stop is permanent; however, it seems to be the case. (STIF did guarantee that a different code would be permanent, but it seems to have abandoned that recently, and GTFS is becoming the de facto standard.) It makes my life a little simpler to use gtfs_id instead of ref:FR:STIF:gtfs_id because the matching logic is simpler. (I started with ref:FR:STIF:gtfs_id but then in JOSM for instance I could not do a search for "gtfs_id -ref" because the "-ref" includes any ref, even ref:FR:STIF:gtfs_id. Using just gtfs_id avoids that problem.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">The problem I run into most frequently is when someone "on the ground" (that is, a mapper) has created a bus stop (usually with a position much more accurate than the agency's data) but the stop doesn't have useful information to derive the gtfs_id. (For instance, if the node had an accurate stop name and the number of a bus line that serves it, I could derive the gtfs_id, but often there isn't anything more informative than "highway=bus_stop".) As a result, I have been importing nodes for each bus line from the STIF data (with permission), then manually merging the nodes with those already in place on the ground. I save myself lots of time when I encounter a new line that uses existing gtfs_ids.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I have a couple of thoughts about GSoC projects for JOSM plugins that might be useful. </div><div class="gmail_extra"><br></div><div class="gmail_extra">-- One would deal with the aforementioned node-merging problem (an interesting theoretical problem; mostly you want to match the closest stop on the same side of the road, assuming it's within a reasonable distance). </div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Another would be a route-builder. My idea would be (a) I provide a starting way and direction, (b) at the end of each way, I indicate left, right, straight or other to continue. I think this would greatly speed the creation of routes. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Perhaps these tools already exist. I'd love to see them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">John</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><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>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 16 Jan 2018 21:35:54 +0100<br>
From: Jo <<a href="mailto:winfixit@gmail.com">winfixit@gmail.com</a>><br>
To: "Public transport/transit/shared taxi related topics"<br>
<<a href="mailto:talk-transit@openstreetmap.org">talk-transit@openstreetmap.<wbr>org</a>><br>
Subject: Re: [Talk-transit] Uploading public transport data on OSM<br>
Message-ID:<br>
<<a href="mailto:CAJ6DwMD4Ls3FwXL395nb6ZepbyJ_Q%2BmHW_LooH_UEG%2Bf-HHn-A@mail.gmail.com">CAJ6DwMD4Ls3FwXL395nb6ZepbyJ_<wbr>Q+mHW_LooH_UEG+f-HHn-A@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Is there a common pattern to these GTFS IDs? Are they guaranteed to be<br>
unique across operators?<br>
<br>
Or is that not important and is it only important that they are stable<br>
between versions of GTFS files for a region?<br>
<br>
Adding a ref:gtfs tag would not be very hard to do, but I would prefer a<br>
scheme with ref:OPERATOR, because some stops may be served by multiple<br>
operators and thus be present in multiple GTFS feeds.<br>
<br>
Polyglot<br>
<br>
2018-01-16 21:07 GMT+01:00 Stephen Sprunk <<a href="mailto:stephen@sprunk.org">stephen@sprunk.org</a>>:<br>
<br>><br>><br>
> What I'd like to see is some sort of tag on OSM objects (stops, routes,<br>
> etc.) listing the GTFS ID numbers so that tools can more easily connect the<br>
> two; that should be easy enough if someone defines a scheme and gets the<br>
> few relevant tools to use it.<br>
><br>
> The lat/long for stops in GTFS data is often questionable, so it would be<br>
> good to have some way for folks to be able to fix the stop locations in OSM<br>
> and not get overwritten by another import later. In many places<br>
> (especially in the US), GTFS data will change every few months, so if we<br>
> want it in OSM at all, we need a scheme that can deal with regular bulk<br>
> imports without losing quality where local OSM editors have improved things<br>
> by hand.<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<br>
><br></blockquote></div></div></div>