RE: [open-civic-data] Digest for open-civic-data@googlegroups.com - 2 updates in 1 topic

34 views
Skip to first unread message

Karl Nicholas

unread,
Feb 19, 2016, 7:59:25 PM2/19/16
to open-ci...@googlegroups.com

Perhaps someone can submit this to CodeForAmerica.org and see if someone there is interested in working with a Gov’t sponsor on this.

 

From: open-ci...@googlegroups.com [mailto:open-ci...@googlegroups.com]
Sent: Friday, February 19, 2016 7:46 PM
To: Digest recipients <open-ci...@googlegroups.com>
Subject: [open-civic-data] Digest for open-ci...@googlegroups.com - 2 updates in 1 topic

 

·         OCD ID to OpenStreetMap ID - 2 Updates

jamespete...@gmail.com: Feb 18 05:14PM -0800

I don't know of this existing, but I'd be interested in this as well!
 
On Thursday, February 18, 2016 at 4:50:47 PM UTC-5, Steve Yang wrote:

Pat Tressel <ptre...@myuw.net>: Feb 19 12:11AM -0800

> Hi, does anyone know if we have any way to map OCD-ID to OpenStreetMap ID
> (or the other way around)? It would be useful to combine datasets using
> different systems.
 
The IDs for OSM objects (ways, nodes, relations) are automatically-assigned
and have no meaning outside of OSM -- they're like database serial number
primary keys.
 
http://wiki.openstreetmap.org/wiki/Node
http://wiki.openstreetmap.org/wiki/Way
http://wiki.openstreetmap.org/wiki/Relation
 
Meaningful metadata, beyond location, in OSM is stored in tags -- key-value
pairs -- associated with objects. For instance, a city might have a
relation that is its administrative boundary, and be tagged with name:<name
of city>. Here's an example -- the city of Mercer Island, WA -- you can
see the name key in the list of tags, with value Mercer Island.
 
http://www.openstreetmap.org/relation/237360
 
A relation is a grouping of objects into some meaningful unit. Most
administrative units (countries, states, etc.) are relations, as are some
larger physical features. Small objects like buildings, and sections of
roads and waterways, are often just ways. An isolated node might be used
to provide a label for an object that does not have a more detailed
relation -- for instance, a small village that does not have a mapped
border might have its name attached to a node in the center of the village.
 
If you know the type of object you want, and its official name (preferably,
with no abbreviations), you can do a query using Nominatim:
 
http://wiki.openstreetmap.org/wiki/Nominatim
 
It will return all matching objects, and tolerates some ambiguity. It does
understand the location hierarchy, so if a name is used in multiple places,
one can add higher levels. For instance, when I searched for Mercer
Island, I used the string "Mercer Island, WA".
 
So, one option would be to query OSM by name. If you have names in a clean
enough format, that might be sufficient.
 
For a different project, we talked about methods of matching up objects,
and the tentative plan was to use a "ref" tag. This is a tag where the key
is ref:<type of external ID> and the value is the external id as a string.
Here's an example of such a tag, for library IDs.
 
http://wiki.openstreetmap.org/wiki/Key:ref:isil
 
So, OCD might use a key like ref:ocdid (assuming that's not already taken),
and then start the laborious job of matching up OCD records with OSM
objects, and annotating the OSM objects with their OCD IDs.
 
The first step might be partly automated: Using names of OCD objects,
query Nominatim, and record the returned records. Carefully crafting the
query will reduce extraneous objects. Some returned objects could be
dropped, e.g. if you get both an admin boundary relation and a simple node,
only keep the relation. Dump the results into some convenient form, like a
spreadsheet / CSV file.
 
I can stop you right now about any ideas of "automating" that second
step... :D Any "bulk upload" has to go through an approval process, and
has to have human eyes on it, to make sure nothing is going wrong. I'd
recommend getting advice from some experienced OSM mappers who have
shepherded uploads through approval, talk to them about what's needed.
Then, it would likely be a matter of having work parties to enter the
data. Organizations with data in OCD might want to handle this for their
own data, or one might organize "mapathons". This can go quickly, with
good training. The usual workflow is to have people enter information for
a small region, to avoid conflicts, and then to have another mapper review
the work.
 
Best way to engage OSM folks initially about this is probably IRC --
irc.oftc.net channel #osm. Secondarily, one might use one of the mailing
lists. But that could spam a lot of people... On IRC, post a question,
and then just hang out there til someone eventually answers. ;-) There
are about 240 people in channel right now, and a fair number are highly
experienced.
 
Another option would be to store OSM IDs in OCD. I don't recommend that,
since OSM IDs could change, if the object is deleted and re-created. That
(probably) won't happen to long-standing objects like major administrative
regions. But if some object has to be significantly altered (e.g. a
village node replaced by a boundary relation), then the original object
will be deleted. (The deleted object will still be there, marked deleted,
so a lookup using it can still succeed. But the data will be stale -- it
was deleted for cause -- and increasingly more so over time.) The tags
from the original object will be copied onto the new object (if the mapper
who is updating the object is Doing it Right), so ref:osmid tag would
survive.
 
Before starting the process with OSM, it would be good to judge the level
of interest in the OCD community for doing this, and also evaluate whether
queries by name, using the Nominatim API, or queries by location to OSM,
are good enough.
 
If you want to chat on IRC with OSM folks, and want a "translator", let me
know when you're going to be on IRC. My nick is same as the username part
of my email address.
 
-- Pat

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to open-civic-da...@googlegroups.com.

 

Reply all
Reply to author
Forward
0 new messages