Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Patrick Schratz]

Edzer,

I appreciate your message and agree with everything.

In addition I want to clarify that the Twitter post does not solely 
result out of / refer to the recent messages of today.
It summarizes observations of mine over a longer period from many 
different people and today's discussion might simply have caused this 
overflow (of emotions).
That’s why I did not add any names or other details, to say that again 
explicitly.

Maybe I should have kept it in my head, though.

Happy coding everyone,
Patrick

On 6 Jun 2020, at 22:31, Edzer Pebesma wrote:


On 6/6/20 9:15 PM, Patrick Schratz wrote:

Since I use and contribute to R (6 years for now) I was always on the
side of "help everyone", "things can get better/easier", "don't 
create
your own island solutions". However, I was hitting some (in my view, 
not
understandable) "walls" recently and I am not sure if I want to 
continue

with this attitude.


Dear Patrick,

We should keep in mind that the system requirements of the R spatial
packages is quite likely the most complicated there is on CRAN, that 
it

has a long legacy, and that GDAL/PROJ came very dynamic recently, and
that many people (though not enough) are involved.

I think that you're learning that working with people is much harder
than working with technology.

I highly appreciate the contributions you made to CI for R packages 
[*],

and the way you helped making it work for sf; this helps robust
development and finding bugs early. However, the moment something 
breaks
in the CI setup, I have no clue what to do and have to ask your help. 
If
I wouldn't get that help a couple of times, I would drop the whole 
thing

and throw it out of the window. For people using sf this is the same:
they have no clue how it works; if it doesn't work a couple of times 
and
help doesn't come quickly, they throw it out of the window and look 
for

something else that does work.

What you have to realize is that what looks simple for you (e.g. CI)
looks incredibly complicated for other people, for the simple reason
that they have been doing very different things for the last 6 years,
and have neither time nor ambition to make up for that. Convincing
others to change something by arguing the change is "simple and makes
things better" often does not work because the receiver has a 
different

perception of "simple" and is not convinced that the status quo is not
good enough, or is convinced the change brings a lot of work and/or
added complexity. I don't think it helps to get emotional publicly in
such a case and move to twitter [&], nor to become disappointed in the 
R

project. If you'd move to another project, you'll find yourself again
confronted with people, and discover that communication is always 
difficult.


[*] see e.g. https://github.com/ropensci/tic
[&] https://twitter.com/pjs_228/status/1269301044481339392
--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48149 Muenster, Germany
Phone: +49 251 8333081
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Edzer Pebesma]

On 6/6/20 9:15 PM, Patrick Schratz wrote:
> Since I use and contribute to R (6 years for now) I was always on the
> side of "help everyone", "things can get better/easier", "don't create
> your own island solutions". However, I was hitting some (in my view, not
> understandable) "walls" recently and I am not sure if I want to continue
> with this attitude.

Dear Patrick,

We should keep in mind that the system requirements of the R spatial
packages is quite likely the most complicated there is on CRAN, that it
has a long legacy, and that GDAL/PROJ came very dynamic recently, and
that many people (though not enough) are involved.

I think that you're learning that working with people is much harder
than working with technology.

I highly appreciate the contributions you made to CI for R packages [*],
and the way you helped making it work for sf; this helps robust
development and finding bugs early. However, the moment something breaks
in the CI setup, I have no clue what to do and have to ask your help. If
I wouldn't get that help a couple of times, I would drop the whole thing
and throw it out of the window. For people using sf this is the same:
they have no clue how it works; if it doesn't work a couple of times and
help doesn't come quickly, they throw it out of the window and look for
something else that does work.

What you have to realize is that what looks simple for you (e.g. CI)
looks incredibly complicated for other people, for the simple reason
that they have been doing very different things for the last 6 years,
and have neither time nor ambition to make up for that. Convincing
others to change something by arguing the change is "simple and makes
things better" often does not work because the receiver has a different
perception of "simple" and is not convinced that the status quo is not
good enough, or is convinced the change brings a lot of work and/or
added complexity. I don't think it helps to get emotional publicly in
such a case and move to twitter [&], nor to become disappointed in the R
project. If you'd move to another project, you'll find yourself again
confronted with people, and discover that communication is always difficult.

[*] see e.g. https://github.com/ropensci/tic
[&] https://twitter.com/pjs_228/status/1269301044481339392
-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48149 Muenster, Germany
Phone: +49 251 8333081


pEpkey.asc
Description: application/pgp-keys
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Patrick Schratz]

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.


Since some people reached out to me regarding this paragraph, I would 
like to clarify some things:


I am aware that the terms "racism" and "fake news" contain some weight 
in the current times.
I used them because the way how people who use a specific operating 
system (no matter which one) are treated/grouped reminds me of how 
mankind groups peoples for whatever reason.


This makes me very sad and also somewhat angry, hence my somewhat 
emotional response on this.
Needless to say that I am completely against such categorizations, 
whether they happen in a human or IT context.


What happens in IT in particular is that often vague arguments are 
added, often poorly informed about the operating system in question, 
mostly because the person does not use it in person and just head some 
things about it.


Nevertheless, such wordings and discussion should not be used in 
IT-related mailing lists.

I apologize for this and try to not do it again.

In addition, I will keep quiet for some time, relaxing my emotions and 
re-evaluating if putting in the effort, like I did recently, is actually 
of any help/received positively or just burning time and pushing 
emotions.


Since I use and contribute to R (6 years for now) I was always on the 
side of "help everyone", "things can get better/easier", "don't create 
your own island solutions". However, I was hitting some (in my view, not 
understandable) "walls" recently and I am not sure if I want to continue 
with this attitude.


On 6 Jun 2020, at 18:09, Roger Bivand wrote:


On Sat, 6 Jun 2020, 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.


Your view, not mine. I cannot ask my employer to provide such 
resources.


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.


No, this is not the main burden. For forward-facing packages 
interfacing external software, it is vastly more important to track 
developments in that software, by reading development mailing lists, 
and checking against alpha, beta and RC, as well as tracking 
master/trunk in periods between releases or when things happening in 
the external software seems to have the potential to impact existing R 
packages. This obviously absorbs a lot of time and energy. 
https://github.com/r-spatial/sf/issues/545 documents where we were in 
November 2017 with this; there are lots of other examples in posts  on 
the PROJ and GDAL lists, and in email exchanges with others.



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.




The problem with macOS compared to Windows has been that while 
providing static builds for Windows for three iterations of the 
Windows RTools build train, with help from CRAN and others, most 
recently Jeroen, has gone fairly smoothly for more than ten years, 
macOS moves too quickly. For Simon to keep R itself running has been 
an uphill struggle, with problems with Fortran, versions of system 
software under clang (most recently the archaic ssl shipped by Apple), 
so providing fresh builds of PROJ, GDAL and GEOS has understandably 
not been a priority. We do not build Windows or macOS PROJ, GDAL or 
GEOS libraries, we need others, probably close to CRAN, to do this, 
following CRAN static linking policy.


Note that Brian Ripley continues to monitor and check possibilities 
for static builds of OSGeo software for static linking to CRAN binary 
packages for macOS, but does not have breakthroughs to report for 
recent PROJ or GDAL releases, unfortunately. We are very fortunate 
that he continues to help us with this. rgdal 1.5-9 is partly to 
resolve your problem, but just as much to resolve problems on Solaris 
and other corner-case CRAN check platforms.


Static linking isn't the only policy, but only Linux platforms provide 
(fairly) mature dynamic build package managers. OSGeo4W - built on 
cygwin - has been tried by some over the years, because CRAN static 
linked binary packages may have different versions than say QGIS, 
GRASS or other Windows binaries. We have touched on the idea of 
proposing R-spatial as an OSGeo project, among other things to try to 
match the versions of key 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Roger Bivand]

Patrick,

Thanks for this ...

On Sat, 6 Jun 2020, Patrick Schratz wrote:


Roger,

thanks for your extensive answer, much appreciated.

I won't commenting on every detail, this would make the discssion somewhat 
bloated.


It's always the "cat and mouse game" between the libraries, packages 
managers and client packages. However, the chain is library > package 
manager > client package in my opinion, meaning the client package has 
the burden to at least check the first two and provide **at least** 
instructions for every OS how to get the package installable.


On Linux, I never myself use the package manager for critical libraries, 
always installing R and software like PROJ/GDAL/GEOS from source. I'll 
admit that it is years since, following Brian Ripley's advice, I installed 
GCC from source to explore a particular wrinkle, but for me it has been 
important to avoid the decisions made by package manager maintainers 
interfering with my view of the relationships between the external 
software and compiled code in packages for which I am responsible. 
Recently, for example, it turned out that the R rpm package picked certain 
values for LDFLAGS, which then got in the way of sf's configure script 
https://github.com/r-spatial/sf/issues/1369.


For Windows, we know how to install, using a script in packages to 
download the libraries and share/* files; it is robust and works.


For Linux, some of us install external software from source, it works, but 
we need to handle mutual dependencies manually (say knowing which PROJ and 
GEOS GDAL was built with). Some use Debian and Ubuntu package managers, 
which are versioned to the level of the OS, and generally work; some repos 
are more actively maintained than others. Some use ArchLinux and other 
distributions, maybe source installs are sensible. For Centos/RHEL/Fedora, 
the picture is rather mixed, with slowish tracking of the fast speed of 
API and ABI change in PROJ and GDAL. Package managers also face 
misunderstandings about when an ABI change needs to be flagged by changing 
a minor version or patch number - this happened when GDAL 3.1.0 RCs were 
being checked: 
https://lists.osgeo.org/pipermail/gdal-dev/2020-May/052060.html. Here the 
careful attention of a Debian packager working with us led to a 
last-minute bump of the SONAME, also thanks to Even Rouault, who is 
unfailingly helpful.


Just keeping things more or less functioning at this level is already 
pretty absorbing.


Getting to CRAN binaries for macOS will take a little longer. From 
R-sig-mac, we know that Simon is not convinced that package managers are 
of use in getting to a general resolution, but he has published recipes: 
Simon replied to me pointinng to them: 
https://stat.ethz.ch/pipermail/r-sig-mac/2020-May/013537.html, 
https://github.com/R-macos/recipes


Since he has asked for input, I think that this is likely  to be a 
fruitful way forward, but as noted in this thread, it is getting harder to 
build PROJ and GDAL static, to get to static CRAN binary packages.




The dev toolchain on macOS in general and how things are linked/build is a 
different topic.
For this, I am somewhat missing (until recently) public accessibility of the 
build process/toolchain, even though things are moving forward with the 
creation of https://github.com/R-macos?type=source lately.


Exactly, it has been really difficult to make this kind of progress, so 
positive contributions and patience seem most useful.




Regarding GDAL2 and PROJ>=6: If there is such an offset in spatial 
projections using this combination, I welcome the blocker. However, this 
was not clear in any way before your last post a few hours ago. However, 
I would also welcome more information on this then, either during 
installation attempts or at some other place. Maybe even opening an 
issue at the respective package manager informing the people about the 
dangerous situation. The more attraction an issue gets, the earlier it 
gets fixed.


The package maintainers are also in a difficult position with regard to 
packages/applications that still need GDAL 2. The offsets are not always 
there, but until end users have had the opportunity to check their 
workflows, we won't know. Certainly the announced degradation of GDAL's 
OSR::exportToProj4() suprised a lot of us, even though we knew it was 
coming. For me teaching the John Snow Soho Cholera story and finding the 
Broad Street pump in Ingestre Place was a strong motivation to get users 
to pay attention. Again, it will not affect everyone, but it may do so.




Apologies if some of my recent messages were offensive to you or anyone else.
However, sometimes discussions need "clear" statements with emotions 
excluded.


In the end, we all aim for a smooth experience and aim to have everybody on 
board.


Certainly everybody on board, locations in data and the real world lined 
up adequately, smooth at the moment is a big ask, but once we get the 
community over to WKT2, 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Patrick Schratz]

Roger,

thanks for your extensive answer, much appreciated.

I won't commenting on every detail, this would make the discssion 
somewhat bloated.

It's always the "cat and mouse game" between the libraries, packages 
managers and client packages.
However, the chain is library > package manager > client package in my 
opinion, meaning the client package has the burden to at least check the 
first two and provide **at least** instructions for every OS how to get 
the package installable.

The dev toolchain on macOS in general and how things are linked/build is 
a different topic.
For this, I am somewhat missing (until recently) public accessibility of 
the build process/toolchain, even though things are moving forward with 
the creation of https://github.com/R-macos?type=source lately.

Regarding GDAL2 and PROJ>=6: If there is such an offset in spatial 
projections using this combination, I welcome the blocker.
However, this was not clear in any way before your last post a few hours 
ago.
However, I would also welcome more information on this then, either 
during installation attempts or at some other place.
Maybe even opening an issue at the respective package manager informing 
the people about the dangerous situation.
The more attraction an issue gets, the earlier it gets fixed.

Apologies if some of my recent messages were offensive to you or anyone 
else.
However, sometimes discussions need "clear" statements with emotions 
excluded.

In the end, we all aim for a smooth experience and aim to have everybody 
on board.

Best, Patrick

On 6 Jun 2020, at 18:09, Roger Bivand wrote:

> On Sat, 6 Jun 2020, 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.
>
> Your view, not mine. I cannot ask my employer to provide such 
> resources.
>
>> 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.
>
> No, this is not the main burden. For forward-facing packages 
> interfacing external software, it is vastly more important to track 
> developments in that software, by reading development mailing lists, 
> and checking against alpha, beta and RC, as well as tracking 
> master/trunk in periods between releases or when things happening in 
> the external software seems to have the potential to impact existing R 
> packages. This obviously absorbs a lot of time and energy. 
> https://github.com/r-spatial/sf/issues/545 documents where we were in 
> November 2017 with this; there are lots of other examples in posts  on 
> the PROJ and GDAL lists, and in email exchanges with others.
>
>
>> 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.
>>
>
> The problem with macOS compared to Windows has been that while 
> providing static builds for Windows for three iterations of the 
> Windows RTools build train, with help from CRAN and others, most 
> recently Jeroen, has gone fairly smoothly for more than ten years, 
> macOS moves too quickly. For Simon to keep R itself running has been 
> an uphill struggle, with problems with Fortran, versions of system 
> software under clang (most recently the archaic ssl shipped by Apple), 
> so providing fresh builds of PROJ, GDAL and GEOS has understandably 
> not been a priority. We do not build Windows or macOS PROJ, GDAL or 
> GEOS libraries, we need others, probably close to CRAN, to do this, 
> following CRAN static linking policy.
>
> Note that Brian Ripley continues to monitor and check possibilities 
> for static builds of OSGeo software for static linking to CRAN binary 
> packages for macOS, but does not have breakthroughs to report for 
> recent PROJ or GDAL releases, unfortunately. We are very fortunate 
> that he continues to help us with this. rgdal 1.5-9 is partly to 
> resolve your problem, but just as much to resolve problems on Solaris 
> and other corner-case CRAN check platforms.
>
> Static linking isn't the only policy, but only Linux platforms provide 
> (fairly) mature dynamic build package managers. OSGeo4W - built on 
> cygwin - has been tried by some over the years, because CRAN static 
> linked binary packages may have different versions than say QGIS, 
> GRASS or other Windows binaries. We have touched on the idea of 
> proposing R-spatial as an OSGeo project, among other things to try to 
> match the versions of key software components better. But having many 
> alternatives for source install on macOS runs counter to this, we need 
> to find a path that works 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Roger Bivand]

On Sat, 6 Jun 2020, 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.


Your view, not mine. I cannot ask my employer to provide such resources.

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.


No, this is not the main burden. For forward-facing packages interfacing 
external software, it is vastly more important to track developments in 
that software, by reading development mailing lists, and checking against 
alpha, beta and RC, as well as tracking master/trunk in periods between 
releases or when things happening in the external software seems to have 
the potential to impact existing R packages. This obviously absorbs a lot 
of time and energy. https://github.com/r-spatial/sf/issues/545 documents 
where we were in November 2017 with this; there are lots of other examples 
in posts  on the PROJ and GDAL lists, and in email exchanges with others.



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.




The problem with macOS compared to Windows has been that while providing 
static builds for Windows for three iterations of the Windows RTools build 
train, with help from CRAN and others, most recently Jeroen, has gone 
fairly smoothly for more than ten years, macOS moves too quickly. For 
Simon to keep R itself running has been an uphill struggle, with problems 
with Fortran, versions of system software under clang (most recently the 
archaic ssl shipped by Apple), so providing fresh builds of PROJ, GDAL and 
GEOS has understandably not been a priority. We do not build Windows or 
macOS PROJ, GDAL or GEOS libraries, we need others, probably close to 
CRAN, to do this, following CRAN static linking policy.


Note that Brian Ripley continues to monitor and check possibilities for 
static builds of OSGeo software for static linking to CRAN binary packages 
for macOS, but does not have breakthroughs to report for recent PROJ or 
GDAL releases, unfortunately. We are very fortunate that he continues to 
help us with this. rgdal 1.5-9 is partly to resolve your problem, but just 
as much to resolve problems on Solaris and other corner-case CRAN check 
platforms.


Static linking isn't the only policy, but only Linux platforms provide 
(fairly) mature dynamic build package managers. OSGeo4W - built on cygwin 
- has been tried by some over the years, because CRAN static linked binary 
packages may have different versions than say QGIS, GRASS or other Windows 
binaries. We have touched on the idea of proposing R-spatial as an OSGeo 
project, among other things to try to match the versions of key software 
components better. But having many alternatives for source install on 
macOS runs counter to this, we need to find a path that works - the 
previous go-to was Kyngchaos, but that is no longer a viable solution.


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.


Package managers were debated on R-sig-mac (yes, I follow that too). If 
you use a package manager, that is your choice, but having CI for macOS 
(past and current releases) then gets multiplied  by the number of package 
managers and environments (conda), etc. For central resources, say curl, 
package managers may be OK, but get stuck when some downstream packages 
either get dropped because they are not up to speed with say PROJ/GDAL, or 
PROJ/GDAL get held up because the packages using them are seen as 
important. This happens in all package managers, and is frequently 
discussed on PROJ and GDAL lists, amonng others by those 
responsible for package manager releases. The decisions are not easy, but 
we cannot be held back by package managers' policy choices. My guess is 
that some package in homebrew depends on GDAL 2.* and has not yet upgraded 
to be able to use GDAL 3.*; since GDAL 2.* can be built (although using 
the deprecated API) with PROJ >= 6, they let things slide. They should 
have chosen to stop PROJ at 5.2.*, avoiding the used of the deprecated 
API.




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 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Patrick Schratz]

AFAIK CRAN for macOS relies on the toolstack listed on 
https://mac.r-project.org/libs-4/ and not on homebrew. Though I am not 
100% sure here.
There, static tarballs are used which do not follow a package manager 
versioning scheme (unfortunately, because this would prevent many issues 
for the end user).


-> GDAL 2.4.2 and PROJ 5.2.0

On 6 Jun 2020, at 17:25, Edzer Pebesma wrote:


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 


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 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Roy Mendelssohn - NOAA Federal via R-sig-Geo]

Hi All:

There are some important issues being discussed here about access to new 
versions of libraries on certain platforms,  but can I add:

1.  Let's keep the discussion civil and factual.  Do a little editing before 
you send to remove side comments.

2.  Develops/maintainers are almost all volunteers,  it is a lot of work,  and 
what may seem easy to you can be just one more large piece of work for the 
maintainer.

3.  Most importantly,  work with the developer to find solutions for things 
that they can't do.  If there are solutions to getting the new proj and gdal 
libraries on a Mac,  post how to do that and also how to use them to build 
rgdal,  sp and sf.   Work with the Mac CRAN maintainer to get the libraries on 
that machine so that binary builds can be available to users.

Thanks to all for the work that they do.  I think everyone is honestly trying 
to achieve the same purposes,  but sometimes frustrations can set in.

-Roy


> On Jun 6, 2020, at 7:28 AM, 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  
>>> 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 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Edzer Pebesma]

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

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Roger Bivand]

On Fri, 5 Jun 2020, Patrick Schratz wrote:


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?


No. If proj.pc is found by pkg-config, the path to the relevant include 
directory is obtained there. If proj.pc is not availble, on Linux 
platforms, the usual include directories are tried (often 
/usrlocal/include is the right place). If proj.pc is not available and the 
include directory cannot be found automatically, use the 
--with-proj-include=DIR configure argument to point to the location of 
proj header files.


This is a different configure argument. If PROJ is >= 6, rgdal will choose 
"proj.h" by default. In PROJ 5-7, proj.h and proj_api.h (the legacy 
interface) have been available. In PROJ 5, proj.h was experimental, and 
proj_api.h was used by default. PROJ 6 uses proj.h (with very different 
structures and functions) by default, but proj_api.h can be used by 
setting -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H. PROJ 7 (March 2020) 
extended the grace period for the use of proj_api.h until PROJ 8 (March 
2021) - originally PROJ 7 was going to block proj_api.h.


So setting the path to the directory where both proj.h and proj_api.h are 
present (and project.h for the archeologically interested, happily gone 
now!) does not solve the problem. Seeing the PROJ version, the configure 
script seeing >= 6 chooses proj.h, but GDAL < 3 does not support proj.h. 
Consequently, sf says - ok, degrade the PROJ headers to the deprecated 
version without needing user intervention, rgdal says - user: either use 
PROJ < 6 with GDAL < 3, or explicitly use configure argument 
--with-proj_api="proj_api.h" to change the default, which is "proj.h" for 
PROJ >= 6. In 9 months, we need to make sure that all affected packages 
and workflows are migrating smoothly to PROJ >= 6 with GDAL >= 3, and 
stand-outs only risk unintended and possibly silent degradation of 
workflows.


See 
http://rgdal.r-forge.r-project.org/articles/CRS_projections_transformations.html


for details of why the migration is needed. PROJ had stood still until 
2017, and was slowly ceasing to be fit for purpose. Projections were fine, 
including ellipsoid changes in some cases, but datum shifts were always a 
cludge. GDAL and PROJ had separate *.csv files to hold projection and 
datum shift specifications; these were not as such authorised, and were 
hard to maintain. PROJ 5 brought the introduction of transformation 
pipelines, offering to avoid transformation from source to WGS84 and then 
to target. PROJ 6 and GDAL 3 brought the harmonisation of projection and 
transformation specifications as an SQLite database (proj.db) shipping 
only with PROJ, and the deep integration of GDAL and PROJ coordinate 
operation functionality. GDAL 2 simply doesn't know how to use the proj.db 
database directly, so some temporary code has been provided to bridge back 
from old GDAL to new PROJ. In particular, the new database structure 
supports conceptualisations, such as area of interest and epoch, which are 
crucial for finding coordinate operations efficiently, but which are not 
available to GDAL 2.


Work can still be done with PROJ 6 or 7 and GDAL 2, but PROJ 8 and GDAL 2 
will not work together. Most likely, accuracy is already less when using 
GDAL 2 and PROJ 6 or 7, compared to upgraded use of GDAL >= 3 and PROJ >= 
6, especially if WKT2 strings are used instead of legacy Proj4 strings in 
the current setting.




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.


Both problems as described above. The positions may end up being off by 
about 125m.




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.




Really not my problem, as you should have seen, I also checked PROJ 5.2.0 
and GDAL 2.4.2. This does not impinge on the use of the deprecated API.


I see that you have posted again, I will respond to that in-thread.

Roger


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; 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Patrick Schratz]

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  
>> 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.schr...@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 

Re: [R-sig-Geo] rgdal release candidate 1.5-9 rev. 1000 ready for testing

[Roger Bivand]

On Sat, 6 Jun 2020, Ista Zahn wrote:


On Fri, Jun 5, 2020 at 7:47 PM Manuel Spínola  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.schr...@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.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J=en

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo




--
*Manuel Spínola, Ph.D.*
Instituto Internacional en Conservación y Manejo de Vida Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
mspin...@una.cr 
mspinol...@gmail.com
Teléfono: (506) 8706 - 4662
Personal website: Lobito de río 
Institutional website: ICOMVIS 

[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


___
R-sig-Geo mailing list
R-sig-Geo@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.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J=en___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo