[PROJ] Equirectangular/Equidistant Cylindrical
Even Rouault
even.rouault at spatialys.com
Wed Oct 12 13:38:46 PDT 2022
Le 12/10/2022 à 22:12, Andrew Patterson a écrit :
> 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?
yes please
>
> 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.
hum, weird, this is the most simple projection you can imagine...
>
> 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 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.
>
>
>
> --
> ..............................
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20221012/1857c5df/attachment-0001.htm>
More information about the PROJ
mailing list