[Imports-us] [Imports] RTD Denver GIS data
derek.kniffin at gmail.com
Thu Aug 29 16:36:45 UTC 2013
I like your idea of doing each feature set separately. I think I will do
I also will do bus routes last, but that is the primary reason I'd like
to do this import, so I don't want to skip it. A lot of the routes in
Denver are missing, and a lot of the ones that are in OSM are wrong, and
almost none of them conform to any kind of standard.
One thought for automated updates would be to create a note each time
there's a new set of changes, and manually make the changes. Of course,
that would be messy, and automated is always better, so if I can script
those changes, that'd be better. An even better (but unlikely)
alternative would be to convince RTD to do the updates each time the
routes change, or possibly use OSM as their primary data set; I'll see
if they might be willing to do that.
I started reading over your notes, and I've read over all those wiki
pages. From what I've read so far, I'm starting to understand that the
easiest way to process this data is to manipulate the osm xml file
programmatically. Is that correct? I'll continue reading through the
rest of the docs in the next few days.
Lastly, I found a better contact for RTD that is supposed to be for
Developers to send inquiries to, so I emailed that one just now.
Hopefully I hear a response soon, because of course I can't do any real
importing until I have their permission.
On 8/26/2013 6:40 PM, Jason Remillard wrote:
> Hi Derek,
> I would recommend treating each feature type as as separate import
> project (bus stops, rail, park and ride, etc). If the bus routes are
> changing all of the time and you want to develop an automated update
> function, that is going to be 10x more work than the one time imports.
> Unless that is your number 1 priority, save it for last, or just skip
> I have written up some notes on doing large imports. You might want to
> read them over. Also, be sure to read the OSM Wiki links at the top of
> my README.md.
> On Mon, Aug 26, 2013 at 7:35 PM, Derek Kniffin <derek.kniffin at gmail.com> wrote:
>> Hi all,
>> I'm completely new to this list (I signed up less than a few minutes ago),
>> so I'm sorry if I'm ignorant of anything pertaining to the list and/or
>> imports in general. I am fairly experienced with many things OSM; I've been
>> editing for 6 months or so, and I've created a couple applications using OSM
>> data, so I'm not a complete noob. However, I've never been involved in any
>> imports. I also apologize for the length of this email; I wanted to make
>> sure all the details are here.
>> I would like to import the GIS data found at the link at the bottom of this
>> page: http://www3.rtd-denver.com/elbert/SystemMap/
>> RTD is the company that runs the public transportation system for all of
>> metro Denver. This includes buses and light rails. I have already contacted
>> RTD about using the data in OSM (copyrights, etc), and I'm waiting to hear a
>> response. In the meantime, I was hoping to discuss the technical details of
>> the import.
>> I've already downloaded their GIS data to take a look at it. It's divided
>> into several different data sets, of which I'm interested in importing: bus
>> stops, bus routes, light rail lines, light rail stations, call-n-rides, and
>> park-n-rides. I'm planning on following the public transportation schema
>> (http://wiki.openstreetmap.org/wiki/Public_transport). That means that there
>> will be a relation for each bus route, and possibly relation for each stop
>> (with a platform and stop_area), and similarly for light rails.
>> What I'm wondering about is the technical aspect of tweaking the import
>> data. Looking at the data, I think the way they organize each route is they
>> have a way at the beginning with the route information. Then they have a
>> bunch more ways that usually (but not always) connect to make the rest of
>> the route. (eg: A----B-----C-----D; way A has the route information, the
>> rest don't). Sometimes, the ways do not connect, but the endpoints are
>> within a foot of each other.
>> The stops should be fairly easy. Each stop has an attribute mapping what
>> route it goes with.
>> Obviously, I'll also somehow have to deal with conflation. Not sure how
>> Another thing I'd like to consider is future route changes. RTD changes
>> their routes 2-3 times per year, and sends out announcements detailing the
>> changes. Sometimes the changes are just schedule changes, which would not
>> change anything in OSM; other times they include topology changes,
>> additional routes, removal of routes, additional stops, etc. I'd like to
>> come up with a process to import those future changes, so that OSM stays up
>> to date with RTD data.
>> Any hints/tips/comments on anything I've said here would be greatly
>> --Derek K
>> Imports mailing list
>> Imports at openstreetmap.org
More information about the Imports-us