Re: [PROJ] OGRCreateCoordinateTransformation()
Even Rouault <[email protected]> Thu, 24 Mar 2022 18:54:44 +0100
| Newsgroups | gmane.comp.gis.gdal.devel,gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0782466917560709118==
Content-Type: multipart/alternative;
boundary="------------nl2y2pan0Iz5kwQyPBAhWIeQ"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------nl2y2pan0Iz5kwQyPBAhWIeQ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Le 24/03/2022 à 18:36, Erixen Cruz a écrit :
>
>> PROJ4_GRIDS provided a way to specify exactly which geoid file(s)
>> to use. Some vertical datums, such as NAVD88, only have a single
>> EPSG code for multiple geoids – what’s the replacement for
>> PROJ4_GRIDS in PROJ9? If I could switch to WKT2 strings (not
>> sure that’s really feasible) does it fix these problems?
>>
> WKT2 hardly helps for that.
>
>
> There is one way to get WKT2 to do just this. Here's the start of the
> thread about that:
> https://lists.osgeo.org/pipermail/proj/2019-December/009142.html. TLDR
> you use a BOUNDCRS with an ABRIDGEDTRANSFORMATION. Thanks again, Even,
> for pointing us in this direction.
>
> This is not ideal though. Like Even said, this (mis)use of BOUNDCRS
> doesn't fit very cleanly in PROJ9 at the moment.
yeah, that can be used in PROJ (and that's exactly how a WKT1 with a
TOWGS84 or PROJ4_GRIDS, or a PROJ.4 strings with
+towgs84/+nadgrids/+geoidgrids end up being represented), but
pedantically a BOUNDCRS[] is not a CRS. PROJ does accept is as a CRS
(such as a COMPOUNDCRS of BOUNDCRS[]) because there was no other
convenient way of modeling those legacy features in ISO19111:2019 /
WKT2:2019, but this is an extension, and strictly conforming other
implementations would reject that.
And the ABRIDGEDTRANSFORMATION[] syntax cannot be used for vertical
transformations where the geographic CRS would not be the interpolation CRS.
--
http://www.spatialys.com
My software is free, but my time generally not.
--------------nl2y2pan0Iz5kwQyPBAhWIeQ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 24/03/2022 à 18:36, Erixen Cruz a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CABG=M1Pb9E4mue1YtcDjDPCXfb=XL62y1v0K4g5AY=T-YX3z6w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote type="cite">
<div>
<p class="MsoNormal">PROJ4_GRIDS provided a way to specify
exactly which geoid file(s) to use. Some vertical
datums, such as NAVD88, only have a single EPSG code for
multiple geoids – what’s the replacement for PROJ4_GRIDS
in PROJ9? If I could switch to WKT2 strings (not sure
that’s really feasible) does it fix these problems?</p>
</div>
</blockquote>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> WKT2
hardly helps for that.</blockquote>
<div><br>
</div>
<div>There is one way to get WKT2 to do just this. Here's the
start of the thread about that: <a
href="https://lists.osgeo.org/pipermail/proj/2019-December/009142.html"
moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.osgeo.org/pipermail/proj/2019-December/009142.html</a>.
TLDR you use a BOUNDCRS with an ABRIDGEDTRANSFORMATION. Thanks
again, Even, for pointing us in this direction.</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CABG=M1Pb9E4mue1YtcDjDPCXfb=XL62y1v0K4g5AY=T-YX3z6w@mail.gmail.com">
<div dir="ltr"><br>
<div>This is not ideal though. Like Even said, this (mis)use of
BOUNDCRS doesn't fit very cleanly in PROJ9 at the moment.</div>
</div>
</blockquote>
<p>yeah, that can be used in PROJ (and that's exactly how a WKT1
with a TOWGS84 or PROJ4_GRIDS, or a PROJ.4 strings with
+towgs84/+nadgrids/+geoidgrids end up being represented), but
pedantically a BOUNDCRS[] is not a CRS. PROJ does accept is as a
CRS (such as a COMPOUNDCRS of BOUNDCRS[]) because there was no
other convenient way of modeling those legacy features in
ISO19111:2019 / WKT2:2019, but this is an extension, and strictly
conforming other implementations would reject that.</p>
<p>And the ABRIDGEDTRANSFORMATION[] syntax cannot be used for
vertical transformations where the geographic CRS would not be the
interpolation CRS.</p>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>
--------------nl2y2pan0Iz5kwQyPBAhWIeQ--
--===============0782466917560709118==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--===============0782466917560709118==--