[Imports-us] import maintenance

Serge Wroclawski emacsen at gmail.com
Fri Jan 11 14:37:12 GMT 2013


On Fri, Jan 11, 2013 at 7:35 AM, Richard Welty <rwelty at averillpark.net> wrote:
> i think it'd be good if we also talked some about how data is to be
> maintained/updated after
> an import occurs. address data and building footprint data is not static. we
> should be trying to
> build relationships with the data sources (County GIS departments or
> whoever) and have
> a general plan for how OSM should keep pace with reality.

Richard,

Do you have any specific datasets or issues in mind?

My suspicion is that the techniques we use will be heavily dependent
on the types of data we're working with, and that as we encounter the
same types of data (building, address, road, water) that we'll be in a
good position to learn from the past and make the process better.

Our biggest challenge, as always is to handle when a user adds their
own data, or else modifies the imported data in unexpected ways.

For example, in working with the TIGER data, I've seen many examples
of users modifying the tiger: tag values.

This (and other experiences) lead me to the belief that unique object
identifiers or other tags can't be relied upon post import, and any
conflation steps need to be done using the same technique that one
might do if starting a conflation step from scratch.

Building and address data are particularly interesting since we'll
usually want them together (ie in most cases we have a 1:1 building
<-> address relationship), so when adding addresses, we'll want to add
them on the buildings, and if we're adding buildings, we'll want to
add addresses if possible (and possibly use addresses as a method for
conflation).

But I think the solution for us is to not spend as much time thinking
abstractly as we do practically, focusing on the issues of imports as
they come in and then generalizing from our experience.

- Serge



More information about the Imports-us mailing list