Within a geographic area could we accept that all bus stops with a specific tag were GTFS tags for a particular transit company?
Thanks John On 16 Jan 2018 7:42 pm, "Johnparis" <[email protected]> wrote: > I believe OSM-Sync creates nodes with "gtfs_id" as the tag key. The value > is typically something like "StopPoint:48:5001". > > 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.) > > 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.) > > 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. > > I have a couple of thoughts about GSoC projects for JOSM plugins that > might be useful. > > -- 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). > > -- 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. > > Perhaps these tools already exist. I'd love to see them. > > John > > > >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 16 Jan 2018 21:35:54 +0100 >> From: Jo <[email protected]> >> To: "Public transport/transit/shared taxi related topics" >> <[email protected]> >> Subject: Re: [Talk-transit] Uploading public transport data on OSM >> Message-ID: >> <[email protected] >> ail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Is there a common pattern to these GTFS IDs? Are they guaranteed to be >> unique across operators? >> >> Or is that not important and is it only important that they are stable >> between versions of GTFS files for a region? >> >> 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. >> >> Polyglot >> >> 2018-01-16 21:07 GMT+01:00 Stephen Sprunk <[email protected]>: >> >> > >> > >> > 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. >> > >> > 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. >> > >> > S >> > >> > -- >> > Stephen Sprunk "Those people who think they know everything >> > CCIE #3723 are a great annoyance to those of us who do." >> > K5SSS --Isaac Asimov >> > >> > > _______________________________________________ > Talk-transit mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-transit > >
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
