<br><br><div class="gmail_quote">On Tue, May 24, 2011 at 10:52 AM, Jochen Topf <span dir="ltr"><<a href="mailto:jochen@remote.org">jochen@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>
One problem with 64bit IDs is simply that they need twice as much space. If you<br>
store a billion node IDs that might be the difference between needing 4GB of<br>
RAM or 8GB. So I think it is worth it trying to live with 32bit IDs as long<br>
as possible. Hardware is getting cheaper. So preserving 32bit IDs for a year<br>
longer might mean investments can be postponed and/or we can actually do things<br>
we could not do otherwise, because there is no money for more hardware.<br>
<br><br>
And while we are at that subject: There is another problem here. Most of the<br>
usual GIS software uses 32bit IDs, when using QGIS with Postgres for instance<br>
it would not accept a 64bit Postgres ID column. (This might have been fixed in<br>
the mean time, I haven't checked for a while.) I have talked about this on<br>
several occasions to the people who work on these projects and they all said,<br>
they'd work on it. But in the meantime there is an awful lot of software<br>
around that can't handle this case.<br>
<br></blockquote><div> </div><div>Things usually get fixed only when they are broken. So until we actually move to 64bit and force things to happen I doubt most GIS software will be ready for it. Postponing this for one year won't make much difference in that regard.</div>
<div>As for the storage aspect of things, I can agree with you. But I'm not sure introducing a temporary system will be cheaper than investing in more storage. Hardware is getting cheaper, but human labor isn't. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Oh, yes, and shapefiles only allow 32bit IDs.<br>
<div class="im"><br></div></blockquote><div><br></div><div>This could be a more serious issue. I guess in the history of GIS there has never been such a large geo database as OSM is now becoming. Maybe we (as the OSM community) should take a proactive stance and propose a new version of shapefile format that could cope with 64 bits. Yes, I know this is daydreaming, but shapefile format is getting old anyway. Something using protocol buffers could be a new way to go - easier to write readers and writers and taking less space, too.</div>
<div><br></div><div>Igor</div><div> </div></div>