[PROJ] World UTM in a proper datum

[Lesparre, Jochem]

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) for UTM zoned 31N. Isn’t this the approach used in WKT strings?

Jochem

From: PROJ <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>
Cc: proj <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<mailto:j1 at jimenezshaw.com>
Sent: Saturday, April 17, 2021 3:56 PM
To: Noel Zinn (cc)<mailto:ndzinn at comcast.net>
Cc: proj<mailto: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<mailto: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<mailto:j1 at jimenezshaw.com>
Sent: Saturday, April 17, 2021 2:44 PM
To: proj<mailto: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<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210418/460be3b4/attachment-0001.html>