[PROJ] Equirectangular/Equidistant Cylindrical

Wed Oct 12 11:48:30 PDT 2022

Andrew,

the PDF file would be needed to analyze this, as well as the target CRS 
you are reprojecting into with your app.

I suspect that the "proj_create_from_database: crs not found" error 
might come from the fact that the PDF contains a WKT string with 
AUTHORITY["Esri","102422"], and PROJ currently only understands "ESRI" 
as the authority, and not "Esri". It should probably be laxer regarding 
that. That said, I'm not sure that explains a difference in positioning. 
It is probably more that recent PROJ versions can apply datum shifts 
more often than older ones, so things might behave as expected.

Even

Le 12/10/2022 à 20:04, Andrew Patterson a écrit :
> 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
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221012/531f8af3/attachment-0001.htm>