[Talk-transit] Uploading public transport data on OSM

Jo winfixit at gmail.com
Tue Jan 16 21:17:36 UTC 2018


That is why I think it's important not to go with ref:gtfs, but use
ref:operator1, ref:operator2. Where operator1 and operator2 are the names
or short names for the different operators. In many cases you'll find that
these refs are also what the public sees on the stops (if the operators
decide to put it there) or in internet urls when using the operator's
website.

Here in Belgium, we have 3 operators extending into the other operator's
mostly served area and some lines extend into neighbouring countries, so we
had to namespace the ref tag a few years ago, already.

Polyglot

2018-01-16 22:07 GMT+01:00 Stephen Sprunk <stephen at sprunk.org>:

> 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.
>
> S
>
>
> 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
>>>> 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.
>>
>> 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
>>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> --
> 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/20180116/e7de0d96/attachment.html>


More information about the Talk-transit mailing list