On 7 June 2010 19:22, Frederik Ramm <frede...@remote.org> wrote: > This could lead to an inflation of UUIDs on the object, and everyone who > changes the object will have to decide which of them to keep, which to move, > which to delete. For example, a restaurant would have one UUID for the > building it is in, one UUID for the chef, one UUID for the pretty barmaid > and so on - one UUID indeed for every single property someone wants to link > to. Then if you, as a mapper, find that the restaurant has moved across town > you'll have to find out what to do with these UUIDs (or, more likely, you'll > just leave them alone).
By occupant I meant the business, not people... As for what to do about the UUID, Peter has already pointed out solutions to the issue, think of the UUIDs as a lookup table to speed up searching inside a bbox every time you want to locate an object... > Because if you link to a restaurant because it has a nice location, then > changing the location would mean that the link is invalidated; if you link > to the restaurant because of the chef, then not. You might also link to a > restaurant because of the name (e.g. "Surprisingly, Hamburg has three > restaurants named 'Chez something'...") - in which case the link would have > to survive a move and a change in chefs but not a change in name. I'm not talking about people, but the business occupying the building, not the chef or the head waiter nor the ..... > Is German English really so different from Australian English ;-) It would certainly seem so. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
