[Proj] The trouble with grid datum correction files
Gerald I. Evenden
geraldi.evenden at gmail.com
Sun Jul 5 11:49:25 PDT 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