CTABLEs are arch dependent

[proj4-bot]

Reported by frankie on 29 May 2009 18:15 UTC
It would be useful having an arch-independent format used for the CTABLE files. That would allow moving/sharing files among multiple platforms without unexpected results.

Migrated-From: https://trac.osgeo.org/proj/ticket/44

[proj4-bot]

Comment by hawkinsp on 7 Aug 2010 20:38 UTC
The fact that the CTABLE files are architecture dependent causes surprising results on Mac OS. It is common to build "universal binaries" on Mac OS, where multiple architectures are combined into the same binary (e.g. x86 and x86-64). Unfortunately the datum shift files are not compatible between architectures, so a universal binary will silently produce invalid datum shift transformations on at least one architecture. This is particularly confusing on Snow Leopard, under which recent machines can execute both x86-64 and x86 binaries.

I just spent some hours hunting for invalid datum shifts in my code; I had been using grids generated for x86-64 together with a binary built for x86 on the same machine. Since sizeof(int) == 4 on x86 and sizeof(int) == 8 on x86-64, the CTABLEs (in particular the layout of struct ILP) are incompatible even though both are from the same machine. It would be good to at least document this behavior if not to fix it.

I note that the Macports build of proj4 incorrectly builds only one set of datum shifts for a universal binary, so clearly I'm not the only one who didn't realize this.

[busstoptaktik]

Can this be closed? Are all PROJ.4 distributed files now arch independent CTABLE2 versions?

[kbevers]

As far as I can tell, yes. We should also consider removing the code that reads the arch-dependent CTABLE files. I haven't looked into the impact of this, but my immediate thought is that it is straight forward.

[sebastic]

I think the code for ctable format files can stay to keep support for old grid files.

This issue can be closed in my opinion too. The ctable2 format is used since proj-datumgrid-1.6RC1.

[kbevers]

I think the code for ctable format files can stay to keep support for old grid files.

Usage of the old files will go towards zero, so at some point in the future we will have code that is never used. I don't like that. In my view the less lines of code to maintain the better. Exactly when the right time to remove the CTable code is up for debate. In general the grid reading code could use a big overhaul, so when someone gets round to do that they can also remove the CTable stuff. I am planning on creating a bunch of issues for stuff to do in 6.0.0 and 7.0.0. I will keep this in mind when I do that.