In PROJ.4 trunk I have modified pj_init.c and nad2bin.c to produce
and consume a new datum shift format - "ctable2" format. This is
a variation of the existing ctable format with a magic string prefix
in the header, all fields are in little endian byte order, and with
predictable offsets to the header fields. This is to avoid the platform
specficness of files produced by nad2bin.
Incidentally nad2bin can now also produce NTv2 format files.
I was going to just switch to them, but because NTv2 carries
along error values for every grid entry it is twice as large as the
corresponding ctable format grid shift files even though I just
had to use zero for the error estimates. Given that these files
might be pushed around quite a bit I didn't feel right about the
I'd do not have easy access to a big endian test system right
now, but I'd like to confirm the byte order handling. If someone
wants to try things on a big endian system (like Solaris on Sparc)
do the following steps: