<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you edit a road, a new one would be created and would point to its<br>
invalidated ancestor. Recursively chasing previous ID pointers, you<br>
would eventually have an object without an ancestor. ID of that object<br>
would also be permanent ID of the successor objects. This will also<br>
solve road split problems as multiple objects can point to the same<br>
ancestor.<br></blockquote></div><br></div><div class="gmail_extra">Erikn, if I understood you correctly, you are proposing the data structure to generate and track IDs.  I think there are several issues:</div><div class="gmail_extra">* determining feature ID requires O(N) - linear search through history.</div><div class="gmail_extra">* given an ID, if you want to examine what it points to, you have to assemble the whole tree of descendants to determine all of the leafs, and test if they still exist or were deleted. Which also means that instead of a human-currated single relation for the multi-segment road, and a single list of tags, you are now looking at a set of objects, each with its own list of tags.</div><div class="gmail_extra">* Download must contain an entire OSM change history to work with the IDs offline</div><div class="gmail_extra"><br></div></div>