Subscribe to R-sig-geo feed
This is an archive for R-sig-geo, not a forum. It is not possible to post through Nabble - you may not start a new thread nor follow up an existing thread. If you wish to post, but are not subscribed to the list through the list homepage, subscribe first (through the list homepage, not via Nabble) and post from your subscribed email address. Until 2015-06-20, subscribers could post through Nabble, but policy has been changed as too many non-subscribers misunderstood the interface.
Updated: 10 min 40 sec ago

Re: Difference in area calculation between QGIS and R

Wed, 06/27/2018 - 10:29
Raster uses a (discretized) cosine-of-latitude approximati (popular amongst
longlat map makers).

QGIS uses a project to local equal area projection method or maybe some
other approach.

There's lots and f options, all that matters is what your work needs.

Cheers, Mike

On Wed, 27 Jun 2018, 22:14 Suncus Etruscus, <[hidden email]>
wrote:

> Dear List,
> I am trying to use R ("sp" and "raster" packages) to calculate the area of
> several polygons (CRS of the shapefile EPSG: 4326  - WGS84).
>
> I used this line of code:
>
> shapefile_name$area_km2 <- area(shapefile_name)/1000000
>
> However, when I used QGIS to calculate the area of the same polygons
> (through the "$area" function), I found there was a slight difference (in
> every polygon).
>
> For example, for a polygon of about 30 000 km2, the area calculated in R
> was 50 km2 smaller.
>
> What could be the cause?
>
> Thanks in advance,
> N.
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Difference in area calculation between QGIS and R

Wed, 06/27/2018 - 10:06
Dear List,
I am trying to use R ("sp" and "raster" packages) to calculate the area of
several polygons (CRS of the shapefile EPSG: 4326  - WGS84).

I used this line of code:

shapefile_name$area_km2 <- area(shapefile_name)/1000000

However, when I used QGIS to calculate the area of the same polygons
(through the "$area" function), I found there was a slight difference (in
every polygon).

For example, for a polygon of about 30 000 km2, the area calculated in R
was 50 km2 smaller.

What could be the cause?

Thanks in advance,
N.

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Fitting GWR for Panel Data in R

Wed, 06/27/2018 - 09:23
Good day!

Does anyone here have experience or code for fitting geographically
weighted regression (GWR) for panel data. For example, I need to determine
the effect of independent variable X1, X2, and X3 to Y which are all
collected for T1 to Tn.  I have experience in fitting GWR for
cross-sectional data but have no experience on doing such on panel data.

Any suggestion is highly appreciated.

Thanks in advance!

Arnold Salvacion
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

(no subject)

Mon, 06/25/2018 - 18:04
hello     https://goo.gl/x8U8LM    Ray Danner
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Variance explained with the GSIF package

Mon, 06/25/2018 - 08:20
Dear list members,

I am using the fit.gstatModel from the GSIF package.

I obtained 2 different values for variance explained using randomForest.
One is for the model and the other for the prediction.  What is the
difference among them and what is more important to report?

omm <- fit.gstatModel(meuse, om~dist+ffreq, meuse.grid,
method="randomForest")

> omm@regModel

Call:
 randomForest(formula = formulaString, data = rmatrix.s, importance =
TRUE,      na.action = na.omit)
               Type of random forest: regression
                     Number of trees: 500
No. of variables tried at each split: 1

          Mean of squared residuals: 5.952434
                    % Var explained: 49.16


om.rk <- predict(omm, meuse.grid)

> show(om.rk)
  Variable           : om
  Minium value       : 1
  Maximum value      : 17
  Size               : 153
  Total area         : 4964800
  Total area (units) : square-m
  Resolution (x)     : 40
  Resolution (y)     : 40
  Resolution (units) : m
  Vgm model          : Exp
  Nugget (residual)  : 2.78
  Sill (residual)    : 8.36
  Range (residual)   : 6100
  RMSE (validation)  : 1.672
  Var explained      : 76.1%
  Effective bytes    : 1215
  Compression method : gzip

--
*Manuel Spínola, Ph.D.*
Instituto Internacional en Conservación y Manejo de Vida Silvestre
Universidad Nacional
Apartado 1350-3000
Heredia
COSTA RICA
[hidden email] <[hidden email]>
[hidden email]
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]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: CRAN releases of sp, rgdal and rgeos

Mon, 06/25/2018 - 03:04
Few more notes on installation of GDAL 2.3.

I was installing GDAL and rgdal on another Ubuntu machine and I
experiences multiple problems with more installations of GDAL and proj4
probably ("unable to load shared object rgdal.so" error). This is what I
realized needs to be done before installing GDAL from source:

1. Install libgdal-dev and libroj-dev (very important otherwise the
installation of rgdal will fail)

|sudo apt-get install libgdal-dev libproj-dev|

2. Download GDAL source code
(https://trac.osgeo.org/gdal/wiki/DownloadSource) and probably best
install it using the checkinstall package:

sudo apt install checkinstall

wget http://download.osgeo.org/gdal/2.3.0/gdal-2.3.0.tar.gz

tar -xvzf gdal-2.3.0.tar.gz

cd gdal-2.3.0

./configure

sudo checkinstall

*checkinstall took 20 minutes on my system, so be ready to take coffee
and relax.

3. This would build a debian package that can then be normally installed
and removed using the gdebi.

4. Install rgdal using install.packages("rgdal")

Thanks Roger for keeping everything up-to-date and stable! GDAL is the
backbone of almost any GIS project I run.

Tom


On 19.06.2018 16:57, Tomislav Hengl wrote:
>
> Hi Roger,
>
> I have now managed to reinstall GDAL 2.3 and the latest versions of
> rgdal and sf. These are the steps I have followed:
>
> 1. First remove existing installation of GDAL using:
>
> sudo apt-get purge --auto-remove gdal-bin
>
> *this also removes QGIS / anything linked with GDAL.
>
> 2. Download GDAL source code
> (https://trac.osgeo.org/gdal/wiki/DownloadSource) and follow the
> instructions to install from source
> (https://trac.osgeo.org/gdal/wiki/BuildingOnUnix)
>
> 3. Installation from source code takes quite some time (10-15
> minutes). After that I get:
>
> gdalinfo --version
> GDAL 2.3.0, released 2018/05/04
>
> 4. Install rgdal from R-forge using e.g.:
>
> R CMD INSTALL rgdal_1.3-3.tar.gz
> * installing to library ‘/opt/microsoft/ropen/3.4.3/lib64/R/library’
> * installing *source* package ‘rgdal’ ...
> checking for g++... g++
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> configure: CC: gcc -std=gnu99
> configure: CXX: g++
> configure: rgdal: 1.3-3
> checking for /usr/bin/svnversion... yes
> cat: inst/SVN_VERSION: No such file or directory
> configure: svn revision:
> checking whether g++ supports C++11 features by default... no
> checking whether g++ supports C++11 features with -std=gnu++11... yes
> configure: C++11 support available
> checking for gdal-config... /usr/local/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 2.3.0
> checking C++11 support for GDAL >= 2.3.0... yes
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /usr/local/share/gdal/pcs.csv readable... yes
> configure: pkg-config proj exists, will use it
> configure: PROJ version: 4.9.2
> checking proj_api.h presence and usability... yes
> checking PROJ version >= 4.8.0... yes
> checking projects.h presence and usability... yes
> checking PROJ.4: epsg found and readable... yes
> checking PROJ.4: conus found and readable... yes
> configure: Package CPP flags:  -I/usr/local/include
> configure: Package LIBS:  -L/usr/local/lib -lgdal -lproj
> configure: creating ./config.status
>
> For sf I had to manually update DBI and units packages as it requires
> newest versions.
>
> So now everything works fine. Thank you!
>
> Tom
>
> On 06/19/2018 10:41 AM, Roger Bivand wrote:
>> On Tue, 19 Jun 2018, Tomislav Hengl wrote:
>>
>>> Two weeks ago I installed new GDAL 2.3.* from source, then tried
>>> installing rgdal and got the error about GDAL requires C++11. Then I
>>> had
>>> to remove everything and reinstall GDAL 2.2. Would love to be able to
>>> start using the newest GDAL inside R as it seems that many things have
>>> been improved
>>> (https://trac.osgeo.org/gdal/query?group=status&milestone=2.3.0).
>>> Installing GDAL from source takes >20mins so next time I would like to
>>> be sure that I will not have to remove GDAL.
>>>
>>> Can somebody point to a step-by-step guide to install GDAL 2.3.* and
>>> rgdal on ubuntu (now that all packages have been updated)?
>>
>> Tom:
>>
>> There is too little information here: which g++ compiler version, was
>> R installed from source or not, GDAL was installed from source, but
>> was PROJ installed from source (and/or GEOS), ... and no verbatim
>> error message.
>>
>> Please try development rgdal_1.3-3 from R-forge, which has some logic
>> fixes in configure:
>>
>> install.packages("rgdal", repos="http://R-Forge.R-project.org")
>>
>> Did you check whether sf installed with GDAL 2.3.0 and PROJ 5.1.0?
>>
>> It looks as though CRAN devel debian is using GDAL 2.3.0 (the test
>> saved output is 2.2.4):
>>
>> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/rgdal-00check.html 
>>
>>
>> Hope this helps,
>>
>> Roger
>>
>>>
>>> Much appreciated!
>>>
>>> My session info:
>>>
>>> > library(rgdal)
>>> Loading required package: sp
>>> rgdal: version: 1.2-20, (SVN revision 725)
>>>  Geospatial Data Abstraction Library extensions to R successfully
>>> loaded
>>>  Loaded GDAL runtime: GDAL 2.2.2, released 2017/09/15
>>>  Path to GDAL shared files: /usr/share/gdal/2.2
>>>  GDAL binary built with GEOS: TRUE
>>>  Loaded PROJ.4 runtime: Rel. 4.9.2, 08 September 2015, [PJ_VERSION:
>>> 492]
>>>  Path to PROJ.4 shared files: (autodetected)
>>>  Linking to sp version: 1.2-7
>>> > sessionInfo()
>>> R version 3.5.0 (2018-04-23)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 16.04.4 LTS
>>>
>>> Matrix products: default
>>> BLAS: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRblas.so
>>> LAPACK: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRlapack.so
>>>
>>>
>>>
>>> On 19.06.2018 08:47, Roger Bivand wrote:
>>>> On Mon, 18 Jun 2018, MacQueen, Don wrote:
>>>>
>>>>> Success!
>>>>>
>>>>> This morning I upgraded a Mac to OS 10.13.5 (the so-called High
>>>>> Sierra version), then
>>>>>
>>>>> - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
>>>>> - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3,
>>>>> from the
>>>>>   CRAN binaries that are now available
>>>>> - Ran my personal test suite, which exercises the kinds of tasks I
>>>>>   perform with those packages
>>>>>
>>>>> All tests succeeded.
>>>>
>>>> Thanks for reporting - especially on your own test suite. We do what
>>>> we can to cover typical use cases, but independent testing in
>>>> production settings is reassuring for everybody. We're expecting more
>>>> PROJ-based changes later this year and next year, so it is great to
>>>> have external test sets to be able to check where any changes in
>>>> output are coming from.
>>>>
>>>> This is an encouragement to other users whose production depends on R
>>>> packages using GDAL, PROJ and/or GEOS to follow this example and keep
>>>> a script handy to test your use cases, and a history of output files
>>>> with which to compare (diff). We don't worry about changes in the EPSG
>>>> versions, but by next year they may be properly anchored too (changes
>>>> in PROJ may include reference system definitions with timestamps).
>>>>
>>>>>
>>>>> I forgot to control the order of installation, so I don't know if I
>>>>> installed sp first, as advised. But I expect that with the binary
>>>>> versions it doesn't matter.
>>>>
>>>> Right, the binary builds use the sp version on the build platform.
>>>>
>>>> Best wishes,
>>>>
>>>> Roger
>>>>
>>>>>
>>>>> (I don't think it matters for the above, but I also installed the
>>>>> clang and gfortran version provided on CRAN's Mac "tools" page, and
>>>>> successfully compiled some source packages that require fortran, and
>>>>> others that require C).
>>>>>
>>>>> Thank again for all your work
>>>>> -Don
>>>>>
>>>>> --
>>>>> Don MacQueen
>>>>> Lawrence Livermore National Laboratory
>>>>> 7000 East Ave., L-627
>>>>> Livermore, CA 94550
>>>>> 925-423-1062
>>>>> Lab cell 925-724-7509
>>>>>
>>>>>
>>>>>
>>>>> On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand"
>>>>> <[hidden email] on behalf of [hidden email]>
>>>>> wrote:
>>>>>
>>>>>    There are new releases of sp, rgdal and rgeos on CRAN. Please
>>>>> install sp
>>>>>    first, then the other two, which link to the installed sp. They
>>>>> all
>>>>>    address so-called rchk issues, which have not so far been a
>>>>> problem, but
>>>>>    might have become more fragile as R's internal memory management
>>>>> is made
>>>>>    even more efficient. This involves compiled code using memory
>>>>> allocated by
>>>>>    R to be freed by R's garbage collector, which has to know if an
>>>>> object is
>>>>>    still being used. Tomas Kalibera, the author of rchk, helped
>>>>> resolve and
>>>>>    explain the issues encountered - what was good coding practice
>>>>> fifteen
>>>>>    years ago isn't always still good practice.
>>>>>
>>>>>    In addition, the earliest versions of GDAL and PROJ with which
>>>>> rgdal will
>>>>>    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The
>>>>> current
>>>>>    released versions of PROJ and GDAL are to be prefered, as bugs
>>>>> have been
>>>>>    fixed and new features and drivers introduced. A check has been
>>>>> put
>>>>>    in place to trap attempts to install rgdal without a C++11-capable
>>>>>    compiler when the GDAL version is >=2.3.0 - which requires C++11.
>>>>> rgeos is
>>>>>    ready for the forthcoming version of GEOS.
>>>>>
>>>>>    The CRAN team has also been very supportive of our efforts to
>>>>> bring
>>>>>    compiled code in these packages into rchk compliance.
>>>>>
>>>>>    Please get in touch if you see any loose ends in these releases.
>>>>>
>>>>>    Roger
>>>>>
>>>>>    --
>>>>>    Roger Bivand
>>>>>    Department of Economics, Norwegian School of Economics,
>>>>>    Helleveien 30, N-5045 Bergen, Norway.
>>>>>    voice: +47 55 95 93 55; e-mail: [hidden email]
>>>>>    http://orcid.org/0000-0003-2392-6140
>>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>>
>>>>>    _______________________________________________
>>>>>    R-sig-Geo mailing list
>>>>>    [hidden email]
>>>>>    https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> R-sig-Geo mailing list
>>>> [hidden email]
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>>
>>>     [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Upcoming bugfix release of rgdal

Sat, 06/23/2018 - 06:58
Thanks for this report for the record, and constructive input from many; rgdal 1.3-3 on CRAN, with positive help from Uwe Ligges.

Roger

Roger Bivand
Norwegian School of Economics
Bergen, Norway



Fra: Rainer Hurling
Sendt: torsdag 21. juni, 12.52
Emne: Re: [R-sig-Geo] Upcoming bugfix release of rgdal
Til: [hidden email]


Am 21.06.2018 um 08:22 schrieb Roger Bivand: > The upcoming submission to CRAN of rgdal 1.3-3 is at: > >  install.packages("rgdal", repos="http://R-Forge.R-project.org") > > for source and Windows binary testing. It fixes logic errors in handling > cases reported mostly for source installs on Linux since 1.3-2. These > affected CentOS 7 and GDAL 1.11.4, and other cases affected by the new > GDAL 2.3.0 requirement that the C++ compiler be C++11 compliant. > > rgdal 1.3-2 passes CRAN checks on both Debian and Fedora systems, so we > are reliant on feedback to identify remaining issues. > > If anyone is still having problems, please get in touch immediately to > try to resolve them before I submit to CRAN. > > Roger > rgdal maintainer > JFTR: rgdal-1.3.3 builds and installs fine on FreeBSD 12.0-CURRENT amd64. #library(rgdal) Lade nötiges Paket: sp rgdal: version: 1.3-3, (SVN revision (unknown)) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 2.2.4, released 2018/03/19 Path to GDAL shared files: /usr/local/share/gdal GDAL binary built with GEOS: TRUE Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493] Path to PROJ.4 shared files: (autodetected) Linking to sp version: 1.3-1 Thanks for the hard work. _______________________________________________ R-sig-Geo mailing list [hidden email] https://stat.ethz.ch/mailman/listinfo/r-sig-geo


        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Fwd: Summer School in Geocomputation - Berkeley - USA

Sat, 06/23/2018 - 03:26
Dear colleagues,

With the objective of enhancing programming skills in Geocomputation and
prepare new scientists in deals with large geo-data,

in August 2018 we organize a summer school at Berkeley.

*International Summer School:*

*Geocomputation using free and Open Source Software** (20th-24th August
2018) *

organized by Spatial Ecology (www.spatial-ecology.net)
<http://www.spatial-ecology.net/> - Venue: *Berkeley Institute of Data
Science <https://bids.berkeley.edu/>*

A 5 days intense experience opening new horizons on the use of the vast
potentials of *Linux* environment and the command line approach for
*geo-data* massive processing using Bash, AWK, Python, GRASS, QGIS,
GDAL/OGR, R, PKtools. We will guide newbies and experienced GIS users who
have never used a command line terminal to a stage which will allow them to
understand and apply very advanced open source data processing routines.
Our focus is to enhance a self-learning approach. This allows participants
to keep on progressing and improving their skills in a continuously
evolving technological environment.

More information and registration:

www.spatial-ecology.net
www.facebook.com/spatialecology  -> event
<https://www.facebook.com/events/202252593719455/>

twitter: @BigDataEcology

Best regards
Spatial Ecology – Team

--
Giuseppe Amatulli, Ph.D.

Research scientist at
Yale School of Forestry & Environmental Studies
Yale Center for Research Computing
Center for Science and Social Science Information
New Haven, 06511
Teaching: http://spatial-ecology.net
Work:  https://environment.yale.edu/profile/giuseppe-amatulli/



--
Giuseppe Amatulli, Ph.D.

Research scientist at
Yale School of Forestry & Environmental Studies
Yale Center for Research Computing
Center for Science and Social Science Information
New Haven, 06511
Teaching: http://spatial-ecology.net
Work:  https://environment.yale.edu/profile/giuseppe-amatulli/

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Question about correcting for spatial autocorrelation

Fri, 06/22/2018 - 02:42
On Fri, 22 Jun 2018, Julie Lee-Yaw via R-sig-Geo wrote:

> Hi 
> I've posted this to the mixed models forum as well but thought people
> here might know:
> I want to use the the correlation setting with corSpher in nlme to
> account for potential spatial autocorrelation in my data. My data
> include observations from across the globe with locations in latitude
> and longitude (decimal degrees). From the R help for corSpher, the
> syntax for their wheat example would be something like:

Nothing in the documentation nor the underlying book suggests that the
coordinates are anything other than planar, so geographical coordinates in
decimal degrees should not be used. Unfortunately, I do not have access to
the underlying article in crop science, but there is no reason to think
that the agricultural experiment extended from France to Turkey and France
to south of Ghana. The documentation in nlme::corSpher() refers to
stats::dist, and I can't see any way to insert fields::rdist.earth() in
its place. So you can safely accept that the coefficients must be
projected (i.e. planar). This is all accessible in the documentation and
Pinheiro & Bates (2000). It is pretty certain that they did not envisage
global scope in geographical coordinates, so maybe you should be using
fields or gstat which are more likely to be able to handle Great Circle
distances.

Hope this clarifies,

Roger

> fm1Wheat2 <- gls(yield ~ variety - 1, corr =corSpher(c(28, 0.2), form =
> + ~ latitude + longitude, nugget = TRUE))
>
> My question is whether the latitude and longitude provided should be
> projected into a spatial projection that preserves distances or areas or
> whether providing decimal degrees is appropriate?

> Many thanks!

Please post plain text.

> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> 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: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Question about correcting for spatial autocorrelation

Thu, 06/21/2018 - 19:14
Hi 
I've posted this to the mixed models forum as well but thought people here might know:
I want to use the the correlation setting with corSpher in nlme to account for potential spatial autocorrelation in my data. My data include observations from across the globe with locations in latitude and longitude (decimal degrees). From the R help for corSpher, the syntax for their wheat example would be something like:
fm1Wheat2 <- gls(yield ~ variety - 1, corr =corSpher(c(28, 0.2), form = ~ latitude + longitude, nugget = TRUE))

My question is whether the latitude and longitude provided should be projected into a spatial projection that preserves distances or areas or whether providing decimal degrees is appropriate?
Many thanks!
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Upcoming bugfix release of rgdal

Thu, 06/21/2018 - 05:52
Am 21.06.2018 um 08:22 schrieb Roger Bivand:
> The upcoming submission to CRAN of rgdal 1.3-3 is at:
>
>   install.packages("rgdal", repos="http://R-Forge.R-project.org")
>
> for source and Windows binary testing. It fixes logic errors in handling
> cases reported mostly for source installs on Linux since 1.3-2. These
> affected CentOS 7 and GDAL 1.11.4, and other cases affected by the new
> GDAL 2.3.0 requirement that the C++ compiler be C++11 compliant.
>
> rgdal 1.3-2 passes CRAN checks on both Debian and Fedora systems, so we
> are reliant on feedback to identify remaining issues.
>
> If anyone is still having problems, please get in touch immediately to
> try to resolve them before I submit to CRAN.
>
> Roger
> rgdal maintainer
>
JFTR:
rgdal-1.3.3 builds and installs fine on FreeBSD 12.0-CURRENT amd64.


#library(rgdal)
Lade nötiges Paket: sp
rgdal: version: 1.3-3, (SVN revision (unknown))
  Geospatial Data Abstraction Library extensions to R successfully loaded
  Loaded GDAL runtime: GDAL 2.2.4, released 2018/03/19
  Path to GDAL shared files: /usr/local/share/gdal
  GDAL binary built with GEOS: TRUE
  Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
  Path to PROJ.4 shared files: (autodetected)
  Linking to sp version: 1.3-1


Thanks for the hard work.

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Upcoming bugfix release of rgdal

Thu, 06/21/2018 - 01:22
The upcoming submission to CRAN of rgdal 1.3-3 is at:

  install.packages("rgdal", repos="http://R-Forge.R-project.org")

for source and Windows binary testing. It fixes logic errors in handling
cases reported mostly for source installs on Linux since 1.3-2. These
affected CentOS 7 and GDAL 1.11.4, and other cases affected by the new
GDAL 2.3.0 requirement that the C++ compiler be C++11 compliant.

rgdal 1.3-2 passes CRAN checks on both Debian and Fedora systems, so we
are reliant on feedback to identify remaining issues.

If anyone is still having problems, please get in touch immediately to try
to resolve them before I submit to CRAN.

Roger
rgdal maintainer

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: nb object in spdep from categorical attribute

Wed, 06/20/2018 - 10:43
Thanks so much.

The nb2blocknb(), aggregate.nb(), and union.nb() are fantastic functions!
Between these three functions I that I had not seen before I can accomplish
what I am seeking. It looks like the new spdep vignette has been greatly
expanded, which is also fantastic.

Thanks again,
Dexter


On Wed, Jun 20, 2018 at 8:24 AM Roger Bivand <[hidden email]> wrote:

> On Tue, 19 Jun 2018, Dexter Locke wrote:
>
> > Dear list,
> >
> > Does anyone know how to make nb objects (to eventually make spatial
> > weights) with spdep using an attribute in a shapefile's data frame?
> >
> > Consider, for example, all property parcels on the same street segment
> > should be defined as neighbors. In the parcel polygons I have the
> > associated street segment name.
> >
> > KNN forces sparsely settled areas to become neighbors, which is
> undesirable
> > for the subsequent analyses.
> >
> > Distances between parcels vary, so distance-based neighbors are also
> > undesirable in this case.
> >
> > Contiguity-based methods do not connect parcels on opposite sites of the
> > same street segment.
> >
> > Is there a way to use an attribute to define what constitutes a neighbor?
>
> Yes, spdep::nb2blocknb() is a specific case where say observations without
> positional data are known to belong to an aggregate entity for which we
> have positional data. The output is an nb object with diagonal blocks (if
> the observations are sorted by block ID, not in the case below), as this
> example shows. You'll need the development version to run it, as released
> spdep::aggregate.nb() failed with empty aggregate sets - the nc median
> poish grid has such empty sets:
>
> # devtools::install.github("r-spatial/spdep")
> library(spdep)
> data(nc.sids)
> ncCC89.nb[sapply(ncCC89.nb, length) == 0L] <- 0L
> image(as(nb2listw(ncCC89.nb, zero.policy=TRUE), "CsparseMatrix"))
> anb <- aggregate(ncCC89.nb, interaction(nc.sids$M.id, nc.sids$L.id))
> image(as(nb2listw(anb, style="B"), "CsparseMatrix"))
> # when the neighbour object is not empty
> bnb <- nb2blocknb(anb, as.character(interaction(nc.sids$M.id,
>    nc.sids$L.id)))
> image(as(nb2listw(bnb, style="B"), "CsparseMatrix"))
> # and when the neighbour object is empty
> anb1 <- lapply(anb, function(x) x <- 0L)
> attributes(anb1) <- attributes(anb)
> bnb1 <- nb2blocknb(anb1, as.character(interaction(nc.sids$M.id,
>    nc.sids$L.id)))
> image(as(nb2listw(bnb1, style="B"), "CsparseMatrix"))
>
> This isn't your case, but crafting an nb object by hand (adding
> attributes after creating the list) then using spdep::union.nb or similar
> to combine with a positional nb (such as poly2nb) may work. For parcels
> across a stream or street, maybe look at the snap= argument if the streets
> are narrower than frontages. Could you provide a small reproducible
> example?
>
> Hope this clarifies,
>
> Roger
>
> >
> > All ideas welcome,
> > Dexter
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > 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: [hidden email]
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: nb object in spdep from categorical attribute

Wed, 06/20/2018 - 07:24
On Tue, 19 Jun 2018, Dexter Locke wrote:

> Dear list,
>
> Does anyone know how to make nb objects (to eventually make spatial
> weights) with spdep using an attribute in a shapefile's data frame?
>
> Consider, for example, all property parcels on the same street segment
> should be defined as neighbors. In the parcel polygons I have the
> associated street segment name.
>
> KNN forces sparsely settled areas to become neighbors, which is undesirable
> for the subsequent analyses.
>
> Distances between parcels vary, so distance-based neighbors are also
> undesirable in this case.
>
> Contiguity-based methods do not connect parcels on opposite sites of the
> same street segment.
>
> Is there a way to use an attribute to define what constitutes a neighbor?
Yes, spdep::nb2blocknb() is a specific case where say observations without
positional data are known to belong to an aggregate entity for which we
have positional data. The output is an nb object with diagonal blocks (if
the observations are sorted by block ID, not in the case below), as this
example shows. You'll need the development version to run it, as released
spdep::aggregate.nb() failed with empty aggregate sets - the nc median
poish grid has such empty sets:

# devtools::install.github("r-spatial/spdep")
library(spdep)
data(nc.sids)
ncCC89.nb[sapply(ncCC89.nb, length) == 0L] <- 0L
image(as(nb2listw(ncCC89.nb, zero.policy=TRUE), "CsparseMatrix"))
anb <- aggregate(ncCC89.nb, interaction(nc.sids$M.id, nc.sids$L.id))
image(as(nb2listw(anb, style="B"), "CsparseMatrix"))
# when the neighbour object is not empty
bnb <- nb2blocknb(anb, as.character(interaction(nc.sids$M.id,
   nc.sids$L.id)))
image(as(nb2listw(bnb, style="B"), "CsparseMatrix"))
# and when the neighbour object is empty
anb1 <- lapply(anb, function(x) x <- 0L)
attributes(anb1) <- attributes(anb)
bnb1 <- nb2blocknb(anb1, as.character(interaction(nc.sids$M.id,
   nc.sids$L.id)))
image(as(nb2listw(bnb1, style="B"), "CsparseMatrix"))

This isn't your case, but crafting an nb object by hand (adding
attributes after creating the list) then using spdep::union.nb or similar
to combine with a positional nb (such as poly2nb) may work. For parcels
across a stream or street, maybe look at the snap= argument if the streets
are narrower than frontages. Could you provide a small reproducible
example?

Hope this clarifies,

Roger

>
> All ideas welcome,
> Dexter
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> 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: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

nb object in spdep from categorical attribute

Tue, 06/19/2018 - 14:40
Dear list,

Does anyone know how to make nb objects (to eventually make spatial
weights) with spdep using an attribute in a shapefile's data frame?

Consider, for example, all property parcels on the same street segment
should be defined as neighbors. In the parcel polygons I have the
associated street segment name.

KNN forces sparsely settled areas to become neighbors, which is undesirable
for the subsequent analyses.

Distances between parcels vary, so distance-based neighbors are also
undesirable in this case.

Contiguity-based methods do not connect parcels on opposite sites of the
same street segment.

Is there a way to use an attribute to define what constitutes a neighbor?

All ideas welcome,
Dexter

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: CRAN releases of sp, rgdal and rgeos

Tue, 06/19/2018 - 09:57

Hi Roger,

I have now managed to reinstall GDAL 2.3 and the latest versions of
rgdal and sf. These are the steps I have followed:

1. First remove existing installation of GDAL using:

sudo apt-get purge --auto-remove gdal-bin

*this also removes QGIS / anything linked with GDAL.

2. Download GDAL source code
(https://trac.osgeo.org/gdal/wiki/DownloadSource) and follow the
instructions to install from source
(https://trac.osgeo.org/gdal/wiki/BuildingOnUnix)

3. Installation from source code takes quite some time (10-15 minutes).
After that I get:

gdalinfo --version
GDAL 2.3.0, released 2018/05/04

4. Install rgdal from R-forge using e.g.:

R CMD INSTALL rgdal_1.3-3.tar.gz
* installing to library ‘/opt/microsoft/ropen/3.4.3/lib64/R/library’
* installing *source* package ‘rgdal’ ...
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: CC: gcc -std=gnu99
configure: CXX: g++
configure: rgdal: 1.3-3
checking for /usr/bin/svnversion... yes
cat: inst/SVN_VERSION: No such file or directory
configure: svn revision:
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... yes
configure: C++11 support available
checking for gdal-config... /usr/local/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 2.3.0
checking C++11 support for GDAL >= 2.3.0... yes
checking GDAL version >= 1.11.4... yes
checking gdal: linking with --libs only... yes
checking GDAL: /usr/local/share/gdal/pcs.csv readable... yes
configure: pkg-config proj exists, will use it
configure: PROJ version: 4.9.2
checking proj_api.h presence and usability... yes
checking PROJ version >= 4.8.0... yes
checking projects.h presence and usability... yes
checking PROJ.4: epsg found and readable... yes
checking PROJ.4: conus found and readable... yes
configure: Package CPP flags:  -I/usr/local/include
configure: Package LIBS:  -L/usr/local/lib -lgdal -lproj
configure: creating ./config.status

For sf I had to manually update DBI and units packages as it requires
newest versions.

So now everything works fine. Thank you!

Tom

On 06/19/2018 10:41 AM, Roger Bivand wrote:
> On Tue, 19 Jun 2018, Tomislav Hengl wrote:
>
>> Two weeks ago I installed new GDAL 2.3.* from source, then tried
>> installing rgdal and got the error about GDAL requires C++11. Then I had
>> to remove everything and reinstall GDAL 2.2. Would love to be able to
>> start using the newest GDAL inside R as it seems that many things have
>> been improved
>> (https://trac.osgeo.org/gdal/query?group=status&milestone=2.3.0).
>> Installing GDAL from source takes >20mins so next time I would like to
>> be sure that I will not have to remove GDAL.
>>
>> Can somebody point to a step-by-step guide to install GDAL 2.3.* and
>> rgdal on ubuntu (now that all packages have been updated)?
>
> Tom:
>
> There is too little information here: which g++ compiler version, was R
> installed from source or not, GDAL was installed from source, but was
> PROJ installed from source (and/or GEOS), ... and no verbatim error
> message.
>
> Please try development rgdal_1.3-3 from R-forge, which has some logic
> fixes in configure:
>
> install.packages("rgdal", repos="http://R-Forge.R-project.org")
>
> Did you check whether sf installed with GDAL 2.3.0 and PROJ 5.1.0?
>
> It looks as though CRAN devel debian is using GDAL 2.3.0 (the test saved
> output is 2.2.4):
>
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/rgdal-00check.html 
>
>
> Hope this helps,
>
> Roger
>
>>
>> Much appreciated!
>>
>> My session info:
>>
>> > library(rgdal)
>> Loading required package: sp
>> rgdal: version: 1.2-20, (SVN revision 725)
>>  Geospatial Data Abstraction Library extensions to R successfully loaded
>>  Loaded GDAL runtime: GDAL 2.2.2, released 2017/09/15
>>  Path to GDAL shared files: /usr/share/gdal/2.2
>>  GDAL binary built with GEOS: TRUE
>>  Loaded PROJ.4 runtime: Rel. 4.9.2, 08 September 2015, [PJ_VERSION: 492]
>>  Path to PROJ.4 shared files: (autodetected)
>>  Linking to sp version: 1.2-7
>> > sessionInfo()
>> R version 3.5.0 (2018-04-23)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 16.04.4 LTS
>>
>> Matrix products: default
>> BLAS: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRblas.so
>> LAPACK: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRlapack.so
>>
>>
>>
>> On 19.06.2018 08:47, Roger Bivand wrote:
>>> On Mon, 18 Jun 2018, MacQueen, Don wrote:
>>>
>>>> Success!
>>>>
>>>> This morning I upgraded a Mac to OS 10.13.5 (the so-called High
>>>> Sierra version), then
>>>>
>>>> - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
>>>> - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3, from
>>>> the
>>>>   CRAN binaries that are now available
>>>> - Ran my personal test suite, which exercises the kinds of tasks I
>>>>   perform with those packages
>>>>
>>>> All tests succeeded.
>>>
>>> Thanks for reporting - especially on your own test suite. We do what
>>> we can to cover typical use cases, but independent testing in
>>> production settings is reassuring for everybody. We're expecting more
>>> PROJ-based changes later this year and next year, so it is great to
>>> have external test sets to be able to check where any changes in
>>> output are coming from.
>>>
>>> This is an encouragement to other users whose production depends on R
>>> packages using GDAL, PROJ and/or GEOS to follow this example and keep
>>> a script handy to test your use cases, and a history of output files
>>> with which to compare (diff). We don't worry about changes in the EPSG
>>> versions, but by next year they may be properly anchored too (changes
>>> in PROJ may include reference system definitions with timestamps).
>>>
>>>>
>>>> I forgot to control the order of installation, so I don't know if I
>>>> installed sp first, as advised. But I expect that with the binary
>>>> versions it doesn't matter.
>>>
>>> Right, the binary builds use the sp version on the build platform.
>>>
>>> Best wishes,
>>>
>>> Roger
>>>
>>>>
>>>> (I don't think it matters for the above, but I also installed the
>>>> clang and gfortran version provided on CRAN's Mac "tools" page, and
>>>> successfully compiled some source packages that require fortran, and
>>>> others that require C).
>>>>
>>>> Thank again for all your work
>>>> -Don
>>>>
>>>> --
>>>> Don MacQueen
>>>> Lawrence Livermore National Laboratory
>>>> 7000 East Ave., L-627
>>>> Livermore, CA 94550
>>>> 925-423-1062
>>>> Lab cell 925-724-7509
>>>>
>>>>
>>>>
>>>> On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand"
>>>> <[hidden email] on behalf of [hidden email]>
>>>> wrote:
>>>>
>>>>    There are new releases of sp, rgdal and rgeos on CRAN. Please
>>>> install sp
>>>>    first, then the other two, which link to the installed sp. They all
>>>>    address so-called rchk issues, which have not so far been a
>>>> problem, but
>>>>    might have become more fragile as R's internal memory management
>>>> is made
>>>>    even more efficient. This involves compiled code using memory
>>>> allocated by
>>>>    R to be freed by R's garbage collector, which has to know if an
>>>> object is
>>>>    still being used. Tomas Kalibera, the author of rchk, helped
>>>> resolve and
>>>>    explain the issues encountered - what was good coding practice
>>>> fifteen
>>>>    years ago isn't always still good practice.
>>>>
>>>>    In addition, the earliest versions of GDAL and PROJ with which
>>>> rgdal will
>>>>    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The
>>>> current
>>>>    released versions of PROJ and GDAL are to be prefered, as bugs
>>>> have been
>>>>    fixed and new features and drivers introduced. A check has been put
>>>>    in place to trap attempts to install rgdal without a C++11-capable
>>>>    compiler when the GDAL version is >=2.3.0 - which requires C++11.
>>>> rgeos is
>>>>    ready for the forthcoming version of GEOS.
>>>>
>>>>    The CRAN team has also been very supportive of our efforts to bring
>>>>    compiled code in these packages into rchk compliance.
>>>>
>>>>    Please get in touch if you see any loose ends in these releases.
>>>>
>>>>    Roger
>>>>
>>>>    --
>>>>    Roger Bivand
>>>>    Department of Economics, Norwegian School of Economics,
>>>>    Helleveien 30, N-5045 Bergen, Norway.
>>>>    voice: +47 55 95 93 55; e-mail: [hidden email]
>>>>    http://orcid.org/0000-0003-2392-6140
>>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>>
>>>>    _______________________________________________
>>>>    R-sig-Geo mailing list
>>>>    [hidden email]
>>>>    https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

adonis2 in vegan (distance or abundance matrix)

Tue, 06/19/2018 - 08:38
Der list,

i have came across this interesting feature of vegan's adonis2.

The example in ?adonis2 shows that adonis2takes an abundance matrix, and
converts it to a distance matrix, as given in "method":

library(vegan)
data(dune)
data(dune.env)

ad1 <- adonis2(dune ~ Management*A1, data = dune.env, method="bray")

Permutation test for adonis under reduced model Terms added sequentially
(first to last) Permutation: free Number of permutations: 999
adonis2(formula = dune ~ Management * A1, data = dune.env, method =
"bray") Df SumOfSqs R2 F Pr(>F) Management 3 1.4686 0.34161 3.2629 0.003
** A1 1 0.4409 0.10256 2.9387 0.022 * Management:A1 3 0.5892 0.13705
1.3090 0.228 Residual 12 1.8004 0.41878 Total 19 4.2990 1.00000 ---
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

However, it can also handle the direct input of the distance matrix:
dune.dist <- vegdist(dune, method="bray")
ad2 <- adonis2(dune.dist~Management*A1, data = dune.env, method="bray")

Permutation test for adonis under reduced model Terms added sequentially
(first to last) Permutation: free Number of permutations: 999
adonis2(formula = dune.dist ~ Management * A1, data = dune.env, method =
"bray") Df SumOfSqs R2 F Pr(>F) Management 3 1.4686 0.34161 3.2629 0.001
*** A1 1 0.4409 0.10256 2.9387 0.009 ** Management:A1 3 0.5892 0.13705
1.3090 0.213 Residual 12 1.8004 0.41878 Total 19 4.2990 1.00000 ---
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Apparently, method="bray" is ignored. Here i thought, because dune.dist
is a already dist-class object, adonis2 abandons the step of creating a
distance matrix. However, if i convert the dist-object into a dataframe,
the output is still the same!

dune.df <- as.data.frame(as.matrix(vegdist(dune, method="bray")))
str(dune.df)

ad3 <- adonis2(dune.df~Management*A1, data = dune.env, method="bray")

Permutation test for adonis under reduced model Terms added sequentially
(first to last) Permutation: free Number of permutations: 999
adonis2(formula = dune.df ~ Management * A1, data = dune.env, method =
"bray") Df SumOfSqs R2 F Pr(>F) Management 3 1.4686 0.34161 3.2629 0.004
** A1 1 0.4409 0.10256 2.9387 0.016 * Management:A1 3 0.5892 0.13705
1.3090 0.221 Residual 12 1.8004 0.41878 Total 19 4.2990 1.00000

Even though, method="bray" is specified, dune.df is not converted to a
dist-object. How is it possible that dune, dune.dist, and dune.df all
give the same result, despite having different dimensions and classes?

> ad1 == ad2 Df SumOfSqs R2 F Pr(>F) Management TRUE TRUE TRUE TRUE FALSE
A1 TRUE TRUE TRUE TRUE FALSE Management:A1 TRUE TRUE TRUE TRUE FALSE
Residual TRUE TRUE TRUE NA NA Total TRUE TRUE TRUE NA NA > ad2 == ad3 Df
SumOfSqs R2 F Pr(>F) Management TRUE TRUE TRUE TRUE FALSE A1 TRUE TRUE
TRUE TRUE FALSE Management:A1 TRUE TRUE TRUE TRUE FALSE Residual TRUE
TRUE TRUE NA NA Total TRUE TRUE TRUE NA NA

Thank you!

--
Dr. Tim Richter-Heitmann

University of Bremen
Microbial Ecophysiology Group (AG Friedrich)
FB02 - Biologie/Chemie
Leobener Straße (NW2 A2130)
D-28359 Bremen
Tel.: 0049(0)421 218-63062
Fax: 0049(0)421 218-63069


        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: CRAN releases of sp, rgdal and rgeos

Tue, 06/19/2018 - 03:41
On Tue, 19 Jun 2018, Tomislav Hengl wrote:

> Two weeks ago I installed new GDAL 2.3.* from source, then tried
> installing rgdal and got the error about GDAL requires C++11. Then I had
> to remove everything and reinstall GDAL 2.2. Would love to be able to
> start using the newest GDAL inside R as it seems that many things have
> been improved
> (https://trac.osgeo.org/gdal/query?group=status&milestone=2.3.0).
> Installing GDAL from source takes >20mins so next time I would like to
> be sure that I will not have to remove GDAL.
>
> Can somebody point to a step-by-step guide to install GDAL 2.3.* and
> rgdal on ubuntu (now that all packages have been updated)? Tom:

There is too little information here: which g++ compiler version, was R
installed from source or not, GDAL was installed from source, but was PROJ
installed from source (and/or GEOS), ... and no verbatim error message.

Please try development rgdal_1.3-3 from R-forge, which has some logic
fixes in configure:

install.packages("rgdal", repos="http://R-Forge.R-project.org")

Did you check whether sf installed with GDAL 2.3.0 and PROJ 5.1.0?

It looks as though CRAN devel debian is using GDAL 2.3.0 (the test saved
output is 2.2.4):

https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/rgdal-00check.html

Hope this helps,

Roger

>
> Much appreciated!
>
> My session info:
>
> > library(rgdal)
> Loading required package: sp
> rgdal: version: 1.2-20, (SVN revision 725)
>  Geospatial Data Abstraction Library extensions to R successfully loaded
>  Loaded GDAL runtime: GDAL 2.2.2, released 2017/09/15
>  Path to GDAL shared files: /usr/share/gdal/2.2
>  GDAL binary built with GEOS: TRUE
>  Loaded PROJ.4 runtime: Rel. 4.9.2, 08 September 2015, [PJ_VERSION: 492]
>  Path to PROJ.4 shared files: (autodetected)
>  Linking to sp version: 1.2-7
> > sessionInfo()
> R version 3.5.0 (2018-04-23)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 16.04.4 LTS
>
> Matrix products: default
> BLAS: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRblas.so
> LAPACK: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRlapack.so
>
>
>
> On 19.06.2018 08:47, Roger Bivand wrote:
>> On Mon, 18 Jun 2018, MacQueen, Don wrote:
>>
>>> Success!
>>>
>>> This morning I upgraded a Mac to OS 10.13.5 (the so-called High
>>> Sierra version), then
>>>
>>> - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
>>> - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3, from the
>>>   CRAN binaries that are now available
>>> - Ran my personal test suite, which exercises the kinds of tasks I
>>>   perform with those packages
>>>
>>> All tests succeeded.
>>
>> Thanks for reporting - especially on your own test suite. We do what
>> we can to cover typical use cases, but independent testing in
>> production settings is reassuring for everybody. We're expecting more
>> PROJ-based changes later this year and next year, so it is great to
>> have external test sets to be able to check where any changes in
>> output are coming from.
>>
>> This is an encouragement to other users whose production depends on R
>> packages using GDAL, PROJ and/or GEOS to follow this example and keep
>> a script handy to test your use cases, and a history of output files
>> with which to compare (diff). We don't worry about changes in the EPSG
>> versions, but by next year they may be properly anchored too (changes
>> in PROJ may include reference system definitions with timestamps).
>>
>>>
>>> I forgot to control the order of installation, so I don't know if I
>>> installed sp first, as advised. But I expect that with the binary
>>> versions it doesn't matter.
>>
>> Right, the binary builds use the sp version on the build platform.
>>
>> Best wishes,
>>
>> Roger
>>
>>>
>>> (I don't think it matters for the above, but I also installed the
>>> clang and gfortran version provided on CRAN's Mac "tools" page, and
>>> successfully compiled some source packages that require fortran, and
>>> others that require C).
>>>
>>> Thank again for all your work
>>> -Don
>>>
>>> --
>>> Don MacQueen
>>> Lawrence Livermore National Laboratory
>>> 7000 East Ave., L-627
>>> Livermore, CA 94550
>>> 925-423-1062
>>> Lab cell 925-724-7509
>>>
>>>
>>>
>>> On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand"
>>> <[hidden email] on behalf of [hidden email]>
>>> wrote:
>>>
>>>    There are new releases of sp, rgdal and rgeos on CRAN. Please
>>> install sp
>>>    first, then the other two, which link to the installed sp. They all
>>>    address so-called rchk issues, which have not so far been a
>>> problem, but
>>>    might have become more fragile as R's internal memory management
>>> is made
>>>    even more efficient. This involves compiled code using memory
>>> allocated by
>>>    R to be freed by R's garbage collector, which has to know if an
>>> object is
>>>    still being used. Tomas Kalibera, the author of rchk, helped
>>> resolve and
>>>    explain the issues encountered - what was good coding practice
>>> fifteen
>>>    years ago isn't always still good practice.
>>>
>>>    In addition, the earliest versions of GDAL and PROJ with which
>>> rgdal will
>>>    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The
>>> current
>>>    released versions of PROJ and GDAL are to be prefered, as bugs
>>> have been
>>>    fixed and new features and drivers introduced. A check has been put
>>>    in place to trap attempts to install rgdal without a C++11-capable
>>>    compiler when the GDAL version is >=2.3.0 - which requires C++11.
>>> rgeos is
>>>    ready for the forthcoming version of GEOS.
>>>
>>>    The CRAN team has also been very supportive of our efforts to bring
>>>    compiled code in these packages into rchk compliance.
>>>
>>>    Please get in touch if you see any loose ends in these releases.
>>>
>>>    Roger
>>>
>>>    --
>>>    Roger Bivand
>>>    Department of Economics, Norwegian School of Economics,
>>>    Helleveien 30, N-5045 Bergen, Norway.
>>>    voice: +47 55 95 93 55; e-mail: [hidden email]
>>>    http://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>>
>>>    _______________________________________________
>>>    R-sig-Geo mailing list
>>>    [hidden email]
>>>    https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> 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: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: CRAN releases of sp, rgdal and rgeos

Tue, 06/19/2018 - 02:55
Two weeks ago I installed new GDAL 2.3.* from source, then tried
installing rgdal and got the error about GDAL requires C++11. Then I had
to remove everything and reinstall GDAL 2.2. Would love to be able to
start using the newest GDAL inside R as it seems that many things have
been improved
(https://trac.osgeo.org/gdal/query?group=status&milestone=2.3.0).
Installing GDAL from source takes >20mins so next time I would like to
be sure that I will not have to remove GDAL.

Can somebody point to a step-by-step guide to install GDAL 2.3.* and
rgdal on ubuntu (now that all packages have been updated)?

Much appreciated!

My session info:

 > library(rgdal)
Loading required package: sp
rgdal: version: 1.2-20, (SVN revision 725)
  Geospatial Data Abstraction Library extensions to R successfully loaded
  Loaded GDAL runtime: GDAL 2.2.2, released 2017/09/15
  Path to GDAL shared files: /usr/share/gdal/2.2
  GDAL binary built with GEOS: TRUE
  Loaded PROJ.4 runtime: Rel. 4.9.2, 08 September 2015, [PJ_VERSION: 492]
  Path to PROJ.4 shared files: (autodetected)
  Linking to sp version: 1.2-7
 > sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.4 LTS

Matrix products: default
BLAS: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRblas.so
LAPACK: /opt/microsoft/ropen/3.5.0/lib64/R/lib/libRlapack.so



On 19.06.2018 08:47, Roger Bivand wrote:
> On Mon, 18 Jun 2018, MacQueen, Don wrote:
>
>> Success!
>>
>> This morning I upgraded a Mac to OS 10.13.5 (the so-called High
>> Sierra version), then
>>
>> - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
>> - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3, from the
>>   CRAN binaries that are now available
>> - Ran my personal test suite, which exercises the kinds of tasks I
>>   perform with those packages
>>
>> All tests succeeded.
>
> Thanks for reporting - especially on your own test suite. We do what
> we can to cover typical use cases, but independent testing in
> production settings is reassuring for everybody. We're expecting more
> PROJ-based changes later this year and next year, so it is great to
> have external test sets to be able to check where any changes in
> output are coming from.
>
> This is an encouragement to other users whose production depends on R
> packages using GDAL, PROJ and/or GEOS to follow this example and keep
> a script handy to test your use cases, and a history of output files
> with which to compare (diff). We don't worry about changes in the EPSG
> versions, but by next year they may be properly anchored too (changes
> in PROJ may include reference system definitions with timestamps).
>
>>
>> I forgot to control the order of installation, so I don't know if I
>> installed sp first, as advised. But I expect that with the binary
>> versions it doesn't matter.
>
> Right, the binary builds use the sp version on the build platform.
>
> Best wishes,
>
> Roger
>
>>
>> (I don't think it matters for the above, but I also installed the
>> clang and gfortran version provided on CRAN's Mac "tools" page, and
>> successfully compiled some source packages that require fortran, and
>> others that require C).
>>
>> Thank again for all your work
>> -Don
>>
>> --
>> Don MacQueen
>> Lawrence Livermore National Laboratory
>> 7000 East Ave., L-627
>> Livermore, CA 94550
>> 925-423-1062
>> Lab cell 925-724-7509
>>
>>
>>
>> On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand"
>> <[hidden email] on behalf of [hidden email]>
>> wrote:
>>
>>    There are new releases of sp, rgdal and rgeos on CRAN. Please
>> install sp
>>    first, then the other two, which link to the installed sp. They all
>>    address so-called rchk issues, which have not so far been a
>> problem, but
>>    might have become more fragile as R's internal memory management
>> is made
>>    even more efficient. This involves compiled code using memory
>> allocated by
>>    R to be freed by R's garbage collector, which has to know if an
>> object is
>>    still being used. Tomas Kalibera, the author of rchk, helped
>> resolve and
>>    explain the issues encountered - what was good coding practice
>> fifteen
>>    years ago isn't always still good practice.
>>
>>    In addition, the earliest versions of GDAL and PROJ with which
>> rgdal will
>>    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The
>> current
>>    released versions of PROJ and GDAL are to be prefered, as bugs
>> have been
>>    fixed and new features and drivers introduced. A check has been put
>>    in place to trap attempts to install rgdal without a C++11-capable
>>    compiler when the GDAL version is >=2.3.0 - which requires C++11.
>> rgeos is
>>    ready for the forthcoming version of GEOS.
>>
>>    The CRAN team has also been very supportive of our efforts to bring
>>    compiled code in these packages into rchk compliance.
>>
>>    Please get in touch if you see any loose ends in these releases.
>>
>>    Roger
>>
>>    --
>>    Roger Bivand
>>    Department of Economics, Norwegian School of Economics,
>>    Helleveien 30, N-5045 Bergen, Norway.
>>    voice: +47 55 95 93 55; e-mail: [hidden email]
>>    http://orcid.org/0000-0003-2392-6140
>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>
>>    _______________________________________________
>>    R-sig-Geo mailing list
>>    [hidden email]
>>    https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
>>
>
>
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: CRAN releases of sp, rgdal and rgeos

Tue, 06/19/2018 - 01:47
On Mon, 18 Jun 2018, MacQueen, Don wrote:

> Success!
>
> This morning I upgraded a Mac to OS 10.13.5 (the so-called High Sierra
> version), then
>
> - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
> - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3, from the
>   CRAN binaries that are now available
> - Ran my personal test suite, which exercises the kinds of tasks I
>   perform with those packages
>
> All tests succeeded. Thanks for reporting - especially on your own test suite. We do what we
can to cover typical use cases, but independent testing in production
settings is reassuring for everybody. We're expecting more PROJ-based
changes later this year and next year, so it is great to have external
test sets to be able to check where any changes in output are coming from.

This is an encouragement to other users whose production depends on R
packages using GDAL, PROJ and/or GEOS to follow this example and keep a
script handy to test your use cases, and a history of output files with
which to compare (diff). We don't worry about changes in the EPSG
versions, but by next year they may be properly anchored too (changes in
PROJ may include reference system definitions with timestamps).

>
> I forgot to control the order of installation, so I don't know if I
> installed sp first, as advised. But I expect that with the binary
> versions it doesn't matter.

Right, the binary builds use the sp version on the build platform.

Best wishes,

Roger

>
> (I don't think it matters for the above, but I also installed the clang
> and gfortran version provided on CRAN's Mac "tools" page, and
> successfully compiled some source packages that require fortran, and
> others that require C).
>
> Thank again for all your work
> -Don
>
> --
> Don MacQueen
> Lawrence Livermore National Laboratory
> 7000 East Ave., L-627
> Livermore, CA 94550
> 925-423-1062
> Lab cell 925-724-7509
>
>
>
> On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand" <[hidden email] on behalf of [hidden email]> wrote:
>
>    There are new releases of sp, rgdal and rgeos on CRAN. Please install sp
>    first, then the other two, which link to the installed sp. They all
>    address so-called rchk issues, which have not so far been a problem, but
>    might have become more fragile as R's internal memory management is made
>    even more efficient. This involves compiled code using memory allocated by
>    R to be freed by R's garbage collector, which has to know if an object is
>    still being used. Tomas Kalibera, the author of rchk, helped resolve and
>    explain the issues encountered - what was good coding practice fifteen
>    years ago isn't always still good practice.
>
>    In addition, the earliest versions of GDAL and PROJ with which rgdal will
>    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The current
>    released versions of PROJ and GDAL are to be prefered, as bugs have been
>    fixed and new features and drivers introduced. A check has been put
>    in place to trap attempts to install rgdal without a C++11-capable
>    compiler when the GDAL version is >=2.3.0 - which requires C++11. rgeos is
>    ready for the forthcoming version of GEOS.
>
>    The CRAN team has also been very supportive of our efforts to bring
>    compiled code in these packages into rchk compliance.
>
>    Please get in touch if you see any loose ends in these releases.
>
>    Roger
>
>    --
>    Roger Bivand
>    Department of Economics, Norwegian School of Economics,
>    Helleveien 30, N-5045 Bergen, Norway.
>    voice: +47 55 95 93 55; e-mail: [hidden email]
>    http://orcid.org/0000-0003-2392-6140
>    https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>
>    _______________________________________________
>    R-sig-Geo mailing list
>    [hidden email]
>    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: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Pages