[PROJ] Equirectangular/Equidistant Cylindrical

[Andrew Patterson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221102/3e0f970d/attachment.htm>