[gdal-dev] Call for discusson on RFC 31 - OGR 64bit Integer Fields and FIDs

[Even Rouault]

Daniel,

> 
> This may not be true on all platforms, but at least with GCC, we get
> warnings in a case like this, e.g.
> 
> 
> #include <stdio.h>
> #include <stdint.h>
> 
> int main()
> {
>    int64_t id=10;
> 
>    printf ("%d %s\n", id, "test");
>    return 0;
> }
> 
> 
> $ gcc -Wall ttt.c -o ttt
> ttt.c: In function 'main':
> ttt.c:8: warning: format '%ld' expects type 'long int', but argument 2
> has type 'int64_t'
> 
> > I've taken that approach from Frank's initial draft and that seamed a
> > valid concern. That said, if you guys think that changing the return
> > type is better, I've no strong mind.
> 
> I don't feel that strongly about it. I was mostly wondering if there
> would be a way to avoid the *64() suffixes.

Yes GCC nicely warns. I don't think MSVC does, but oh well people building on 
Windows are used to self-inflicted pain ;-)

So I've renamed GetFID64() -> GetFID() and GetFeatureCount64() -> GetFeature() 
in latest commit : 
https://github.com/rouault/gdal2/commit/40eb13bb9e2a4c86df9d3cf4d030ab14d67749d5

> 
> >> Also note that in the list of driver upgrades, you could add potential
> >> enhancement to the support for MITAB "TAB Seamless Tables" which had a
> >> potential FID overflow problem on very large tables with 32 bit ids. The
> >> driver would have caught and reported an error in this case, but that
> >> limitation can be solved with 64 bit ids if/when the code is upgraded to
> >> use them. Look for TABSeamless::EncodeFeatureId() and related methods in
> >> mitab_tabseamless.cpp.
> > 

I've made changes in TABSeamless and now builds a 64 bit FID  with the upper 
32bits being for the index table and the lower 32bits for the feature within 
the table.
Looking at the code, I've manually forged a simple seamless table and added it 
in autotest.
https://github.com/rouault/gdal2/commit/a922228eff8d0b07918db520de142154e8454f6a

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com