[PROJ] World UTM in a proper datum

Sun Apr 18 06:41:22 PDT 2021

As an onlooker, I have a question: what is UTM/WGS84 intended to mean? Is
it (A) the UTM projection using the WGS84 ellipsoid
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.

On Sun, Apr 18, 2021 at 2:51 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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.
>
> What you describe is exactly the not so known OGC URN syntax for combined
> objects (see OGC 07-092r2, para 7.5.4 :
> https://portal.ogc.org/files/?artifact_id=29533
> <https://urldefense.com/v3/__https://portal.ogc.org/files/?artifact_id=29533__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718H5HVjC4$>
> )
>
> For example for UTM 31N / WGS 84 (G1762), that is
>
>
> urn:ogc:def:crs,crs:EPSG::9057,cs:EPSG::4400,coordinateOperation:EPSG::16031
>
> and you can use that with projinfo / proj_create()
>
> 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.
>
> Even
> Le 18/04/2021 à 09:20, Lesparre, Jochem via PROJ a écrit :
>
> 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 (
> https://epsg.org/conversion_16031/UTM-zone-31N.html
> <https://urldefense.com/v3/__https://epsg.org/conversion_16031/UTM-zone-31N.html__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718m8HlkqY$>)
> for UTM zoned 31N. Isn’t this the approach used in WKT strings?
>
>
>
> Jochem
>
>
>
> *From:* PROJ <proj-bounces at lists.osgeo.org> <proj-bounces at lists.osgeo.org> *On
> Behalf Of *Noel Zinn (cc)
> *Sent:* zaterdag 17 april 2021 23:59
> *To:* Javier Jimenez Shaw <j1 at jimenezshaw.com> <j1 at jimenezshaw.com>
> *Cc:* proj <PROJ at lists.osgeo.org> <PROJ at lists.osgeo.org>
> *Subject:* Re: [PROJ] World UTM in a proper datum
>
>
>
> 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?
>
>
>
>
>
> *From:* Javier Jimenez Shaw <j1 at jimenezshaw.com>
>
> *Sent:* Saturday, April 17, 2021 3:56 PM
>
> *To:* Noel Zinn (cc) <ndzinn at comcast.net>
>
> *Cc:* proj <PROJ at lists.osgeo.org>
>
> *Subject:* Re: [PROJ] World UTM in a proper datum
>
>
>
> Hi Noel,
>
> 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.
>
> I know I can apply UTM over ITRF2014 (GDAL does it easily). But there is
> no EPSG code for that.
>
>
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
>
>
>
> On Sat, 17 Apr 2021 at 22:24, Noel Zinn (cc) <ndzinn at comcast.net> wrote:
>
> 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.
>
>
>
> *From:* Javier Jimenez Shaw <j1 at jimenezshaw.com>
>
> *Sent:* Saturday, April 17, 2021 2:44 PM
>
> *To:* proj <PROJ at lists.osgeo.org>
>
> *Subject:* [PROJ] World UTM in a proper datum
>
>
>
> Hi
>
>
>
> 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.
>
>
>
> We have talked many times about the lack of accuracy of WGS84 (EPSG:4326),
> the datum ensemble, etc.
>
> 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).
>
>
>
> Do you know if there is any plan? Or do they exist and I was not able to
> find them?
>
>
>
> Thanks.
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
> ------------------------------
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
> <https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$>
>
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj <https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$>
>
> -- http://www.spatialys.com <https://urldefense.com/v3/__http://www.spatialys.com__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718aCkmz9c$>
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
>
> https://urldefense.com/v3/__https://lists.osgeo.org/mailman/listinfo/proj__;!!Mih3wA!W6E8KjQeH8H-OnMjrZ9cWSBnPkQEeS2Ow1ldMT0tZvbKVM5fTlD9r718Osx8jCY$
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210418/09b0bce4/attachment-0001.html>