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 <step...@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
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
