[R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition

Roger Bivand Roger@B|v@nd @end|ng |rom nhh@no
Sun May 31 17:44:29 CEST 2020 

Fresh version of rgdal rev 995 on link and R-forge, with more tweaks to 
the configure file. Please test.

Roger

On Fri, 29 May 2020, Roger Bivand wrote:

> I have put a tarball, built without vignettes with GDAL 2.2.4 and PROJ 7.0.1 
> that passes CMD check (with warnings for missing vignettes) on:
>
> http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz
>
> It involves code copying to provide duplicated functions in three settings:
>
> PROJ < 6 & GDAL < 3
> PROJ > = 6 & GDAL >= 3
> PROJ > = 6 & GDAL < 3 (your homebrew case)
>
> You need the configure argument: --configure-args=--with-proj_api=proj_api.h.
> Without the argument, you now get directed to use it.
>
> For now I've dropped the configure tests for sqlite3, curl and tiff; works 
> for me but may not work for you.
>
> Please make the output of:
>
> R CMD check --install-args="--configure-args=--with-proj_api=proj_api.h" 
> rgdal_1.5-9.tar.gz
>
> available ASAP. I count on an immediate response.
>
> Roger
>
> On Fri, 29 May 2020, Roger Bivand wrote:
>
>>  On Fri, 29 May 2020, Patrick Schratz wrote:
>>
>>>   The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6 is
>>>   present. It does not even install the package if this condition is not
>>>   met
>>>   but errors during linking.
>>
>>  Please document with the output of 00install.out from R CMD check
>>  rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo --version
>>  with system details.
>>
>>  Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no sense
>>  with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API and the
>>  old metadata structure with Proj4 string degradation; GDAL < 3 with PROJ
>>>  = 6 must use the deprecated API and the new metadata structure.
>> 
>>>
>>>   I could not find any sources in the web or in the announcement post of
>>>   v1.5.8 why this condition was enforced so strictly.
>>>   Does it cause unwanted results?
>>
>>  Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the complete
>>  break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with PROJ >= 6) after
>>  GDAL barnraising. So:
>>
>>            PROJ
>>            < 6 >= 6
>>  GDAL < 3   OK   NO
>>    >  = 3   NO   OK
>> 
>> 
>>
>>>   If so, then there is a big issue since the “gdal2 and proj >= 6”
>>>   combination has been used by many people in the past already.
>>
>>  No good precedent, just binary packagers protecting slow downstream
>>  adaptation.
>>
>>>   I haven’t tracked down for how long this situation was on the market
>>>   already.
>>>   Also the {sf} package is still installable with this combination and I
>>>   am not aware of any warnings/issues that came up due to this so far.
>>> 
>>
>>  rgdal is a much older package and has much more older code that needs this
>>  protection. It is possible to accommodate the no-go areas, but I'd really
>>  value patches to R-forge, as I cannot check multiple PROJ/GDAL version
>>  combinations just because someone isn't up to speed.
>>
>>>   It further causes complete breakage for people relying on the homebrew
>>>   package manager on macOS since current versions are gdal v2.2.4 and proj
>>>   7.0.1.
>>
>>  They should never have gone beyond PROJ 5 if they are stuck on GDAL. PROJ
>>  7 is a very different animal.
>>
>>>   The update to gdal3 is blocked since months due to an incompatibility
>>>   with `liblas` (https://github.com/libLAS/libLAS/issues/164). Reading the
>>>   issue, it looks unclear when this issue will be resolved.
>>>   The alternative osgeo4mac tap holds formula that is unstable and
>>>   somewhat broken. One cannot link rgdal with the current gdal v3.0.1 from
>>>   osgeo4mac.
>>>
>>>   This incompatibility with homebrew-core formula leads to further issues
>>>   for CI tests that rely on the spatial homebrew stack for macOS builds.
>>>
>>>   All of this is really unfortunate and I am wondering if this was a known
>>>   factor when introducing this condition in the new release.
>>>   Unfortunately rgdal is not hosted on any Git* provider (there is just
>>>   the CRAN mirror with not much information about the recent changes) and
>>>   it is unclear/untransparent to me if there is a continuous integration
>>>   setup at all for this package.
>>
>>  Do not require me to leave the excellent SVN service on R-forge. Provide
>>  patches there.
>>
>>>   I hope this is not another case in the series “I do not like operating
>>>   system XY and hence I do not test on it” which was seen recently in
>>>   another package. That’s what CI is for and the responsibility of
>>>   package authors.
>>> 
>>
>>  I run and develop on Fedora, I  have no access to OSX, and the current
>>  release was fully checked with ~ 900 revdeps repeatedly since November on
>>  successive older and newer versions of PROJ and GDAL. I blocked new PROJ
>>  with old GDAL recently to simplify development. CI is only as good as the
>>  scripts, I am completely sure that repeated revdep testing and reading the
>>  output is superior.
>>
>>>   Also one should be aware that not every rgdal user is member of this
>>>   mailing list (I guess not even 5%) and many people in production will
>>>   face this error during install, most of them without any clue what to do
>>>   or an idea why this was raised.
>>> 
>>
>>  There has been plenty of information given about the CRS changes. rgdal
>>  could simply have been abandoned by me, and all  those production
>>  volunteers might have fixed things, but I never hear anything at all.
>>
>>>   In summary it would be great if
>>>
>>>   - There would be more detailed information on the introduction of the
>>>   new condition
>>>   - Awareness of state-of-the-art platform related library versions before
>>>   making such a release
>>>   - Transparency/Existence of a cross-platform build process
>>>   - If the incompatibility is just due to some features not being
>>>   accessible with this configuration, I suggest to raise a warning during
>>>   package load but not prevent the package from installing in the first
>>>   place
>>>   - A version-based NEWS file would be available. Currently one only sees
>>>   a revision-based Changelog:
>>>   https://cran.r-project.org/web/packages/rgdal/ChangeLog
>>>
>>>   I am well aware that I am indirectly criticising (hopefully in a
>>>   constructive way) the transparency and release process here, for which I
>>>   will probably get a rough response.
>>>   However, if that leads to more robustness and transparency in future
>>>   release, I am fine with this.
>>>
>>>   A quick patch release resolving the breakage would be highly
>>>   appreciated.
>>
>>  Only with community imput. what you ask is not needed, just extra
>>  complexity. Please provide patches, or accept my invitation to join the
>>  R-forge project and commit your fixes directly. I can see how to do it,
>>  but I don't think it makes sense, and your messsage has not motivated me,
>>  to be honest. I'm prioritizing working with CRAN to iron out reverse
>>  dependency problems.
>>
>>  Roger
>> 
>>>
>>>   Best, Patrick
>>>    [[alternative HTML version deleted]]
>>>
>>>   _______________________________________________
>>>   R-sig-Geo mailing list
>>>   R-sig-Geo using r-project.org
>>>   https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>> 
>> 
>> 
>
>

-- 
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 using nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

More information about the R-sig-Geo mailing list