[PROJ] World UTM in a proper datum

Sun Apr 18 02:45:59 PDT 2021

Hi Jochem,
I do not need to reach that far. You can do that with a "personalized" WKT
string, it is easy... but probably not supported by many software.
Every combination of geographic crs and projection does not make sense in
EPSG. Coordinate reference systems are usually defined by the state/country
authority. In Spain for instance the oficial for maps is ETRS89 + UTM (3
zones). Nobody uses a LCC. In Switzerland they use a single projection
(Hotine_Oblique_Mercator_Azimuth_Center). USA has... well, this is a
different chaos; but it has a limit.

My problem comes with the lack of a
 a) worldwide
 b) accurate / well defined
 c) projected system
 d) in EPSG
for general purpose.
(When I say b), I would include an associated geoid, EGM2008?)

WGS84 / UTM does not fulfill b).
WGS84(G1762), ITRF2008, ITRF2014, and other similar do not fulfill c).
NAD83(2011) / Any projection does not fulfill a)
A personalized WKT does not fulfill d)

I do not need every combination. I just need "one".
Later I can convert -if needed- to my local crs in my country using
(probably) an accurate transformation.

Cheers,
Javier

PS. Dear Santa. All I want this year is a substitute for WGS84. One that we
all agree, we all love, accurate and useful. One easy and accurate to
transform to the personal needs. One with a nice family of projected
children in EPSG that we all can enjoy and play with. Not only for my
friends an me, but for everybody in the world.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.

On Sun, 18 Apr 2021 at 09:20, Lesparre, Jochem <Jochem.Lesparre at kadaster.nl>
wrote:

> 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 <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
>
>
>
> 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/bdd9e81c/attachment.html>