- Corey Burger arranged a host of electrons thusly: -
> The NIDs are going to go or be moved regardless, as people move and
> combine objects. Come updates or new data, I really don't think they
> are going to be all that useful. This means we really can't actually
> trust the NIDs, because they made correspond to an object in the
> Geobase data that in our db is something very different.
Short-term the NIDs would be very useful for things like adding
programmatically addressing information to ways in provices which have
it. So there's at least one use-case.
A strange idea might be to move the geobase:uuid to the start & finish
nodes for the geobase segments. Some (or most, really) would have
multiple values in each tag. You'd be able to reconstruct a geobase
segment by finding the other node with the same geobase:uuid tag, and
then looking at the osm way that joins the two. This would be resilient
in the face of joins & moves, etc. I'm not sure how it would behave
when nodes are merged (I suspect that the uuid values would be lost).
Anyway, something for discussion or outright dismissal -- I haven't
thought through the implications on database size, or algorithmic
complexity & stuff.
> Given we have roadmatcher, we can compare relative distances. We can
> also compare road names. These, combined with local knowledge, are
> what we are realistically going to have to rely on.
Hmm, something involving roadmatcher would probably work nicely in the
future. I shudder to think of the resource requirements for loading all
of canada in, and then running a conflation on all that data to produce
the differences file.
peace,
Austin.
--
Build a man fire, he'll be warm for a day.
Set a man on fire, he'll be warm for the rest of his life.
_______________________________________________
Talk-ca mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
