Hi Jason,
I like your idea of doing each feature set separately. I think I will do
that.
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.
--Derek
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
it.
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.
https://github.com/jremillard/osm-import-toolkit/blob/master/README.md
Thanks
Jason
On Mon, Aug 26, 2013 at 7:35 PM, Derek Kniffin <[email protected]> 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
yet...
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
appreciated.
Thanks!
--Derek K
_______________________________________________
Imports mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/imports
_______________________________________________
Imports-us mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/imports-us
