[PROJ] 7.2.1 RC1 ob_tran changes break existing logic

[Even Rouault]

On lundi 28 décembre 2020 13:25:15 CET Kristian Evers wrote:
> Thanks, I now understand what you are doing. Basically you are doing your
> best to emulate the legacy behaviour of PROJ.4. And that is the root cause
> of this problem. At least partially. That is not saying that it shouldn’t
> work, though. From the examples below it looks like 7.2.0 has two bugs that
> in conjunction returns the expected result. The two bugs are
> 
> 1. proj_create_crs_to_crs_from_pj() does not return a +proj=noop
> transformation when two identical +proj=ob_tran CRS’s are used as source
> and target. 2. proj_crs_get_geodetic_crs() returning a CRS that is
> identical to the +proj=ob_tran CRS that it is fed. Should probably return
> +proj=latlong +ellps=sphere instead.
> 
> In 7.2.1 1) is fixed but not 2). I assume everything would work as expected
> if 2) is also fixed.

2) is actually correct. "+proj=ob_tran +o_proj=longlat +o_lon_p=-162 
+o_lat_p=39.25 +lon_0=180 +ellps=sphere +type=crs" is represented as a 
DerivedGeographicCRS, but a DerivedGeographicCRS is itself a GeographicCRS 
which is itself a GeodeticCRS.
For a derived CRS, you'd want to use proj_get_source_crs(). The function 
handle different situations, but for a derived CRS, it returns the base CRS, 
which is what you want here.
In the C API we're probably missing a function to easily know if a CRS is a 
derived CRS. So in that situation, you'd want to test the PROJ string for the 
presence of "+proj=ob_tran", and if proj_get_type() returns 
PJ_TYPE_GEOGRAPHIC_2D_CRS, conclude that it is a derived geographic CRS, on 
which you can call proj_get_source_crs()

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com