[Talk-ca] [OSM-talk] uStream .tv broadcast 2pm PST 5pm EST - geobase import

Greg Troxel gdt at ir.bbn.com
Mon Jan 26 14:39:23 GMT 2009


Sam Vekemans <acrosscanadatrails at gmail.com> writes:

> The result is a set of friends names and addresses where for each friend,
> all their addresses; phone numbers would be available on the same entry.
>
> So in OSM terms, all the OSM user created data & references, would be shown
> on the same Node/way with the imported tags. So NO user data would actually
> be removed.
>
> Does this make sense?

Sort of, but I'm afraid that one really has to write out processing
rules to be confident, or maybe that's just the way my brain works.  I
have been thinking about something like this for a long time, to manage
my own collection of waypoints, but never implemented it.  osm is far
ahead of what I had been thinking in terms of database management.

I think of upstream databases like the vendor branch in CVS.  It's
imported, and then there are local edits.  New versions are imported and
merged.

Here's a few use cases to frame the 2nd-import.  I'll talk about massgis
because that's my local upstream data source, and I've recently fixed
some errors in it.

Case 1:

  import of massgis data (I thought this was tagged by a regular user
    crschmidt, but it's tagged as an import user as Russ noted earlier;
    other massgis data was import by Chris as himself)

  I fixed the name, and then the classification
    http://www.openstreetmap.org/browse/way/9354852/history


Now, let's assume that there's a new import of massgis data next year.
If this entry has not changed at all since the previous import, nothing
should happen.  If it has, there's a conflict to be resolved, perhaps
manually.  Having a literal diff with the previous import state in the
history, after looking up the way via the massgis way key, would make
most operations automatic.  Attributes that had not been edited could be
changed if they still matched the previous import, but not if they
didn't match the old import.

Case 2:

  import of massgis data

  change coordinates of a node

  re-import

    here, the new massgis coordinates don't match osm, but the new
    massgis coordinates match the old massgis coordinates.  So the right
    answer is to do nothing.

Case 3:

  import of massgis data

  osm changes coordinates of a node

  massgis changes coordinates of a node

  re-import

    here, the the new ones, the old ones, and the osm ones are all
    different.  This is an interesting conflict, and it would be good to
    look at it.


Hope this is helpful - after typing it it seems less helpful than I
thought it was going to seem.



It would be really nice to have way to diff the new massgis import
against the state of the database, and against the old import.

I wonder about trying to feed changes back to someplace like MassGIS.
I'm sure they have source auditing rules, but it could put things on
lists for them to recheck based on field reports that they aren't right.


(I realize this is talk-ca, which I'm not on and i'm talking about
massgis, but I think the principles are the same.  enough from me...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20090126/fab8b3de/attachment.pgp>


More information about the Talk-ca mailing list