Javier,
the proper fix would be to add a PJ_TYPE_DERIVED_PROJECTED_CRS to the
enumeration (9.2 type of change only, not to be backported to stable
branch). Returning PJ_TYPE_PROJECTED_CRS could cause issues as you can't
cast the C++ object corresponding to a DerivedProjectedCRS to be a
ProjectedCRS
ISO 19111 doesn't consider a DerivedProjectedCRS to be a ProjectedCRS,
presumably because that the conversion applied to the ProjectedCRS to
make it a DerivedProjectedCRS might loose some of the properties of the
projection (conformality, equal area, etc.). For example if you apply an
affine transformation where the scaling isn't the same in both axis.
Just guessing.
Even
Le 23/11/2022 à 11:35, Javier Jimenez Shaw a écrit :
Hi
Searching from PDAL (SpatialReference::isProjected) to GDAL
(OSRIsProjected) to PROJ, I ended up in the function
PJ_TYPE proj_get_type(const PJ *obj)
Inspecting the code I realized that a DerivedProjectedCRS is not
covered by the selector, and will return PJ_TYPE_OTHER_CRS
Remember that unlike other derived, like DerivedGeographicCRS that is
a GeographicCRS or DerivedVerticalCRS is a VerticalCRS, a
DerivedProjectedCRS is not inheriting from ProjectedCRS.
How should it be? Should it be returned as PJ_TYPE_PROJECTED_CRS ?
Should we create a new category? Leave as it is now (abandoned among
other first class citizen CRS types)?
In my opinion a DerivedProjectedCRS "behaves" like a ProjectedCRS in
the same way as a DerivedVerticalCRS behaves like a VerticalCRS and so
on. But maybe I am missing something.
Thanks.
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
