<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 19/07/2022 à 17:10, Giacomo
Cappellini a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CABXJd1nhQuSkXyrZhWpkCWOXpPoGfJKh=SW7D=1ijoa6bLOFnQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Thanks Even, thanks Greg. <br>
</div>
<div><br>
</div>
<div>I now understand why there are no proposed transformations
from RDN2008 to ETRF2000 or ITRF2000.</div>
<div>To get a better picture on the topic I downloaded the EPSG
database and by grepping the available transformations
starting from RDN2008 I've confirmed that "RDN2008 to ETRS89
(1)" and "RDN2008 to WGS 84 (1)" are the only available
transformations according to EPSG authority.</div>
<div><br>
</div>
<div>The only point I miss from the picture is the meaning of
"ENSEMBLE". While I can generally grasp how to move from a
source Reference Frame to a target Reference Frame, I fail to
picture how to move from a Reference Frame to a Reference
System ensemble. I'd like to ask if possible a little more
details about the meaning of "we actually do that manually for
the WGS 84 datum ensemble vs its realizations". </div>
</div>
</blockquote>
<p>See the manually added records starting at
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/PROJ/blob/5b2d59b68f931303d73e742763309d258f9335d4/data/sql/customizations.sql#L187">https://github.com/OSGeo/PROJ/blob/5b2d59b68f931303d73e742763309d258f9335d4/data/sql/customizations.sql#L187</a>.
"manually" here means "not done in code": an alternative would be
to explore the datum ensembles and their members in the database
and figure out the null transformation between them. Given the
relatively low number of datum ensembles in the EPSG database
(essentially only WGS 84 and ETRS89), the manual way is much
easier to implement than new code.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CABXJd1nhQuSkXyrZhWpkCWOXpPoGfJKh=SW7D=1ijoa6bLOFnQ@mail.gmail.com">
<div dir="ltr">
<div>The information I've reached so far about RS ensemble says
that "all but the highest accuracy requirements may be
considered to be insignificantly different from each other"
and "Datasets referenced to the various realizations may be
merged without change of coordinates":</div>
<div>- <a
href="https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#87"
moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#87</a></div>
<div>- <a
href="https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53"
moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#53</a></div>
</div>
</blockquote>
<p>That's what is implemented in the above WGS 84 specific records
with a Helmert transformation with all terms null, or my prior
suggestion for ETRS89 <--> ETRF2000</p>
<p>(to be pedantic we only record transformation from each member of
the ensemble to the ensemble, to avoid the combinatory explosion
of registering transformations between each member. but PROJ is
smart enough to combine 2 (not more) steps to do e.g WGS 84 (<span
class="pl-s">G1674) -> WGS 84 (G1762) as </span><span
class="pl-s">WGS 84 (<span class="pl-s">G1674) -> WGS 84
(ensemble) -> </span></span><span class="pl-s"><span
class="pl-s"><span class="pl-s">WGS 84 (G1762) )<br>
</span></span></span></p>
<blockquote type="cite"
cite="mid:CABXJd1nhQuSkXyrZhWpkCWOXpPoGfJKh=SW7D=1ijoa6bLOFnQ@mail.gmail.com">
<div dir="ltr"><br>
<div>Thanks,<br>
</div>
<div><br>
</div>
<div>G.C.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Il giorno mar 19 lug 2022 alle
ore 13:48 Greg Troxel <<a href="mailto:gdt@lexort.com"
moz-do-not-send="true" class="moz-txt-link-freetext">gdt@lexort.com</a>>
ha scritto:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Even Rouault <<a href="mailto:even.rouault@spatialys.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
writes:<br>
<br>
> For RDN2008, there are 2 transformations available:<br>
><br>
> - one from RDN2008 to ETRS89 (EPSG:4258), with a null
Helmert<br>
> transformation and a accuracy of 0 m. This is consistant
with how you<br>
> described RDN2008, and this transformation has the
comment "RDN2008 is<br>
> the second Italian realization of ETRS89"<br>
<br>
A far more lengthy way forward might be:<br>
<br>
Italian geodetic authorities (whoever defined RDN2008)
publish a<br>
transformation from RDN2008 to some modern ETRFyyyy,
including an<br>
error estimate.<br>
<br>
They submit that to EPSG for inclusion.<br>
<br>
A new EPSG version is published.<br>
<br>
A proj release arrives with the new EPSG version.<br>
<br>
Meanwhile, you wait for the previous 4 steps.<br>
<br>
I realize it doesn't solve your problem now, but authoritative<br>
transforms with tight error estimates shorten the transform
pipelines<br>
that are used and lead to better answers. The above avoids
ETRS89.<br>
<br>
> Afaik, RDN2008 is ETRS89 realization ETRF2000 epoch
2008.0.<br>
<br>
If you believe that precisely, you could just relabel your
data as being<br>
ETRF2000 (assuming the standard epoch is 2008.0).<br>
<br>
Or insert a transform similar to Even's sugggestion, perhaps
with better<br>
accuracy. I would expect RDN2008/ETRF2000:2008.0 to be at the
0.01m<br>
level -- but I am pretty clueless about ETRF details.<br>
<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>