<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Andrew,</p>
<p>did you include <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/6523">https://github.com/OSGeo/gdal/pull/6523</a> in your
GDAL build ? It will be included in the soon-to-be-released GDAL
3.6.0 release candidate</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 02/11/2022 à 16:40, Andrew Patterson
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAC8biO0UAWaHUUTkjSY8ooyBiE9O01vXDQKtLBTs32LzG26EaA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hello again!
<div><br>
</div>
<div>I was not expecting to return to this issue (I found the
actual cause of my original problem, a semi-transposed
transform matrix) but after fixing the original bug a new
issue cropped up and it ended up explaining (I think) the
error message:</div>
<div><br>
</div>
<div><font face="monospace">ERROR 1: PROJ:
proj_create_from_database: crs not found</font><br>
</div>
<div><br>
</div>
<div>I get the same error internally when I attempt to import
that PDF using the EPSG code instead of the WKT. This seems to
be because the EPSG code is an ESRI-flavour ESPG code 102422.
It attempts to do a lookup using the "EPSG" factory in PROJ
and the SQL statement:</div>
<div><br>
</div>
<div>"SELECT type FROM crs_view WHERE auth_name = ? AND code =
?" (from factory.cpp:5216 in PROJ)<br>
</div>
<div><br>
</div>
<div>It fails because it uses 'EPSG' for auth_name, but 'ESRI'
causes it to succeed. If I update ogrspatialreference.cpp
(circa 10635):</div>
<div><br>
</div>
<div><font face="monospace">auto obj =
proj_create_from_database(d->getPROJContext(),<br>
"EPSG", <br>
osCode.c_str(),<br>
PJ_CATEGORY_CRS,<br>
true,<br>
nullptr);</font><br>
</div>
<div><br>
</div>
<div>Replacing:</div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">"EPSG" </font></div>
<div><br>
</div>
<div>with:</div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">nCode > 100000 ? "ESRI" : "EPSG"</font> </div>
<div><br>
</div>
<div>After this, it successfully imports the coordinate system.
That feels skeevy to me, but maybe using importFromEPSG() is
the wrong function to use? Though I don't see an alternative.
I'm 99% sure this worked in a previous version of GDAL, though
it may have required a call to morphFromESRI().</div>
<div><br>
</div>
<div>Am I doing something wrong or is there something missing
that should handle ESRI EPSG codes?</div>
<div><br>
</div>
<div>As usual, any help is greatly appreciated!</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 13, 2022 at 9:38
AM Even Rouault <<a
href="mailto:even.rouault@spatialys.com"
moz-do-not-send="true" class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Access
to the PDF to try spotting the cause of the <br>
"proj_create_from_database: crs not found" error &
possibly solving it <br>
would still be interesting<br>
<br>
Le 13/10/2022 à 15:31, Andrew Patterson a écrit :<br>
> Even,<br>
><br>
> So while I was writing up the issue I realized I could
probably <br>
> provide some simple code to help illustrate the problem,
so I wrote <br>
> some. Then I realized I should really run it in our old
app as well, <br>
> which took a while -- which is why you're reading this
today rather <br>
> than yesterday. But in the course of doing this, I
basically proved <br>
> that PROJ is fine, so there's no reason to create the
issue. So false <br>
> alarm!<br>
><br>
> Plotting on the maps is a two step process; coordinate
transform via <br>
> PROJ from WGS84 to the map's projection, then run that
coordinate <br>
> through a world-to-page (i.e. pixel) transform. The
latter is *really* <br>
> easy to test so that's always the first thing I verify.
Once that's <br>
> been done, the problem basically has to lie with the PROJ
transform -- <br>
> and this has been true until now. I'm actually quite
perplexed. If <br>
> both parts of a two-part transformation are fine, why is
everything <br>
> shifted? Something is hinky, but that's my problem not
yours, so I <br>
> apologize for wasting your time with this. I think I also
jumped the <br>
> gun because of problems with Equidistant Cylindrical in
the past, but <br>
> for once, that project is innocent.<br>
><br>
> Again, sorry for the trouble!<br>
><br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><span style="font-size:12.8px">..............................</span><br>
</div>
<div>Andrew Patterson</div>
<div>Lead Software Architect</div>
<div>Avenza Systems Inc.</div>
<div><br>
</div>
<div>email: <a href="mailto:andrew@avenza.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">andrew@avenza.com</a></div>
<div>phone: 416.487.5116 </div>
</div>
</div>
</blockquote>
<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>