[Talk-transit] Uploading public transport data on OSM

Stephen Sprunk stephen at sprunk.org
Tue Jan 16 21:07:50 UTC 2018

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. 

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. 

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. 

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. 


On 2018-01-16 14:35, Jo wrote:

> 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>:
> On 2018-01-16 08:30, Mike N wrote:
> On 1/16/2018 7:37 AM, Yash Ganthe wrote:
> What caught my attention is a project called Go Sync https://wiki.openstreetmap.org/wiki/GO-Sync [1]
> The description indicates that it is for syncing GTFS with OSM. But I am not sure what type of account is needed for that. 
> From what I recall, Go-Sync only synchronizes stops but not the GTFS
> route paths with OSM route relations.
> The routing samples on the OpenStreetMap web site will not
> automatically give public transport trip routing because the full GTFS
> schedule information is not in OSM.   It would require a separate
> local site such as OpenTripPlanner which automatically combines full
> GTFS with OSM data.   There are some companies providing large scale
> instances of OpenTripPlanner which may cover your area.
 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.


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 [2] 
Talk-transit mailing list
Talk-transit at openstreetmap.org

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov 

[1] https://wiki.openstreetmap.org/wiki/GO-Sync
[2] https://lists.openstreetmap.org/listinfo/talk-transit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20180116/031ede30/attachment.html>

More information about the Talk-transit mailing list