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