[Talk-transit] Uploading public transport data on OSM

[Stephen Sprunk]

Agreed; ref:gtfs just won't work, and ref:OPER probably would. 

I was originally thinking in terms of some gtfs:key tags for imported
data, similar to tiger:key tags.  Once you consider multiple objects
could be merged, though, that would likewise need to change to
gtfs:OPER:key.  But do we need such import tags if we can directly put
the data directly into normal tags, such as your ref:OPER?  My first
thought was no, but perhaps it could help OSM edits survive future
imports of lower-quality GTFS data? 

>From the other side, how can we design this so that stops removed from
one or more GTFS feeds can be properly updated in OSM?  I was thinking a
gtfs:OPER:importdate tag, and once you're done adding/updating all the
objects in the latest GTFS feed, you can then query for objects still
showing a previous import date.  But there is probably a better way. 

S 

On 2018-01-16 15:17, Jo wrote:

> 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

-- 
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/20180118/ad6b1822/attachment.html>