[OSRS-PROJ] Significant digits in parameters

[Gerald Evenden]

Using a larger number of digits in projection parameters will, for a variety of
reasons, not increase the accuracy of the results
For example, the major axis is only spec'd to a 7 digit integer, thus the
accuracy of the x-y values are also only to the nearest meter regardless
of the significant digits of the other parameters.  Note: and a single fraction
digit for Clarke.

Secondly, many projections only approximate the projection because of
truncated series are used in the evaluation.  For example, the meridinal
distance along the central meridian is a truncated sine series.  This series
is used by Transverse Mercator (UTM also).  GCTP and earlier versions
of proj truncated the series so that it was good only to about a centimeter or
so.  I later included a version in proj which is good to about
15+ digits (better than a nano centimeter) by merely adding two or three
more terms.  Another minor point to make is that proj always uses power
series of sine (sin^n(x)) which is somewhat more accurate than the commonly
used multiple angle (sin n (x)) series.

The respective x and y axis values also come from truncated series with
terms obtained from truncated coefficient expressions.

I do not find it necessary to carry parameters to anything more than
what maintains 1 millimeter accuracy of the x-y values and a similar
accuracy in geographic coordinates.  Also, it certainly not necessary
to carry along trailing zeros of rational values (eg 47.5, 47.0, 0.0, ...)

Craig Bruce wrote:

> Paul Ramsey <pramsey at refractions.net> pointed out that the EPSG, et al.
> coordinate-system definitions used in PROJ.4 look like the following:
>
> +proj=lcc +lat_1=47.500000000 +lat_2=48.733333333 +lat_0=47.000000000
> +lon_0=-120.833333333 +x_0=609601.219 +y_0=0.000 +ellps=clrk66
> +datum=NAD27 +to_meter=+0.3048006096
>
> A significant issue here is that all of the numbers appear to be given
> with a fixed format of only nine decimal places (C "%.9f").  I strongly
> recommend that a floating format of 16 significant digits be used instead
> (C "%.16g") because most computations are performed using 'double'
> values and sixteen significant digits is the (close-decimal-equivalent)
> accuracy of this type.  If computations are carried out with only nine
> or so significant digits, then the calculations will be unnecessarily
> imprecise, and this can lead to problems with code that deals with
> floating-point rounding control.
>
> For example, we may want to check if a computed longitude is within
> thirteen significant digits of being equal to another or to some to
> round figure, and the needless imprecision will confound this useful
> functionality.  (Most of the PROJ.4 computations seem to be accurate to
> about 13 digits otherwise.)
>
> The ESRI example:
>
> PROJCS["NAD_1927_StatePlane_Washington_North_FIPS_4601",GEOGCS["GCS_North_Americ
> an_1927",DATUM["D_North_American_1927",SPHEROID["Clarke_1866",6378206.4,294.9786
> 982]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lam
> bert_Conformal_Conic"],PARAMETER["False_Easting",2000000],PARAMETER["False_North
> ing",0],PARAMETER["Central_Meridian",-120.8333333333333],PARAMETER["Standard_Par
> allel_1",47.5],PARAMETER["Standard_Parallel_2",48.73333333333333],PARAMETER["Lat
> itude_Of_Origin",47],UNIT["Foot_US",0.30480060960121924]]
>
> has the right idea.

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.