<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Duncan,<div><br><div>WGS84 or EPSG 4326 is a global CRS that uses longitudes and latitudes. It uses the WGS ellipsoid. Distances are measured in degrees. UTM zones for WGS84 (or universal Transverse Mercator) is based on EPSG 4326 and uses meters instead. Meters North- South are calculated in meters from the equator, as determined by EPSG 4326 and meter EAST - Ouest and determine east and ouest from a specific latitudes as determined by ESPG 4326. The zones spans 6 degrees. </div><div><br></div><div>Geiod on the other hand give you a model of gravity. Is basically tells you where the average sea level should be anywhere on earth. There are many models because a)you need to agree on the centre or the earth, you need to agree on the best ellipsoid to use, you need to agree on the average sea level, you need to measure the gravity on earth. The centre of the earth and the level of gravity change as models get better with newer data (ei satellites data vs ground level data)... Therefore, models change as the knowledge improves.</div><div><br><div dir="ltr">Nicolas Cadieux<div><a href="https://gitlab.com/njacadieux">https://gitlab.com/njacadieux</a></div></div><div dir="ltr"><br><blockquote type="cite">Le 18 avr. 2021 à 11:25, Duncan Agnew via PROJ <proj@lists.osgeo.org> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>As an onlooker, I have a question: what is UTM/WGS84 intended to mean? Is it (A) the UTM projection using the WGS84 ellipsoid</div><div>as a parameter, or (B) is it meant to imply also that the coordinates are in a datum that is one of the several labelled WGS84? A is clear and completely unambiguous; B isn't, partly because it is subject to change as data are collected (not to mention plate motions). Data-dependence is also a problem with geoid models: it is why there are so many, after all.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 18, 2021 at 2:51 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Yes, I assume that the large number of codes that should be
created, and still for relatively marginal use cases, is what
makes IOGP refrain from doing that.<br>
</p>
<p>What you describe is exactly the not so known OGC URN syntax for
combined objects (see OGC 07-092r2, para 7.5.4 :
<a href="https://urldefense.com/v3/__https://portal.ogc.org/files/?artifact_id=29533__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718H5HVjC4$" target="_blank">https://portal.ogc.org/files/?artifact_id=29533</a> )<br>
</p>
<p>For example for UTM 31N / WGS 84 (G1762), that is<br>
</p>
<p>urn:ogc:def:crs,crs:EPSG::9057,cs:EPSG::4400,coordinateOperation:EPSG::16031</p>
<p>and you can use that with projinfo / proj_create()</p>
<p>If you use that in GeoTIFF, what would be missing though is the
coordinate epoch. You'll have to store it in a TIFF tag. There's
no way in the GeoTIFF encoding itself to store it.<br>
</p>
<p>Even<br>
</p>
<div>Le 18/04/2021 à 09:20, Lesparre, Jochem
via PROJ a écrit :<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span lang="EN-GB">This is indeed a major
problem with (the way most software and people are using)
EPSG. By just using EPSG CRS codes, one needs a unique EPSG
CRS code for every possible combination of datum and
projection. However, the number of possible combinations is
way too large. I think, the solution is to split the datum
definition (WGS84, WGS84G1762, ITRF2014, ETRF2000, etc.) and
the projection definition (UTM, pseudomercator, LAEA, LCC,
etc.). For the datum definition one can use the normal EPSG
CRS codes. For the projection definition one could use the
lesser known EPSG conversion codes, e.g. EPSG conversion
code 16031 (<a href="https://urldefense.com/v3/__https://epsg.org/conversion_16031/UTM-zone-31N.html__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718m8HlkqY$" target="_blank">https://epsg.org/conversion_16031/UTM-zone-31N.html</a>)
for UTM zoned 31N. Isn’t this the approach used in WKT
strings?</span></p>
<p class="MsoNormal"><span lang="EN-GB"> </span></p>
<p class="MsoNormal"><span lang="EN-GB">Jochem
</span></p>
<p class="MsoNormal"><span lang="EN-GB"> </span></p>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> PROJ <a href="mailto:proj-bounces@lists.osgeo.org" target="_blank"><proj-bounces@lists.osgeo.org></a>
<b>On Behalf Of </b>Noel Zinn (cc)<br>
<b>Sent:</b> zaterdag 17 april 2021 23:59<br>
<b>To:</b> Javier Jimenez Shaw
<a href="mailto:j1@jimenezshaw.com" target="_blank"><j1@jimenezshaw.com></a><br>
<b>Cc:</b> proj <a href="mailto:PROJ@lists.osgeo.org" target="_blank"><PROJ@lists.osgeo.org></a><br>
<b>Subject:</b> Re: [PROJ] World UTM in a proper datum</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal"><span>We really need two codes, don’t
we? One for the geographical datum (ITRF2014 in
GRS80, which is EPSG:7789 in your case) and one for
the projection UTM in GRS80 (which, I guess, doesn’t
exist), perhaps an EPSG architecture problem. To be
frank, your expectation that the EPSG do for ITRF2014
what it’s done for WGS84/UTM is unrealistic. Add
ITRF2008 and so on, how many combinations would that
be?</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span>
<a href="mailto:j1@jimenezshaw.com" title="j1@jimenezshaw.com" target="_blank">Javier Jimenez Shaw</a>
</span></p>
</div>
<div>
<p class="MsoNormal"><b><span>Sent:</span></b><span>
Saturday, April 17, 2021 3:56 PM</span></p>
</div>
<div>
<p class="MsoNormal"><b><span>To:</span></b><span>
<a href="mailto:ndzinn@comcast.net" title="ndzinn@comcast.net" target="_blank">Noel Zinn (cc)</a>
</span></p>
</div>
<div>
<p class="MsoNormal"><b><span>Cc:</span></b><span>
<a href="mailto:PROJ@lists.osgeo.org" title="PROJ@lists.osgeo.org" target="_blank">proj</a> </span></p>
</div>
<div>
<p class="MsoNormal"><b><span>Subject:</span></b><span>
Re: [PROJ] World UTM in a proper datum</span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span>Hi Noel, </span></p>
<div>
<p class="MsoNormal"><span>If I am the only user of
the data, I can do that (and whatever I want). But
if I have to produce accurate data processed by
somebody else, I fall into the hole of vagueness
of WGS84. For instance, if I create a precise
GeoTIFF and I want to tag it with an EPSG, using
EPSG:326XX is... vague. Or a GCP, or anything
else. There are several alternatives for the
geographic crs.</span></p>
</div>
<div>
<p class="MsoNormal"><span>I know I can apply UTM over
ITRF2014 (GDAL does it easily). But there is no
EPSG code for that.</span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span>.___ ._ ..._ .. . ._.
.___ .. __ . _. . __.. ... .... ._ .__<br>
Entre dos pensamientos racionales <br>
hay infinitos pensamientos irracionales.</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span>On Sat, 17 Apr 2021 at
22:24, Noel Zinn (cc) <<a href="mailto:ndzinn@comcast.net" target="_blank">ndzinn@comcast.net</a>>
wrote:</span></p>
</div>
<blockquote>
<div>
<div>
<div>
<p class="MsoNormal"><span>Unlike an
empirically-derived datum transformation
(e.g. WGS <> ITRF), which can have
different levels of "accuracy" depending how
it was derived, a map projection (lat/lon
<> N/E) is defined mathematically and
is precise, i.e. without error. Having said
that, there are better and worse algorithms
for UTM, but that's not the question you're
asking. In a datum transformation sense UTM
will always be as (and only as) "accurate"
as the geographicals you convert to N/E.
So, use EPSG:326XX and EPSG327XX, but plug
in your precise geographicals. </span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span>From:</span></b><span>
<a href="mailto:j1@jimenezshaw.com" title="j1@jimenezshaw.com" target="_blank">Javier
Jimenez Shaw</a>
</span></p>
</div>
<div>
<p class="MsoNormal"><b><span>Sent:</span></b><span>
Saturday, April 17, 2021 2:44 PM</span></p>
</div>
<div>
<p class="MsoNormal"><b><span>To:</span></b><span>
<a href="mailto:PROJ@lists.osgeo.org" title="PROJ@lists.osgeo.org" target="_blank">
proj</a> </span></p>
</div>
<div>
<p class="MsoNormal"><b><span>Subject:</span></b><span>
[PROJ] World UTM in a proper datum</span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span>Hi </span></p>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Maybe there is
a better place to talk about this, but
I do not know which one. I hope
somebody from EPSG is reading this,
and may give me a clue.</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>We have talked
many times about the lack of accuracy
of WGS84 (EPSG:4326), the datum
ensemble, etc.</span></p>
</div>
<div>
<p class="MsoNormal"><span>The problem is
that I miss an accurate equivalent of
the projected family "WGS84 / UTM zone
XXY"(EPSG:326XX and EPSG327XX) for XX
between 1 and 60 and Y is N or S. It
would be nice something similar (a
worldwide projected CRSs on UTM), but
over a proper accurate and well
defined geographic CRS (ITRF2014,
WGS84(G1762), etc).</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Do you know if
there is any plan? Or do they exist
and I was not able to find them?</span></p>
</div>
<div>
<p class="MsoNormal"><span> </span></p>
</div>
<div>
<p class="MsoNormal"><span>Thanks.<br>
</span></p>
<div>
<div>
<p class="MsoNormal"><span>.___ ._
..._ .. . ._. .___ .. __ . _. .
__.. ... .... ._ .__<br>
Entre dos pensamientos racionales
<br>
hay infinitos pensamientos
irracionales.</span></p>
</div>
</div>
</div>
</div>
<div class="MsoNormal"><span>
<hr width="100%">
</span></div>
<p class="MsoNormal"><span>_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
Disclaimer:<br>
De inhoud van dit bericht is uitsluitend bestemd voor
geadresseerde.<br>
Gebruik van de inhoud van dit bericht door anderen zonder
toestemming van het Kadaster<br>
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht
komen, dan verzoeken wij u<br>
dit direct te melden aan de verzender en het bericht te
vernietigen.<br>
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.<br>
<br>
Disclaimer:<br>
The content of this message is meant to be received by the
addressee only.<br>
Use of the content of this message by anyone other than the
addressee without the consent<br>
of the Kadaster is unlawful. If you have received this message,
but are not the addressee,<br>
please contact the sender immediately and destroy the message.<br>
No rights can be derived from the content of this message.<br>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="https://urldefense.com/v3/__http://www.spatialys.com__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718aCkmz9c$" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$</a> <br>
</blockquote></div>
<span>_______________________________________________</span><br><span>PROJ mailing list</span><br><span>PROJ@lists.osgeo.org</span><br><span>https://lists.osgeo.org/mailman/listinfo/proj</span><br></div></blockquote></div></div></body></html>