- 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 Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca