[Talk-transit] Uploading public transport data on OSM

[john whelan]

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" <okosm at johnfreed.com> 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 <winfixit at gmail.com>
>> To: "Public transport/transit/shared taxi related topics"
>>         <talk-transit at openstreetmap.org>
>> Subject: Re: [Talk-transit] Uploading public transport data on OSM
>> Message-ID:
>>         <CAJ6DwMD4Ls3FwXL395nb6ZepbyJ_Q+mHW_LooH_UEG+f-HHn-A at mail.gm
>> 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 <stephen at sprunk.org>:
>>
>> >
>> >
>> > 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
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20180116/9b9b0a9a/attachment.html>