[Proj] +towgs84 approximation error

[Thomas Knudsen]

Hi Jochem,

You say that you would like to do
    ETRF2000(R14) <--7par--> pseudo_NL_Bessel <--NTv2-->
true_NL_Bessel<--proj--> true_RD
In Proj.4

This will, as far as I can see, be possible with the Proj.4 pipeline
implementation, when
Kristian's latest pull request "Horisontal and vertical gridshift drivers "
(cf. https://github.com/OSGeo/proj.4/pull/492 ).

Actually most of what has been mentioned in this thread (and the
neighbouring thread about
dynamical reference systems) is possible using the transformation pipeline
framework, which
Kristian and I have been designing and implementing over the last few
months.

We're making progress, but we're flooded with other tasks as well, so time
allocated to building this
is limited. The plan is, however, to retire our old and venerable
transformation software, trlib
(https://bitbucket.org/KMS/trlib ), so we have no other way to go than to
extend Proj.4 with a full
geodetic framework.

The ubiquity of Proj.4 also means that, realistically speaking,
extending Proj.4 in this way will also be the only viable road to provide
"longterm centimeter accuracy to everyone, everywhere".

But this is just the first step: Once Proj.4 is capable of handling generic
geodetic transformations,
we will have a long process going making the downstream application
projects actually making
that available to end users. Here, we will have to depend on end-users
actually reqiring and
requesting that support.

/Thomas




2017-03-24 11:29 GMT+01:00 Jochem <jochem.lesparre at kadaster.nl>:

> 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.
> _______________________________________________
> 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/20170324/7c432d6c/attachment.html>