n [mailto:thesw...@gmail.com]
Sent: fredag 19. januar 2018 04.12
To: talk-transit@openstreetmap.org
Subject: Re: [Talk-transit] Uploading public transport data on OSM
On 19/01/18 01:32, Stephen Sprunk wrote:
Agreed; ref:gtfs just won't work, and ref:OPER probably would.
I had always thought tha
: talk-transit@openstreetmap.org
Subject: Re: [Talk-transit] Uploading public transport data on OSM
On 19/01/18 01:32, Stephen Sprunk wrote:
> Agreed; ref:gtfs just won't work, and ref:OPER probably would.
>
I had always thought that ref was the public facing reference that is used (ie:
On 19/01/18 01:32, Stephen Sprunk wrote:
Agreed; ref:gtfs just won't work, and ref:OPER probably would.
I had always thought that ref was the public facing reference that is
used (ie: what's on the bus stop sign) and in the GTFS scheme this is
stop_code. The stop_id is supposed to be unique
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 s
s already exist. I'd love to see them.
>
> John
>
>
>
>>
>>
>> --
>>
>> Message: 5
>> Date: Tue, 16 Jan 2018 21:35:54 +0100
>> From: Jo
>> To: "Public transport/transit/shared taxi related topics"
&
0
> From: Jo
> To: "Public transport/transit/shared taxi related topics"
>
> Subject: Re: [Talk-transit] Uploading public transport data on OSM
> Message-ID:
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is there
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
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
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
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.
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 onl
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.
Yes, the permissions from the agency will be obtained.
On Tue, Jan 16, 2018 a
Hi, the very first question that comes to mind is: is it under a suitable
license, or can you get explicit permission from the operator to contribute
it to OpenStreetMap?
The next issue is that there is no direct way to add GTFS to OSM. stops.txt
can be converted to nodes for the stops, but the ot
Hi,
If I have a GTFS data of my agency, can I upload it to OSM? Do I need to
convert it to any other format before uploading? Do I need to create a
special account in OSM to be able to upload the data? Will it start showing
the public transport options on the map similar to Google Maps?
Regards,
14 matches
Mail list logo
