[PROJ] Equirectangular/Equidistant Cylindrical
Andrew Patterson
andrew at avenza.com
Wed Oct 12 13:12:08 PDT 2022
Even,
I can share both, but presumably I shouldn't (or can't?) post the PDF to
the mailing list. Should I create an issue on GitHub and post the PDF and
other information there?
The transformation is from WGS84 into the CRS of the map (or in this case,
PDF). We render the PDF in its native projection and the points in question
are stored in lat/long in the KML file, so they are being projected from
WGS84 to Equidistant Cylindrical and then transformed into pixels by a
second stage transformation. The latter hasn't changed between the two
versions of the app, so it's presumably the WGS84 -> Equidistant
Cylindrical where the problem lies.
On Wed, Oct 12, 2022 at 2:48 PM Even Rouault <even.rouault at spatialys.com>
wrote:
> 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 listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- 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/20221012/1d96caa3/attachment.htm>
More information about the PROJ
mailing list