[R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition
Abdoulaye Sarr
@bdou|@ye@@r @end|ng |rom gm@||@com
Wed Jun 3 15:38:42 CEST 2020
Have a problem with needed gdal version on mac
On Tue, Jun 2, 2020 at 4:04 PM Robin Lovelace <rob00x using gmail.com> wrote:
> Confirmed: this worked perfectly for me.
>
> Video evidence that this is fixed:
> https://asciinema.org/a/zPQFbI6Q01oqUy1HRauCjLUXY
>
> Thanks Roger!
>
> Robin
>
> On Tue, Jun 2, 2020 at 4:00 PM Roger Bivand <Roger.Bivand using nhh.no> wrote:
>
> > Brian Ripley (thanks!) provided a patch for rgdal's configure.ac, and
> the
> > R-forge build and check processes now succeed, so please try to install
> > either downloading
> > http://download.r-forge.r-project.org/src/contrib/rgdal_1.5-9.tar.gz and
> > installing from the command line (after running R CMD check), or
> > install.packages("rgdal", repos="http://R-Forge.R-project.org").
> >
> > Remember that if GDAL is < 3, and PROJ >= 6, you need the configure
> > argument: --configure-args=--with-proj_api=proj_api.h.
> >
> > Roger
> >
> > On Sun, 31 May 2020, Roger Bivand wrote:
> >
> > > 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
> > _______________________________________________
> > R-sig-Geo mailing list
> > R-sig-Geo using r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> [[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
>
[[alternative HTML version deleted]]
More information about the R-sig-Geo
mailing list