[PROJ] World UTM in a proper datum

Even Rouault even.rouault at spatialys.com
Sun Apr 18 02:51:23 PDT 2021 

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 
> <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
>     <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210418/eb337627/attachment-0001.html>

More information about the PROJ mailing list