[PROJ] 7.2.1 RC1 ob_tran changes break existing logic

[Kristian Evers]

Thanks for clearing this up, Even. The workflow is a bit cumbersome but with the
knowledge you’ve provided here it should be possible for Roger to adapt the code
to work around this.

I agree that a function to determine if a CRS is derived would be a nice addition.

I guess this problem mostly shows up because ob_tran is a bit of a weird projection.
It is often the cause of problems. I wonder if it is time to get rid of it and replace the
functionality with simpler rotational transformation steps in a pipeline?

/Kristian

> On 28 Dec 2020, at 16:26, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> 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