[PROJ] 7.2.1 RC1 ob_tran changes break existing logic

Roger Bivand Roger.Bivand at nhh.no
Tue Dec 29 12:12:50 PST 2020


On Tue, 29 Dec 2020, Roger Bivand wrote:

> 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.

Check with PROJ 6.3.1/GDAL 3.0.4 OK.

No further problems with RC1.

Roger

>
> 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


More information about the PROJ mailing list