<div class="gmail_quote">I was just reading the recent thread about 64-bit IDs and had a couple thoughts to put out there. 64 bits gives us a really big number space for IDs. We should take advantage of this:<div><br></div>
<div>1. Keeping the current usage of negative IDs costs us only one bit. We are currently only getting 31 bits. The jump to 64 bits actually increases the number space by a factor of 4 Billion even while preserving negative IDs.<div>

<br></div><div>2. How about, as part of the transition to 64-bit IDs, we also shift to a single unique object ID. That is, all changeset IDs would be unique from way IDs which would be unique from node IDs, etc. One of the things the USGS and US Federal Government has learned the hard way is that adopting a truly unique object ID facilitates data synchronization. I'm not at all saying OSM should adopt the crazy UIDs that the USGS is using. What I mean is just allocate all IDs from the same 64-bit number space.</div>

<div>  a. To make the transition, you'd probably want to "hash" the existing object type into the ID. Add a "1" at the beginning for existing nodes, a "2" for ways, etc.</div><div>  b. I'm not a big fan of permanently hashing the object type into the ID, so one sequence in the database would be adequate.</div>

<div><br></div><div>Just some thoughts...</div><div><br></div><div>-Eric</div><div><br></div><div>-=--=---=----=----=---=--=-=--=---=----=---=--=-=-<br>Eric B. Wolf                           <a href="tel:720-334-7734" value="+17203347734" target="_blank">720-334-7734</a><br>
<br><br><br>
</div></div>
</div><br>