[PROJ] World UTM in a proper datum

Sun Apr 18 14:09:26 PDT 2021

Hi Duncan,

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. 

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.

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 18 avr. 2021 à 11:25, Duncan Agnew via PROJ <proj at lists.osgeo.org> a écrit :
> 
> 
> 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 )
>> 
>> 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) 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
>>> 
>>> Sent: Saturday, April 17, 2021 3:56 PM
>>> 
>>> To: Noel Zinn (cc)
>>> 
>>> Cc: proj
>>> 
>>> 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
>>> 
>>> Sent: Saturday, April 17, 2021 2:44 PM
>>> 
>>> To: proj
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 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 list
>>> PROJ at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/proj
>> -- 
>> http://www.spatialys.com
>> 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$ 
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210418/97936818/attachment-0001.html>