> -------Original Message-------
> From: geographika <[email protected]>
> To: [email protected]
> Subject: Re: [gdal-dev] RFC 31 - OGR 64bit Support
> Sent: Nov 27 '10 06:17
>
> Hi,
>
> As I understand it the only reason to use 64bit integers for IDs would
> be for tables with more than 2 billion records (in the positive range).
> There is a related question on StackOverflow about this
> http://stackoverflow.com/questions/2124631/sql-server-int-or-bigint-database-table-ids
> Are there really feature classes with this many records in existence?
Not a very long time ago some people thought that two numbers was enough to
store dates and we got in trouble for that. For example, automatic sensors
capture much more data then we need before we can filter it. Another point is
that users could very well decide to use codes on IDs rather than just
sequential values. It is better be prepared than sorry. But I understand you
point.
Best regards,
> Regards,
>
> Seth
>
>
> On 26/11/2010 17:59, Frank Warmerdam wrote:
> > Folks,
> >
> > In the interest of moving towards a GDAL/OGR 1.8 release I have done some
> > work on RFC 31 - 64bit integers for OGR fields and FIDs. I've updated
> > the
> > RFC itself somewhat, and done a preliminary implementation of the RFC on
> > my own system with a reasonable level of success.
> >
> > I'm asking for additional comment on the RFC at:
> >
> > http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64
> >
> > The implications and complications of this update are greater than I had
> > first anticipated and even with what I've done so far I'm sure lots of
> > additional glitches will come out of the wood work. Unfortunately, this
> > is not funded work for me so it is hard to apply the level of effort that
> > I would like to it. In short, I'm a bit nervous about implementing this
> > RFC though now that I've sunk 2-3 days into the prototype work I'm
> > hesitant
> > to throw it away either. :-)
> >
> > Thoughts welcome.
> >
> > Best regards,
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
