rgdal release candidate 1.5-9 rev. 1000 ready for testing

Patrick, out of interest: can you point to a CI that mirrors what CRAN
OSX binary builds do? What I have seen they build on brew, not on
statically built binaries.

On 6/6/20 4:28 PM, Patrick Schratz wrote:

Roger,

I am sorry for arguing differently so often recently, but if I think
that unfair arguing is going on, I have the feeling to correct this.

First, again I think that stating "I do not have access to this 
system"
is a weak reason in 2020.
I've said this previously but again: As a developer/maintainer, there 
is
the implicit burden to set up a dev environment across different
platforms.
CI helps here.
For more detailed testing, local emulation is possible via virtual
machines which also applies to macOS systems (setting up is harder 
but
not impossible).
Before switching back to macOS a few months ago, I had a virtual 
machine
of macOS running and used it successfully for dev purposes.

Second: All package managers seek to provide stability and homebrew 
is
one of the most sophisticated ones out there.
I honestly do not understand the general bashing against package
managers here.

Third: What role does Apple play in all of this? I am not arguing 
that
they made some decisions that did not necessarily enhance the dev
experience on macOS.
However, I do not see any of these having an effect on the spatial
library stack, especially GDAL and PROJ.

The current situation is that the **main** package manager on macOS,
namely homebrew, has a temporary version situation of GDAL and PROJ 
that
is (for no clear reason yet) blocked by the client package rgdal.

Users on macOS can however use the formulas of the osgeo4mac
(https://github.com/OSGeo/homebrew-osgeo4mac) tap which comes with 
PROJ7
and GDAL3 to solve these issues.

```r
brew tap osgeo/osgeo4mac
brew unlink gdal
brew unlink proj

brew install osgeo-gdal
brew install osgeo-proj
brew link osgeo-gdal
brew link osgeo-proj
```

I am well aware that many users of spatial software are not 
developers
in their every day life and should stick to binaries.
However, there is a group that does source installs and there are CI
checks that rely on proper source installations with the current 
stack
of the main package managers on a platform.
And exactly this group is blocked right now by blocking the rgdal
installation at all, with a somewhat weak reasoning for this action.

In addition, arguing/ranting about specific platforms with points
unrelated to the current issues is a thing that I absolutely dislike,
getting me started arguing against it.
I also do not like certain platforms and have personal favorites.
However, I always check on all and make sure that everyone gets a
pleasant experience on their platform, even if that's painful for me 
and
costs a lot of time.

I am well aware that I might not be invited to the next imaginary 
party
with my arguing here but maybe the discussion can make use of more 
real
facts again, lower subjective views, and focus on providing support 
for
everyone, on all platforms, without introducing something like a
"platform racism" with semi-fake news.

Best, Patrick

On 6 Jun 2020, at 15:45, Roger Bivand wrote:

On Sat, 6 Jun 2020, Ista Zahn wrote:

On Fri, Jun 5, 2020 at 7:47 PM Manuel Sp?nola 
<mspinola10 at gmail.com>
wrote:

Dear list members,

Sorry for the confusion, but with all these suggestions, what is 
the
way to
have the updated versions of the external
software GEOS, PROJ, and GDAL for macOS users.

I think the current recommendation is "if you have to ask don't do
it". Just wait for these to be updated in the OSX binary packages 
on
CRAN.

Thanks, a much better way of saying this!

We really would like to be able to help macOS users who see "Install
from source?" and are tempted to choose "yes", but not only do we 
not
have the resources or access to running systems, but also, at the
moment, things seem very unpredictable. We do not think that
environments are helpful, and many package managers do not seem to
have sufficient focussed attention, which is understandable given
Apple's gift for moving the goalposts.

If users can install external software from source (macOS, Linux),
they/we have a good deal of freedom. But this takes time, insight, 
and
for many is problematic because their production system is blocked
until the new versions are ready (PROJ and GDAL are C++11 or more, 
and
take an order of magnitude longer to compile than just a few years
ago).

So for Windows and macOS, waiting for the CRAN binaries is a
reasonable choice.

Beyond this, we need to find ways of providing share/proj and
share/gdal metadata files for all of the packages now using the PROJ
and GDAL libraries, and of navigating the content download network 
for
geodetic transformation grids available from PROJ 7. But that is
another story ...

Roger

Best,
Ista

Manuel

El vie., 5 jun. 2020 a las 14:31, Patrick Schratz (<
patrick.schratz at gmail.com>) escribi?:

I am not sure if the part with

use --with-proj_api="proj_api.h" for deprecated API

Is of much help since c/p won?t work but the text let?s 
people
assume that c/p could/should work.
In fact, a full path to ?proj_api.h? is required?

I still do not like this blocker and I still do not know if this
combination causes serious issues in production or just limits 
new
features.

For the time being, using and linking osgeo-gdal (3.0.1) and
osgeo-proj
(7.0.1) works and can be used as a workaround until homebrew-core
formulas catch up.

checks OK on PROJ 7.0.1 and GDAL 2.2.4

Again, since it was maybe caused by my typo a few mails ago: The
homebred-core gdal version is at 2.4.4 and not 2.2.4.

On 5 Jun 2020, at 13:29, Roger Bivand wrote:

The release candidate of rgdal_1.5-9 is ready for testing on
R-forge:

https://r-forge.r-project.org/R/?group_id=884

Those insisting on installing on PROJ >= 6 and GDAL < 3 must use
configure argument --with-proj_api="proj_api.h"; with this used,
this
version builds with --no-build-vignettes and installs and checks
OK on
PROJ 7.0.1 and GDAL 2.2.4 with --with-proj_api="proj_api.h".

Otherwise checked OK with PROJ 4.8.0, 4.9.2, 4.9.3 and 5.2.0 
with
GDAL
1.11.4; with PROJ 5.2.0 and GDAL 2.2.4, 2.3.2 and 2.4.2; with 
PROJ
6.3.2 and GDAL 3.0.4; with PROJ 7.0.1 and GDAL 3.0.4 and 3.1.0.

All who have indicated issues with source installs are asked to
try
the release candidate and to report back here by midnight CEST
Monday
8 June. If no indications are forthcoming, I'll assume that
problems
with 1.5-8 are resolved.

Roger

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

--
*Manuel Sp?nola, Ph.D.*
Instituto Internacional en Conservaci?n y Manejo de Vida 
Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
mspinola at una.cr <mspinola at una.ac.cr>
mspinola10 at gmail.com
Tel?fono: (506) 8706 - 4662
Personal website: Lobito de r?o
<https://sites.google.com/site/lobitoderio/>
Institutional website: ICOMVIS <http://www.icomvis.una.ac.cr/>

        [[alternative HTML version deleted]]

-- 
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_______________________________________________
R-sig-Geo mailing list
R-sig-Geo at r-project.org

	[[alternative HTML version deleted]]

-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48149 Muenster, Germany
Phone: +49 251 8333081