[PROJ] Equirectangular/Equidistant Cylindrical

Andrew Patterson andrew at avenza.com
Wed Oct 12 11:04:33 PDT 2022


Hello everyone!

I posted an issue, #3186, involving Equidistant Cylindrical back in May. It
was fixed (very quickly I might add) and I applied the patch to our version
of PROJ without an issue, solving the problem.

Since then, however, I've been given a PDF with an
Equirectangular/Equidistant Cylindrical projection that is giving me some
grief. My QA team has created a KMl file with three positions on this map
that when imported to an earlier version of our app using GDAL 2.4,
properly positioned the placemarks where they are expected. If I do the
same with the current version of our app, running GDAL 3.4, these
placemarks appear west & south of where they should be. I know I'm talking
about GDAL here, but I'm pretty sure this is a PROJ issue for both the
obvious reason that it's a transformation and for another that I'll get to
momentarily.

I downloaded GDAL binaries for 2.4 & 3.5.2 and ran gdalinfo -proj4 against
the PDF file and I get the following outputs (I've removed everything but
the WKTs & proj4 string):

GDAL 2.4:
---------------------------------------------------------------------------------------------
Driver: PDF/Geospatial PDF
Files: 11.2 - Cape Spear Path - Blackhead to Maddox Cove GEO.pdf
Size is 1275, 1650
Coordinate System is:
PROJCS["WGS_1984_ARC_System_Zone_02",
    GEOGCS["GCS_WGS_1984",
        DATUM["WGS_1984",
            SPHEROID["WGS_84",6378137.0,298.257223563]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Equirectangular"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",0.0],
    PARAMETER["Standard_Parallel_1",41.12682127],
    UNIT["Meter",1.0],
    AUTHORITY["Esri","102422"]]
PROJ.4 string is:
'+proj=eqc +lat_ts=41.12682127 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84
+units=m +no_defs '
---------------------------------------------------------------------------------------------

GDAL 3.5.2:
---------------------------------------------------------------------------------------------
ERROR 1: PROJ: proj_create_from_database: crs not found
Driver: PDF/Geospatial PDF
Files: 11.2 - Cape Spear Path - Blackhead to Maddox Cove GEO.pdf
Size is 1275, 1650
Coordinate System is:
PROJCRS["WGS_1984_ARC_System_Zone_02",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]],
            ID["EPSG",6326]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["Degree",0.0174532925199433]]],
    CONVERSION["unnamed",
        METHOD["Equidistant Cylindrical",
            ID["EPSG",1028]],
        PARAMETER["Latitude of 1st standard parallel",41.12682127,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8823]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["Degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]]
Data axis to CRS axis mapping: 1,2
PROJ.4 string is:
'+proj=eqc +lat_ts=41.12682127 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84
+units=m +no_defs'
---------------------------------------------------------------------------------------------

Now, obviously the fact that it has a PROJ error at the top in 3.5.2 is
what points me at PROJ rather than GDAL, even if it wasn't likely just for
being anyways just for being a transformation problem. Just to be on the
safe side, I repealed the fix for #3186 to make sure that wasn't somehow
causing this problem, and no, the problem remains even if I pull that fix
out (of our app, not gdalinfo). I also tried feeding in the WKT from 3.5.2
that the original WKT gets transformed into (this was a workaround for
#3186) but that didn't help.

Any idea on what the problem might be? I'm happy to provide more
information if needed (and even the file it would help!). I'm assuming that
error is the key piece though. Unfortunately, when I debug our app, I never
hit that line; it always manages to pull the SRC from the cache (it never
seems to ask for anything other than EPSG 4326)

Any help would be greatly appreciated!

..............................
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/20221012/647137a2/attachment.htm>


More information about the PROJ mailing list