[Proj] bugfix PROJ.4 release?

[Clifford J Mugnier]

In regards to "reality checks," the specification written by the United States National Geodetic Survey for map projection transformations is for the maintenance of computational accuracy of plus or minus one-tenth of a millimeter between forward and invese solutions.  Anything "better" than that is silliness and not part of the national specification for the North American Datum of 1983.  (Special Publication Number 5 by James Stem (in pdf format) available from www.ngs.noaa.gov .)
 
I have had to correct junior engineers in the past regarding changing Fortran format statements ... increasing the number of decimal points displayed does NOT increase the accuracy of the input data!  In like fashion, double-double/quad precision/long double accomplishes nothing but expend extra electrons in this particular context.  A googolplex of these computations might save a barrel of oil ... !  :-)
 
Ahem.
 
Cliff Mugnier
LOUISIANA STATE UNIVERSITY

________________________________

From: proj-bounces at lists.maptools.org on behalf of Gerald I. Evenden
Sent: Mon 30-Jun-08 18:32
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] bugfix PROJ.4 release?



On Monday 30 June 2008 2:53 pm, Maciej Sieczka wrote:
> Frank,
>
> Now that the "CPLAtof() - different results than atof()" [1] bug in GDAL
> is fixed, do you think you could regenerate the broken PROJ.4's epsg
> file and provide a bugfix PROJ.4 release?
>
> [1]http://trac.osgeo.org/gdal/ticket/2036
>
> Best,
> Maciek

This is a simple little program I wrote because of the contents of the above
web site:
#include <stdio.h>
#include <float.h>
        int
main(char **argc, int narg) {
        printf("FLT_DIG: %d\n",FLT_DIG);
        printf("DBL_DIG: %d\n",DBL_DIG);
        printf("LDBL_DIG: %d\n",LDBL_DIG);
}
Executing it yields the following results:
FLT_DIG: 6
DBL_DIG: 15
LDBL_DIG: 18

In case you have not guessed, these are the significant decimal digits on my
machine---a 64 Inte---for type float, double and long double.  All work work
that I do does not extend beyond DBL or "double x" and I suspect that the
software producing the results on the web site has about the same
characteristics.

MY burning, yes *very* burning, question is what are data numbers containing
16 digits doing on the display???  And why, why would anyone ever worry that
they do not match to 16 digits???!!!!

Secondly, and probably more importantly, Earth parameters are probably not
more significant than 10 digits (milimeters for radius).  And that is
probably *very* optimistic.

And someone is worried that two procedures that cannot agree to 16 digits??

How about a little reality check folks.

If you want to reduce the "annoying effect" try reducing the format to
say %.4g---and that is overkill.
--
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
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080630/d4353429/attachment.html>