<div dir="ltr">Even,<div><br></div><div>So it's funny, but I completely forgot about that issue -- which is embarrassing since I filed it! I looked, but no, that wouldn't solve my problem because I'm not using GDAL to read the PDF's spatial referencing. Our app takes a PDF and reads the referencing manually, then renders the PDF into a tile pyramid and stores the referencing in a separate file. Presently, we only store the WKT but in the past, we sometimes stored the EPSG instead. So the problem in question happens when someone migrates from an older version of our app (using GDAL 2.4) to the newest version (3.4). I think literally every time I've posted here with a question or problem relates to that jump!</div><div><br></div><div>At any rate, when we load the tile pyramid, we read in the referencing and all I have is the EPSG code in some cases. But feeding an ESRI pseudo-EPSG to importFromEpsg() doesn't work. That said, when I looked at your fix for #6523, I noticed you use SetFromUserInput(), so I tried that and it solved the problem. I didn't realize that I had to ensure that the ESRI pseudo-EPSGs were handled differently; maybe there should be a warning or error message if you pass in an EPSG code that is bigger than 100K to importFromEPSG()?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 11:51 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">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">
  
    
  
  <div>
    <p>Andrew,</p>
    <p>did you include <a href="https://github.com/OSGeo/gdal/pull/6523" target="_blank">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>Le 02/11/2022 à 16:40, Andrew Patterson
      a écrit :<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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">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">
        <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">andrew@avenza.com</a></div>
          <div>phone: 416.487.5116 </div>
        </div>
      </div>
    </blockquote>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</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">andrew@avenza.com</a></div><div>phone: 416.487.5116 </div></div></div>