[PROJ] 7.2.1 RC1 ob_tran changes break existing logic

[Roger Bivand]

On Mon, 28 Dec 2020, Even Rouault wrote:

> On lundi 28 décembre 2020 16:41:09 CET Kristian Evers wrote:

>> 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.
>
> Queued in https://github.com/OSGeo/PROJ/pull/2496 . I've targetted it for 8.0
> . Could be easily backported if deemed necessary.
>

Thanks! Handled with

if (proj_get_type(target_crs) == PJ_TYPE_GEOGRAPHIC_2D_CRS && use_ob_tran) 
{
         if ((source_crs = proj_get_source_crs(PJ_DEFAULT_CTX, target_crs)) 
== 0)
...

where use_ob_tran is declared by the user as TRUE if the user wishes, and 
the involved CRS include the proj=ob_tran string.

Tested OK with 7.2.1 RC1 and 7.2.0; now need to check for earlier 
releases. Current code on R-Forge SVN, revisions 1086-1088.

Roger


>>
>> 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
>
> Although I concur it is an annoyance, I can't see how we could get rid 
> of it. There are definitely use cases where people want a CRS object 
> expressing such rotation.
>
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en