[Imports] Imports Digest, Vol 22, Issue 3

PJ Houser stephanie.jean.houser at gmail.com
Tue Apr 5 01:35:43 UTC 2011


> Date: Mon, 4 Apr 2011 14:27:13 -0400
> From: Josh Doe <josh at joshdoe.com>
> To: Ian Dees <ian.dees at gmail.com>
> Cc: "imports at openstreetmap.org" <imports at openstreetmap.org>
> Subject: Re: [Imports] Importing Arkansas data
> Message-ID: <BANLkTika-UdpkoyZ7w26E8dXgbsgQK3z5w at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I think we need to be careful when we use the word "import", as it has
> such a loaded meaning on this list.
>
> Rather than thinking about a "continual import", we need to think
> about syncing. I haven't seen much in the way of tools for syncing OSM
> with external databases. It's been mentioned quite a bit as something
> useful, like for sending feedback to the US GNIS on the thousands
> (millions?) of points imported from them, but it doesn't seem to have
> been done.
>
> Does anyone currently sync data with OSM, and if so are the tools
> available? A quick search reveals one such tool, gtfs-osm-sync, for
> syncing General Transit Feed Specification data with OSM, but I don't
> even see this listed on the wiki. Perhaps we can create a page with a
> list of all such sync tools as well as ideas for sync tools (desktop
> and web based). The lowest hanging fruit should be creating a tool to
> sync data between nodes in OSM and an external database. In fact this
> could be a good GSoC project.
>
> -Josh
>

Josh,

At Trimet - transit agency - in Portland, Oregon, we are trying to sync OSM
with our regional jurisdictional data. We use 6 in aerials for confirmation
and derivative work. It's not an import at all. Sync is really the best word
to use for it because it's two way, although the main focus is on making OSM
more accurate and up-to-date. And it's NOT automated - each change is done
by one of 4 interns (I'm one of them!) - we adjust nodes of ways, or add
tags, or change tags, or erase erroneous ways or replace really off ways
(usually trails done by GPS are quite off) with our jurisdictional data (but
we add on OSM tags our data didn't have). If jurisdictional data is
incorrect, we track the IDs and email our contact at the relevant regional
database agency.

I wish there was a utility that did a better job of comparing existing OSM
to our jursidictional data. Currently, we are using ArcMap's OSM Editor to
create "diff" files where we use buffers and select OSM and jurisdictional
data out of sync with each other. Then we put these diff files in JOSM and
edit from there - with aerials. And so far, the diff files are just for
geometric differences, not even topological differences.

A utility that compares attributes and geometry and topology between
jurisdictional data and OSM would be great - but complicated.

We seem to be the first agency doing this type of thing, and it needs a lot
more work and development. We keep finding things in our workflow to change
or tweak. Trimet is employing us because they want to use OSM as their data
source for an open source trip planner! Cool, eh?

--
PJ Houser
Trimet
GIS intern, 503-962-5711 (office)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20110404/cd7bae3a/attachment.html>


More information about the Imports mailing list