[PROJ] Equirectangular/Equidistant Cylindrical

Wed Nov 2 10:49:02 PDT 2022

Even,

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!

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()?

On Wed, Nov 2, 2022 at 11:51 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Andrew,
>
> did you include https://github.com/OSGeo/gdal/pull/6523 in your GDAL
> build ? It will be included in the soon-to-be-released GDAL 3.6.0 release
> candidate
>
> Even
> Le 02/11/2022 à 16:40, Andrew Patterson a écrit :
>
> Hello again!
>
> 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:
>
> ERROR 1: PROJ: proj_create_from_database: crs not found
>
> 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:
>
> "SELECT type FROM crs_view WHERE auth_name = ? AND code = ?" (from
> factory.cpp:5216 in PROJ)
>
> It fails because it uses 'EPSG' for auth_name, but 'ESRI' causes it to
> succeed. If I update ogrspatialreference.cpp (circa 10635):
>
> auto obj = proj_create_from_database(d->getPROJContext(),
>                                          "EPSG",
>                                          osCode.c_str(),
>                                          PJ_CATEGORY_CRS,
>                                          true,
>                                          nullptr);
>
> Replacing:
>
> "EPSG"
>
> with:
>
> nCode > 100000 ? "ESRI" : "EPSG"
>
> 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().
>
> Am I doing something wrong or is there something missing that should
> handle ESRI EPSG codes?
>
> As usual, any help is greatly appreciated!
>
> On Thu, Oct 13, 2022 at 9:38 AM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Access to the PDF to try spotting the cause of the
>> "proj_create_from_database: crs not found" error & possibly solving it
>> would still be interesting
>>
>> Le 13/10/2022 à 15:31, Andrew Patterson a écrit :
>> > Even,
>> >
>> > So while I was writing up the issue I realized I could probably
>> > provide some simple code to help illustrate the problem, so I wrote
>> > some. Then I realized I should really run it in our old app as well,
>> > which took a while -- which is why you're reading this today rather
>> > than yesterday. But in the course of doing this, I basically proved
>> > that PROJ is fine, so there's no reason to create the issue. So false
>> > alarm!
>> >
>> > Plotting on the maps is a two step process; coordinate transform via
>> > PROJ from WGS84 to the map's projection, then run that coordinate
>> > through a world-to-page (i.e. pixel) transform. The latter is *really*
>> > easy to test so that's always the first thing I verify. Once that's
>> > been done, the problem basically has to lie with the PROJ transform --
>> > and this has been true until now. I'm actually quite perplexed. If
>> > both parts of a two-part transformation are fine, why is everything
>> > shifted? Something is hinky, but that's my problem not yours, so I
>> > apologize for wasting your time with this. I think I also jumped the
>> > gun because of problems with Equidistant Cylindrical in the past, but
>> > for once, that project is innocent.
>> >
>> > Again, sorry for the trouble!
>> >
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
>
> --
> ..............................
> Andrew Patterson
> Lead Software Architect
> Avenza Systems Inc.
>
> email: andrew at avenza.com
> phone: 416.487.5116
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>

-- 
..............................
Andrew Patterson
Lead Software Architect
Avenza Systems Inc.

email: andrew at avenza.com
phone: 416.487.5116
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221102/cd060f0a/attachment.htm>