[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