[R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition
Patrick Schratz
p@tr|ck@@chr@tz @end|ng |rom gm@||@com
Fri May 29 22:05:11 CEST 2020
The URL returns a 404.
FWIW I’ve tried it locally using the latest svn revision but have no
clue where I should find `proj_api.h` (I’ve looked in the complete
proj installation directory).
I see
```
ls /usr/local/Cellar/proj/7.0.1/lib/
libproj.19.dylib libproj.a libproj.dylib@ libproj.la*
pkgconfig/
```
Even if this custom installation might work at some point, making such
adjustments until gdal3 arrives in homebrew will be a major pain, also
for CI builds.
It would still be highly appreciated if this internal assertion would be
removed again.
On 29 May 2020, at 18:37, 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
[[alternative HTML version deleted]]
More information about the R-sig-Geo
mailing list