[Talk-ca] [OSM-talk] uStream .tv broadcast 2pm PST 5pm EST - geobase import
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
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.
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
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.
import of massgis data
change coordinates of a node
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.
import of massgis data
osm changes coordinates of a node
massgis changes coordinates of a node
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
Size: 193 bytes
Desc: not available
More information about the Talk-ca