[Talk-transit] Uploading public transport data on OSM

Johnparis okosm at johnfreed.com
Wed Jan 17 00:41:44 UTC 2018

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.


> ------------------------------
> 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.
> gmail.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
> > 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20180117/b4d248f2/attachment-0001.html>

More information about the Talk-transit mailing list