[Proj] +towgs84 approximation error

Jochem jochem.lesparre at kadaster.nl
Fri Mar 24 03:29:20 PDT 2017


Hi Martin,

Thanks for your clarifying email.

> Many different coordinate operations can exist for the same pair of CRS.
> In USA, there is about 80 datum
> shift operations from NAD27 to WGS84.

I think we should make a distinction between reference systems and reference
frames here (I assume you are familiar with that). As each frame of a system
will have different parameters. For a frame only one set of parameters is
needed. If these are multiple sets, one could combine the information of all
these stochastic transformations in to one best least-squares estimated set
of parameters.

However, maybe I should nuance my point that it is nonsense to store
multiple sets of parameters also for a frame. There could be different sets
of transformation parameters for one frame to WGS84 exist in practice, but
here are no *mathematical* reasons to store redundant sets of parameters.


> I saw a statement saying that the CRS would be by definition an other CRS
> with the coordinate operation
> defined by the 7 parameters. But I still a little bit surprised by a
> scenario where a derived CRS would be 
> defined by Bursa-Wolf parameters.

For the country where I am working this week, the parameters are not really
by definition (conventional) but official (given) parameters. See the
terminology below my email for the distinction between conventional defined,
official given and self-estimated stochastic parameters.

However, this is the case for the national grid (RD) of the Netherlands. RD
is defined as the transformation (in ISO19111 terminology this would be a
conversion?) from ETRS89, including a 7 parameter transformation, but also
an correction grid on projected coordinates is used:  

ETRF2000(R05) <--7par--> pseudo_NL_Bessel <--proj--> pseudo_RD <--corr-->
true_RD

Since this order of steps is not supported by Proj.4, EPSG etc., this
procedure will probably be updated this year to:

ETRF2000(R14) <--NTv2--> true_NL_Bessel <--proj--> RD

However, I would like to see this possibility in Proj.4, EPSG, etc.:

ETRF2000(R14) <--7par--> pseudo_NL_Bessel <--NTv2--> true_NL_Bessel
<--proj--> true_RD

This would be better for 2 reasons. First, the normal of the NL-Bessel
ellipsoid is closer to the true vertical than the normal of ETRS89. Second,
there are always stubborn users that will use RD outside the bounding box of
the NTv2 grid (using: ETRF2000(R05) <--7par--> NL_Bessel <--proj--> RD). Of
course they should not do that, but I know they will keep doing this and it
is causing nasty problems at the edge of the bounding box. With the the
combination of 7 parameters and a NTv2 grid, the values in the NTv2 grid
could fade out to zero outside the Netherlands and the grid can cover the
entire earth. This would produce complete nonsense for points outside the
bounding box, but at least it will be the same consistent nonsense for all
users without edge effects.


Citation from  Van der Marel, 2016
<http://www.citg.tudelft.nl/fileadmin/Faculteit/CiTG/Over_de_faculteit/Afdelingen/Afdeling_Geoscience_and_Remote_Sensing/Study/CTB3310_TerrestrialReferenceSystems_TRS_2-1a.pdf> 
:
| A big difference between datum transformations and coordinate conversions
is that the
| parameters for the datum transformation are often empirically determined
and thus subject
| to measurement errors, whereas coordinate conversions are fully
deterministic. More specific,
| three possibilities need to be distinguished for the datum transformation
parameters
| 
| 1. The first possibility is that the datum transformation parameters are
*conventional*. This
| means they are chosen and therefore not stochastic. The datum
transformation is then
| just some sort of coordinate conversion (which are also not stochastic).
| 
| 2. The second possibility is that the datum transformation parameters are
*given*, but have
| been derived by a third party through measurements. What often happens is
that this
| third party does new measurements and updates the transformation
parameters occa-
| sionally or at regular intervals. This is also related to the concepts of
| reference system and reference frames. Reference frames are considered
(different) realizations of the
| same reference system, with different coordinates assigned to the points
in the reference
| frame, and often with different realizations of the transformation
parameters. The sta-
| tion coordinates and transformation parameters are stochastic, so new
measurements,
| mean new estimates that are different from the previous estimates.
| 
| 3. The third possibility is that there is no third party that has
determined the transformation
| parameters, and you as user, have to *estimate *them using at least three
common points
| in both systems. In this case you will need coordinates from the other
reference system.
| Keep in mind that the coordinates from the external reference system all
come from the
| same realization, or, reference frame.




--
View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5314039.html
Sent from the PROJ.4 mailing list archive at Nabble.com.



More information about the Proj mailing list