[Proj] The trouble with grid datum correction files

Gerald I. Evenden geraldi.evenden at gmail.com
Sun Jul 5 13:49:25 EST 2009


On Sunday 05 July 2009 1:31:47 pm Karl Swartz wrote:
> > > (http://en.wikipedia.org/wiki/Endian#Endianness_in_networking ).
> >
> > For the moment, I do not think we should concern ourselves with binary
> > data *and* network protocol.  This introduces an additional complex
> > layer ...
>
> If a problem has already been solved in one space, it seems silly to
> blindly reinvent the wheel.  In various binary formats I've developed,
> borrowing the nton{s,l}() routines from the networking space is simple
> and portable.

The matter of conversion is not an issue to me other than the nuisance *and* 
that if one is to develop transportable software it brings up the issue of 
*another* damn machine dependent factor to test in transferring code.

> > At the moment what bothers me most is the fact that I have the strong
> > feeling that those who assembled these data bases were either ignorant
> > of the problem or chose to ignore it.
>
> Given that some of these formats may have their roots in times when CPU
> cycles (to convert data) were precious and networking was a research
> project, you may not be too far off the mark because there was no more
> near-term need than there was for four-digit years.  Look at the number
> of files in the petromeum exploration space that use EBCDIC, 370 FP
> formats, and are sized to fit on a 3390 tapes!

Good ol' EBCDIC.  I haven't thought about that in eons.  I used to keep a card 
list of it as a souveneer.

Getting back to the case at hand: what principally concerns me is that endian 
was not specified as part of the details of format description of the NT2v 
format and I think that that factor needs to be addressed by the powers in 
control of the format.  Same with the US files.  What I was hoping for was 
that there were some in this group who might have some clout with those who 
control these formats and put a bug in their ear.

The Swiss distribution, chenyx06.zip, makes strong case for ASCII 
distribution.  The compressed ascii version of the NTv2 file is a few bytes 
smaller than the original binary.  No endian problems here!

The Swiss always seem to have their act together.

gie at charon:~/NEW_CARTO/geodesy/gridcon$ m CHENYX06.asc
NUM_OREC 11
NUM_SREC 11
NUM_FILE  1
GS_TYPE SECONDS
VERSION NTv2.0
SYSTEM_FCH1903
SYSTEM_TCH1903+
MAJOR_F  6377397.155
MINOR_F  6356078.963
MAJOR_T  6377397.155
MINOR_T  6356078.963
SUB_NAMECHENyx06
PARENT  NONE
CREATED 08-06-12
UPDATED 08-06-12
S_LAT     163680.000000
N_LAT     173040.000000
E_LONG    -39780.000000
W_LONG    -19980.000000
LAT_INC       30.000000
LONG_INC      30.000000
GS_COUNT206893
  -.000001   .000002   .001000   .001000
  -.000001   .000002   .001000   .001000
   ...

The rediculous thing is having a "-" in front of the longitude values, but 
that is not the Swiss' fault.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist


More information about the Proj mailing list