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: 5 min 10 sec ago

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

Re: CRAN releases of sp, rgdal and rgeos

Mon, 06/18/2018 - 14:39
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.

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.

(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

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 08:49
Yes, thanks for the explanations.


Have a nice week! :)

Em seg, 18 de jun de 2018 às 10:29, Ben Tupper <[hidden email]>
escreveu:

> Hi,
>
> I will blissfully proceed as I have in the past.   Thanks to each of you
> for the clear explanations.
>
> Cheers,
> Ben
>
> > On Jun 18, 2018, at 6:26 AM, Michael Sumner <[hidden email]> wrote:
> >
> > Agree with Edzer this application of eqc is anomalous and after it
> confused
> > us initially we now ignore it and apply the unproblematic proj=longlat
> > interpretation to these products (after checking).
> >
> > I might explore the L3 products to find out why this occurred, but the
> > ocean colour forum is the usual place to find discussion.
> >
> > Cheers, Mike
> >
> > On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]
> >
> > wrote:
> >
> >> Plate carree is essentially a linear mapping of long and lat to x and y,
> >> without changing aspect ratio (scale factor 1 at equator).
> >>
> >> projecting long/lat towards plate caree using the proj4 string you
> >> mention will however change the units from degrees to m. So while the
> >> plots of of data in linear long/lat (with aspect ration 1) looks
> >> identical to the one obtained in plate caree (with aspect ratio 1), the
> >> numerical values along their axes are very different.
> >>
> >> Many netcdf files carry a grid (raster) with the x and y coordinates of
> >> grid cells (centers?) in another coordinate system, but the ones you
> >> mention below don't, as far as I can tell. I think what they mean by
> >> mentioning plate carree is just saying that this is a regular long/lat
> >> degree grid; rather unlucky wording IMO.
> >>
> >> On 06/15/2018 08:14 PM, Ben Tupper wrote:
> >>> Hi,
> >>>
> >>> That's an interesting approach.
> >>>
> >>> On the other hand, sometimes I get bitten (well, muddled really) when I
> >> use raster to determine the crs of a ncdf resource.  It all sort of
> depends.
> >>>
> >>> Below is an example for Aqua MODIS imagery from OBPG (
> >>
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> >> <
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> >).
> >> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
> >> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
> >> served up as 'Plate Carrée' which I think has a crs ...
> >>>
> >>> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
> >> +datum=WGS84 +units=m +no_defs '
> >>>
> >>> ... as described here http://spatialreference.org/ref/epsg/32662/ <
> >> http://spatialreference.org/ref/epsg/32662/>
> >>>
> >>> You can see below that raster comes up with...
> >>>
> >>> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
> >>>
> >>> ... which is http://spatialreference.org/ref/epsg/4326/ <
> >> http://spatialreference.org/ref/epsg/4326/>
> >>>
> >>> Explicitly setting the crs while reading doesn't help.  I have never
> >> resolved if it is an OBPG documentation bug, my confusion about
> >> projections, or some other mystery.  So, my usual practice is to assume
> >> that raster makes the right call.
> >>>
> >>> #### start
> >>>
> >>> library(raster)
> >>> URI = '
> >>
> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
> >> '
> >>>
> >>> # ~3.8MB
> >>> ok = download.file(URI, basename(URI))
> >>>
> >>> R = raster::raster(basename(URI), varname = 'sst')
> >>> R
> >>> # class       : RasterLayer
> >>> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> >>> # resolution  : 0.08333334, 0.08333334  (x, y)
> >>> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> >>> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> >>> # data source : /Users/Shared/code/R/others/record/spnc/
> >> A2017175.L3m_DAY_SST_sst_9km.nc
> >>> # names       : Sea.Surface.Temperature
> >>> # zvar        : sst
> >>>
> >>> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
> >> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
> >> +units=m +no_defs')
> >>> # Warning message:
> >>> # In .getProj(prj, crs) :
> >>> #  argument "crs" ignored because the file provides a crs
> >>>
> >>> #### end
> >>>
> >>>
> >>> Cheers,
> >>> Ben
> >>>
> >>>
> >>>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]>
> wrote:
> >>>>
> >>>> Try raster::projection(raster::raster(a)) first, then delve if
> necessary
> >>>> into the ncdump summary with print(raster::raster(a)))
> >>>>
> >>>> But, raster(a) may be enough here? To get that stuff more directly
> from
> >> the
> >>>> NetCDF API you have to use the inq and att functions of ncdf4 or
> RNetCDF
> >>>> and that's no fun.
> >>>>
> >>>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different
> but
> >>>> equivalent read path.
> >>>>
> >>>> Cheers, Mike
> >>>>
> >>>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
> >> wrote:
> >>>>
> >>>>> Greetings,
> >>>>>
> >>>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
> >>>>> model). The NetCDF can have one of these three projections:
> >>>>>
> >>>>> Polar stereographic
> >>>>> Lambert conformal
> >>>>> Mercator projection
> >>>>>
> >>>>> (See figure
> >>>>>
> >>>>>
> >>
> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
> >>>>> )
> >>>>>
> >>>>> What is the  Coordinate Reference System for each case?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Here an example with ncdf4 and raster:
> >>>>>
> >>>>> library(ncdf4)
> >>>>> library(raster)
> >>>>> a <- tempfile()
> >>>>> download.file(url = "
> >>>>>
> >>
> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
> >>>>> ",
> >>>>>             destfile = a) #78 Mb
> >>>>> wrf <- nc_open(a)
> >>>>> paste("The file has",wrf$nvars,"variables")
> >>>>> paste("The file has",names(wrf$var))
> >>>>> lat <- ncvar_get( wrf, "XLAT" )
> >>>>> lon <- ncvar_get( wrf, "XLONG" )
> >>>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
> >>>>> dim(t2) #73 60 13
> >>>>> #image
> >>>>> image(t2[, , 12])
> >>>>> # raster
> >>>>> rt2 <- raster(t(t2[1:dim(t2)[1],
> >>>>>                  dim(t2)[2]:1,
> >>>>>                  12]),
> >>>>>             xmn = min(lon),
> >>>>>             xmx = max(lon),
> >>>>>             ymn = min(lat),
> >>>>>             ymx = max(lat),
> >>>>> *              crs="+init=epsg:4326") # ???*
> >>>>> spplot(rt2)
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ​Sergio Ibarra Espinosa
> >>>>> Post Doc
> >>>>> PhD in Atmospheric Sciences
> >>>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
> >>>>> Universidade de São Paulo
> >>>>> Rua do Matão, 1226
> >>>>> São Paulo-SP - Brasil -
> >>>>> 05508-090
> >>>>> +55-11-97425-3791 <(11)%2097425-3791>
> >>>>> Skype: sergio_ibarra1
> >>>>>
> >>>>>       [[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
> >>>>
> >>>
> >>> Ben Tupper
> >>> Bigelow Laboratory for Ocean Scien
> <https://maps.google.com/?q=for+Ocean+Scien&entry=gmail&source=g>ces
> >>> 60 Bigelow Drive, P.O. Box 380
> >>> East Boothbay, Maine 04544
> >>> http://www.bigelow.org
> >>>
> >>> Ecological Forecasting: https://eco.bigelow.org/
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      [[alternative HTML version deleted]]
> >>>
> >>> _______________________________________________
> >>> R-sig-Geo mailing list
> >>> [hidden email]
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>>
> >>
> >> --
> >> Edzer Pebesma
> >> Institute for Geoinformatics
> >> Heisenbergstrasse 2, 48151 Muenster, Germany
> >> Phone: +49 251 8333081 <+49%20251%208333081>
> >>
> >> _______________________________________________
> >> 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
> >
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
​Sergio Ibarra Espinosa
Post Doc
PhD in Atmospheric Sciences
Instituto de Astronomia, Geofísica e Ciências Atmosféricas
Universidade de São Paulo
Rua do Matão, 1226
São Paulo-SP - Brasil -
05508-090
+55-11-97425-3791
Skype: sergio_ibarra1

        [[alternative HTML version deleted]]

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

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 08:22
Hi,

I will blissfully proceed as I have in the past.   Thanks to each of you for the clear explanations.  

Cheers,
Ben

> On Jun 18, 2018, at 6:26 AM, Michael Sumner <[hidden email]> wrote:
>
> Agree with Edzer this application of eqc is anomalous and after it confused
> us initially we now ignore it and apply the unproblematic proj=longlat
> interpretation to these products (after checking).
>
> I might explore the L3 products to find out why this occurred, but the
> ocean colour forum is the usual place to find discussion.
>
> Cheers, Mike
>
> On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]>
> wrote:
>
>> Plate carree is essentially a linear mapping of long and lat to x and y,
>> without changing aspect ratio (scale factor 1 at equator).
>>
>> projecting long/lat towards plate caree using the proj4 string you
>> mention will however change the units from degrees to m. So while the
>> plots of of data in linear long/lat (with aspect ration 1) looks
>> identical to the one obtained in plate caree (with aspect ratio 1), the
>> numerical values along their axes are very different.
>>
>> Many netcdf files carry a grid (raster) with the x and y coordinates of
>> grid cells (centers?) in another coordinate system, but the ones you
>> mention below don't, as far as I can tell. I think what they mean by
>> mentioning plate carree is just saying that this is a regular long/lat
>> degree grid; rather unlucky wording IMO.
>>
>> On 06/15/2018 08:14 PM, Ben Tupper wrote:
>>> Hi,
>>>
>>> That's an interesting approach.
>>>
>>> On the other hand, sometimes I get bitten (well, muddled really) when I
>> use raster to determine the crs of a ncdf resource.  It all sort of depends.
>>>
>>> Below is an example for Aqua MODIS imagery from OBPG (
>> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
>> <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).
>> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
>> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
>> served up as 'Plate Carrée' which I think has a crs ...
>>>
>>> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
>> +datum=WGS84 +units=m +no_defs '
>>>
>>> ... as described here http://spatialreference.org/ref/epsg/32662/ <
>> http://spatialreference.org/ref/epsg/32662/>
>>>
>>> You can see below that raster comes up with...
>>>
>>> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
>>>
>>> ... which is http://spatialreference.org/ref/epsg/4326/ <
>> http://spatialreference.org/ref/epsg/4326/>
>>>
>>> Explicitly setting the crs while reading doesn't help.  I have never
>> resolved if it is an OBPG documentation bug, my confusion about
>> projections, or some other mystery.  So, my usual practice is to assume
>> that raster makes the right call.
>>>
>>> #### start
>>>
>>> library(raster)
>>> URI = '
>> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
>> '
>>>
>>> # ~3.8MB
>>> ok = download.file(URI, basename(URI))
>>>
>>> R = raster::raster(basename(URI), varname = 'sst')
>>> R
>>> # class       : RasterLayer
>>> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
>>> # resolution  : 0.08333334, 0.08333334  (x, y)
>>> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
>>> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>>> # data source : /Users/Shared/code/R/others/record/spnc/
>> A2017175.L3m_DAY_SST_sst_9km.nc
>>> # names       : Sea.Surface.Temperature
>>> # zvar        : sst
>>>
>>> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
>> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
>> +units=m +no_defs')
>>> # Warning message:
>>> # In .getProj(prj, crs) :
>>> #  argument "crs" ignored because the file provides a crs
>>>
>>> #### end
>>>
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
>>>>
>>>> Try raster::projection(raster::raster(a)) first, then delve if necessary
>>>> into the ncdump summary with print(raster::raster(a)))
>>>>
>>>> But, raster(a) may be enough here? To get that stuff more directly from
>> the
>>>> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
>>>> and that's no fun.
>>>>
>>>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
>>>> equivalent read path.
>>>>
>>>> Cheers, Mike
>>>>
>>>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
>> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
>>>>> model). The NetCDF can have one of these three projections:
>>>>>
>>>>> Polar stereographic
>>>>> Lambert conformal
>>>>> Mercator projection
>>>>>
>>>>> (See figure
>>>>>
>>>>>
>> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
>>>>> )
>>>>>
>>>>> What is the  Coordinate Reference System for each case?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Here an example with ncdf4 and raster:
>>>>>
>>>>> library(ncdf4)
>>>>> library(raster)
>>>>> a <- tempfile()
>>>>> download.file(url = "
>>>>>
>> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
>>>>> ",
>>>>>             destfile = a) #78 Mb
>>>>> wrf <- nc_open(a)
>>>>> paste("The file has",wrf$nvars,"variables")
>>>>> paste("The file has",names(wrf$var))
>>>>> lat <- ncvar_get( wrf, "XLAT" )
>>>>> lon <- ncvar_get( wrf, "XLONG" )
>>>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
>>>>> dim(t2) #73 60 13
>>>>> #image
>>>>> image(t2[, , 12])
>>>>> # raster
>>>>> rt2 <- raster(t(t2[1:dim(t2)[1],
>>>>>                  dim(t2)[2]:1,
>>>>>                  12]),
>>>>>             xmn = min(lon),
>>>>>             xmx = max(lon),
>>>>>             ymn = min(lat),
>>>>>             ymx = max(lat),
>>>>> *              crs="+init=epsg:4326") # ???*
>>>>> spplot(rt2)
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ​Sergio Ibarra Espinosa
>>>>> Post Doc
>>>>> PhD in Atmospheric Sciences
>>>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
>>>>> Universidade de São Paulo
>>>>> Rua do Matão, 1226
>>>>> São Paulo-SP - Brasil -
>>>>> 05508-090
>>>>> +55-11-97425-3791
>>>>> Skype: sergio_ibarra1
>>>>>
>>>>>       [[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
>>>>
>>>
>>> Ben Tupper
>>> Bigelow Laboratory for Ocean Sciences
>>> 60 Bigelow Drive, P.O. Box 380
>>> East Boothbay, Maine 04544
>>> http://www.bigelow.org
>>>
>>> Ecological Forecasting: https://eco.bigelow.org/
>>>
>>>
>>>
>>>
>>>
>>>
>>>      [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>> --
>> Edzer Pebesma
>> Institute for Geoinformatics
>> Heisenbergstrasse 2, 48151 Muenster, Germany
>> Phone: +49 251 8333081
>>
>> _______________________________________________
>> 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
>
Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive, P.O. Box 380
East Boothbay, Maine 04544
http://www.bigelow.org

Ecological Forecasting: https://eco.bigelow.org/






        [[alternative HTML version deleted]]

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

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 05:26
Agree with Edzer this application of eqc is anomalous and after it confused
us initially we now ignore it and apply the unproblematic proj=longlat
interpretation to these products (after checking).

I might explore the L3 products to find out why this occurred, but the
ocean colour forum is the usual place to find discussion.

Cheers, Mike

On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]>
wrote:

> Plate carree is essentially a linear mapping of long and lat to x and y,
> without changing aspect ratio (scale factor 1 at equator).
>
> projecting long/lat towards plate caree using the proj4 string you
> mention will however change the units from degrees to m. So while the
> plots of of data in linear long/lat (with aspect ration 1) looks
> identical to the one obtained in plate caree (with aspect ratio 1), the
> numerical values along their axes are very different.
>
> Many netcdf files carry a grid (raster) with the x and y coordinates of
> grid cells (centers?) in another coordinate system, but the ones you
> mention below don't, as far as I can tell. I think what they mean by
> mentioning plate carree is just saying that this is a regular long/lat
> degree grid; rather unlucky wording IMO.
>
> On 06/15/2018 08:14 PM, Ben Tupper wrote:
> > Hi,
> >
> > That's an interesting approach.
> >
> > On the other hand, sometimes I get bitten (well, muddled really) when I
> use raster to determine the crs of a ncdf resource.  It all sort of depends.
> >
> > Below is an example for Aqua MODIS imagery from OBPG (
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).
> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
> served up as 'Plate Carrée' which I think has a crs ...
> >
> > '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
> +datum=WGS84 +units=m +no_defs '
> >
> > ... as described here http://spatialreference.org/ref/epsg/32662/ <
> http://spatialreference.org/ref/epsg/32662/>
> >
> > You can see below that raster comes up with...
> >
> > '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
> >
> > ... which is http://spatialreference.org/ref/epsg/4326/ <
> http://spatialreference.org/ref/epsg/4326/>
> >
> > Explicitly setting the crs while reading doesn't help.  I have never
> resolved if it is an OBPG documentation bug, my confusion about
> projections, or some other mystery.  So, my usual practice is to assume
> that raster makes the right call.
> >
> > #### start
> >
> > library(raster)
> > URI = '
> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
> '
> >
> > # ~3.8MB
> > ok = download.file(URI, basename(URI))
> >
> > R = raster::raster(basename(URI), varname = 'sst')
> > R
> > # class       : RasterLayer
> > # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> > # resolution  : 0.08333334, 0.08333334  (x, y)
> > # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : /Users/Shared/code/R/others/record/spnc/
> A2017175.L3m_DAY_SST_sst_9km.nc
> > # names       : Sea.Surface.Temperature
> > # zvar        : sst
> >
> > S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
> +units=m +no_defs')
> > # Warning message:
> > # In .getProj(prj, crs) :
> > #  argument "crs" ignored because the file provides a crs
> >
> > #### end
> >
> >
> > Cheers,
> > Ben
> >
> >
> >> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
> >>
> >> Try raster::projection(raster::raster(a)) first, then delve if necessary
> >> into the ncdump summary with print(raster::raster(a)))
> >>
> >> But, raster(a) may be enough here? To get that stuff more directly from
> the
> >> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
> >> and that's no fun.
> >>
> >> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
> >> equivalent read path.
> >>
> >> Cheers, Mike
> >>
> >> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
> wrote:
> >>
> >>> Greetings,
> >>>
> >>> I'm want to read NetCDF spatial data from a meteorological model (WRF
> >>> model). The NetCDF can have one of these three projections:
> >>>
> >>> Polar stereographic
> >>> Lambert conformal
> >>> Mercator projection
> >>>
> >>> (See figure
> >>>
> >>>
> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
> >>> )
> >>>
> >>> What is the  Coordinate Reference System for each case?
> >>>
> >>> Thanks!
> >>>
> >>> Here an example with ncdf4 and raster:
> >>>
> >>> library(ncdf4)
> >>> library(raster)
> >>> a <- tempfile()
> >>> download.file(url = "
> >>>
> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
> >>> ",
> >>>              destfile = a) #78 Mb
> >>> wrf <- nc_open(a)
> >>> paste("The file has",wrf$nvars,"variables")
> >>> paste("The file has",names(wrf$var))
> >>> lat <- ncvar_get( wrf, "XLAT" )
> >>> lon <- ncvar_get( wrf, "XLONG" )
> >>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
> >>> dim(t2) #73 60 13
> >>> #image
> >>> image(t2[, , 12])
> >>> # raster
> >>> rt2 <- raster(t(t2[1:dim(t2)[1],
> >>>                   dim(t2)[2]:1,
> >>>                   12]),
> >>>              xmn = min(lon),
> >>>              xmx = max(lon),
> >>>              ymn = min(lat),
> >>>              ymx = max(lat),
> >>> *              crs="+init=epsg:4326") # ???*
> >>> spplot(rt2)
> >>>
> >>>
> >>>
> >>> --
> >>> ​Sergio Ibarra Espinosa
> >>> Post Doc
> >>> PhD in Atmospheric Sciences
> >>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
> >>> Universidade de São Paulo
> >>> Rua do Matão, 1226
> >>> São Paulo-SP - Brasil -
> >>> 05508-090
> >>> +55-11-97425-3791
> >>> Skype: sergio_ibarra1
> >>>
> >>>        [[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
> >>
> >
> > Ben Tupper
> > Bigelow Laboratory for Ocean Sciences
> > 60 Bigelow Drive, P.O. Box 380
> > East Boothbay, Maine 04544
> > http://www.bigelow.org
> >
> > Ecological Forecasting: https://eco.bigelow.org/
> >
> >
> >
> >
> >
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> --
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081
>
> _______________________________________________
> 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

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 03:59
Plate carree is essentially a linear mapping of long and lat to x and y,
without changing aspect ratio (scale factor 1 at equator).

projecting long/lat towards plate caree using the proj4 string you
mention will however change the units from degrees to m. So while the
plots of of data in linear long/lat (with aspect ration 1) looks
identical to the one obtained in plate caree (with aspect ratio 1), the
numerical values along their axes are very different.

Many netcdf files carry a grid (raster) with the x and y coordinates of
grid cells (centers?) in another coordinate system, but the ones you
mention below don't, as far as I can tell. I think what they mean by
mentioning plate carree is just saying that this is a regular long/lat
degree grid; rather unlucky wording IMO.

On 06/15/2018 08:14 PM, Ben Tupper wrote:
> Hi,
>
> That's an interesting approach.  
>
> On the other hand, sometimes I get bitten (well, muddled really) when I use raster to determine the crs of a ncdf resource.  It all sort of depends.
>
> Below is an example for Aqua MODIS imagery from OBPG (https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/ <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).  The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <https://oceancolor.gsfc.nasa.gov/products/>) state that the data is served up as 'Plate Carrée' which I think has a crs ...
>
> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs '
>
> ... as described here http://spatialreference.org/ref/epsg/32662/ <http://spatialreference.org/ref/epsg/32662/>
>
> You can see below that raster comes up with...
>
> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
>
> ... which is http://spatialreference.org/ref/epsg/4326/ <http://spatialreference.org/ref/epsg/4326/>
>
> Explicitly setting the crs while reading doesn't help.  I have never resolved if it is an OBPG documentation bug, my confusion about projections, or some other mystery.  So, my usual practice is to assume that raster makes the right call.
>
> #### start
>
> library(raster)
> URI = 'https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc'
>
> # ~3.8MB
> ok = download.file(URI, basename(URI))
>
> R = raster::raster(basename(URI), varname = 'sst')
> R
> # class       : RasterLayer
> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> # resolution  : 0.08333334, 0.08333334  (x, y)
> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> # data source : /Users/Shared/code/R/others/record/spnc/A2017175.L3m_DAY_SST_sst_9km.nc
> # names       : Sea.Surface.Temperature
> # zvar        : sst
>
> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs')
> # Warning message:
> # In .getProj(prj, crs) :
> #  argument "crs" ignored because the file provides a crs
>
> #### end
>
>
> Cheers,
> Ben
>
>
>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
>>
>> Try raster::projection(raster::raster(a)) first, then delve if necessary
>> into the ncdump summary with print(raster::raster(a)))
>>
>> But, raster(a) may be enough here? To get that stuff more directly from the
>> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
>> and that's no fun.
>>
>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
>> equivalent read path.
>>
>> Cheers, Mike
>>
>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]> wrote:
>>
>>> Greetings,
>>>
>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
>>> model). The NetCDF can have one of these three projections:
>>>
>>> Polar stereographic
>>> Lambert conformal
>>> Mercator projection
>>>
>>> (See figure
>>>
>>> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
>>> )
>>>
>>> What is the  Coordinate Reference System for each case?
>>>
>>> Thanks!
>>>
>>> Here an example with ncdf4 and raster:
>>>
>>> library(ncdf4)
>>> library(raster)
>>> a <- tempfile()
>>> download.file(url = "
>>> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
>>> ",
>>>              destfile = a) #78 Mb
>>> wrf <- nc_open(a)
>>> paste("The file has",wrf$nvars,"variables")
>>> paste("The file has",names(wrf$var))
>>> lat <- ncvar_get( wrf, "XLAT" )
>>> lon <- ncvar_get( wrf, "XLONG" )
>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
>>> dim(t2) #73 60 13
>>> #image
>>> image(t2[, , 12])
>>> # raster
>>> rt2 <- raster(t(t2[1:dim(t2)[1],
>>>                   dim(t2)[2]:1,
>>>                   12]),
>>>              xmn = min(lon),
>>>              xmx = max(lon),
>>>              ymn = min(lat),
>>>              ymx = max(lat),
>>> *              crs="+init=epsg:4326") # ???*
>>> spplot(rt2)
>>>
>>>
>>>
>>> --
>>> ​Sergio Ibarra Espinosa
>>> Post Doc
>>> PhD in Atmospheric Sciences
>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
>>> Universidade de São Paulo
>>> Rua do Matão, 1226
>>> São Paulo-SP - Brasil -
>>> 05508-090
>>> +55-11-97425-3791
>>> Skype: sergio_ibarra1
>>>
>>>        [[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
>>
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

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

Call for manuscripts "Technological and Methodological Advances in Measuring, Mapping and Monitoring Soil Carbon and Nutrients in Space and Spacetime" Special issue in Nutrient Cycling in Agroecosystems Journal

Mon, 06/18/2018 - 02:56

This is the first call for manuscripts for a special issue
"Technological and Methodological Advances in Measuring, Mapping and
Monitoring Soil Carbon and Nutrients in Space and Spacetime" Nutrient
Cycling in Agroecosystems Journal (https://link.springer.com/journal/10705).

We aim at producing a special issue listing good practice examples of
how novel technologies such as soil sensing and image recognition,
automated sensor networks, unmanned aerial vehicles (UAVs) and publicly
available remote sensing products (such as NASA's Landsat 7 & 8 and
ASTER missions, ESA's Sentinel 2 and other Copernicus land products,
JAXA's Advanced Land Observing Satellite ALOS, LiDAR, TanDEMx and
similar missions), in combination with statistical / machine learning,
data mining and high performance computing, can be used to generate most
accurate maps of soil carbon and soil nutrients in space and spacetime.

We require that all articles submitted for this issue come with
documented computational steps (code) and/or data processing tutorials
which are available publicly (github, Rpubs, Launchpad, Bitbucket or
similar) and can be used to reproduce at least 2/3rd of key results (key
tabular and graphical results). This corresponds to Level 2 or 3
standards of the Reproducible Research as defined in
http://dx.doi.org/10.1126/science.aab2374

First five (5) accepted papers for this special issue will be awarded a
waived registration fees (names to be chosen by the contact author of
the accepted paper) at the next OpenGeoHub Summer School 2019 (former
GEOSTAT Summer School, see: https://geostat-course.org/2018).

For more information refer to: http://opengeohub.org/

Special issue editors: T. (Tom) Hengl, M. (Madlene) Nussbaum and P.
(Pierre) Roudier
Editor-in-Chief: J. (Johannes) Lehmann

Important dates:

- First call: 2018, June 1st.
- Manuscript submission until 2018, December 1st.
- Manuscript evaluation until 2019, February 20th.
- Special issue publication in 2019, March.

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

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 10:51
Barry,

No, and it's not that easy. Matching GDAL and PROJ versions, source or binary, multiplies the combinations, and putting aws instances into a box is hard (was missing ldconfig of /usr/local, not rgdal). Docker is always a heavy download, and doesn't work for me on the road and my laptop.

A network of actual users  with problems is arguably as efficient, and includes those with problems in looking for solutions, which is harder for a system solution to do. I for example do not know how to configure R and GDAL versions in a container with Fedora despite doing Dirk's workshop, where we used pre-configured Debian systems.

Somehow people come out of this quite well, don't they?

Just some thoughts,

Roger

Roger Bivand
Norwegian School of Economics
Bergen, Norway



Fra: Barry Rowlingson
Sendt: søndag 17. juni, 16.13
Emne: Re: [R-sig-Geo] rgdal installation on Fedora 28
Til: Sarah Goslee
Kopi: Roger Bivand, r-sig-geo


Just a quick note to point out that you can test installations on systems without having to install such a system by using Docker. Fedora 28 images are available on Docker Hub.

You have to figure out how to install the toolchain and other components for building R etc but that helps make a reproducible installation procedure.

Is everyone doing this already?

Barry


On Sun, Jun 17, 2018 at 2:50 PM, Sarah Goslee <[hidden email]<mailto:[hidden email]>> wrote:
I can confirm that the patched R-Forge version of rgdal installs
correctly on my systems with no other change.

Thank you to Roger and Colin, and everyone else who took a look. The R
community is the BEST.

Sarah

On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand <[hidden email]<mailto:[hidden email]>> wrote:
> On Sat, 16 Jun 2018, Colin Rundel wrote:
>
>> As I mentioned in the tweet, I was able to fix this on both a Fedora 23
>> and
>> Fedora 27 machine by making the following change to configure.ac<http://configure.ac>:
>>
>> diff --git a/configure.ac<http://configure.ac> b/configure.ac<http://configure.ac>
>> index 8ff72be..ab4c772 100644
>> --- a/configure.ac<http://configure.ac>
>> +++ b/configure.ac<http://configure.ac>
>> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
>> DESCRIPTION | cut -d' ' -f2 |
>> AC_INIT(rgdal, [pkgversion], [hidden email]<mailto:[hidden email]>)
>> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
>>
>> +AC_PROG_CXX()
>> +
>> # find R home and set correct compiler + flags
>> : ${R_HOME=`R RHOME`}
>> if test -z "${R_HOME}"; then
>>
>> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
>> results in ./configure working for me. I don't have a deep enough
>> understanding of the vagaries of autoconf to know why exactly this is
>> necessary on redhat systems and why this fixes it but at least everything
>> seems to work.
>
>
> Thanks very much, committed to R-forge as revision 758.
>
> Roger
>
>
>>
>> -Colin
>>
>> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
>> [hidden email]<mailto:[hidden email]>> wrote:
>>
>>> The following lines in your config.log:
>>>
>>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can
>>> not be used when making a shared object; recompile with -fPIC
>>>
>>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
>>> platform in the makefile?
>>>
>>> Greetings, -- Thiago V. dos Santos
>>> Postdoctoral Research FellowDepartment of Climate and Space Science and
>>> EngineeringUniversity of Michigan
>>>
>>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
>>> [hidden email]<mailto:[hidden email]>> wrote:
>>>
>>>  Hi folks,
>>>
>>> I updated all of my linux computers to Fedora 28, and now can’t install
>>> rgdal.
>>>
>>> I can install sf with no problems, so it doesn't appear to be an issue
>>> with GDAL or with proj.
>>>
>>> I checked with Roger Bivand, the package maintainer, who asked me to
>>> confirm whether I could install sf, to make sure it wasn’t a
>>> dependency issue, and to post the logs online, then ask on the
>>> R-sig-geo mailing list. I’m putting the full problem here, and the
>>> abbreviated version on the mailing list.
>>>
>>> I’d appreciate any thoughts: I rely very heavily on the incredibly
>>> useful rgdal package.
>>>
>>>> sessionInfo()
>>>
>>> R version 3.5.0 (2018-04-23)
>>> Platform: x86_64-redhat-linux-gnu (64-bit)
>>> Running under: Fedora 28 (Workstation Edition)
>>>
>>> Matrix products: default
>>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
>>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
>>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats    graphics  grDevices utils    datasets  methods  base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.5.0 tools_3.5.0</code>
>>>
>>>
>>> The install message is:
>>>
>>> installing *source* package ‘rgdal’ ...
>>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>>> configure: CC: gcc -m64
>>> configure: CXX: g++ -m64
>>> configure: rgdal: 1.3-2
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 755
>>> 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... configure: error: in
>>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
>>> configure: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> ERROR: configuration failed for package ‘rgdal’
>>> * removing ‘/usr/lib64/R/library/rgdal’
>>> * restoring previous ‘/usr/lib64/R/library/rgdal’
>>>
>>>
>>> The complete information and config.log are posted online at:
>>>
>>> http://numberwright.com/2018/06/stuck-on-rgdal/
>>>
>>>
>>> Any ideas? Or any other information that would be useful?
>>>
>>> Thanks!
>>> Sarah
>>>
_______________________________________________
R-sig-Geo mailing list
[hidden email]<mailto:[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

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 10:13
Just a quick note to point out that you can test installations on systems
without having to install such a system by using Docker. Fedora 28 images
are available on Docker Hub.

You have to figure out how to install the toolchain and other components
for building R etc but that helps make a reproducible installation
procedure.

Is everyone doing this already?

Barry


On Sun, Jun 17, 2018 at 2:50 PM, Sarah Goslee <[hidden email]>
wrote:

> I can confirm that the patched R-Forge version of rgdal installs
> correctly on my systems with no other change.
>
> Thank you to Roger and Colin, and everyone else who took a look. The R
> community is the BEST.
>
> Sarah
>
> On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand <[hidden email]> wrote:
> > On Sat, 16 Jun 2018, Colin Rundel wrote:
> >
> >> As I mentioned in the tweet, I was able to fix this on both a Fedora 23
> >> and
> >> Fedora 27 machine by making the following change to configure.ac:
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 8ff72be..ab4c772 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
> >> DESCRIPTION | cut -d' ' -f2 |
> >> AC_INIT(rgdal, [pkgversion], [hidden email])
> >> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
> >>
> >> +AC_PROG_CXX()
> >> +
> >> # find R home and set correct compiler + flags
> >> : ${R_HOME=`R RHOME`}
> >> if test -z "${R_HOME}"; then
> >>
> >> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
> >> results in ./configure working for me. I don't have a deep enough
> >> understanding of the vagaries of autoconf to know why exactly this is
> >> necessary on redhat systems and why this fixes it but at least
> everything
> >> seems to work.
> >
> >
> > Thanks very much, committed to R-forge as revision 758.
> >
> > Roger
> >
> >
> >>
> >> -Colin
> >>
> >> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
> >> [hidden email]> wrote:
> >>
> >>> The following lines in your config.log:
> >>>
> >>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata'
> can
> >>> not be used when making a shared object; recompile with -fPIC
> >>>
> >>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
> >>> platform in the makefile?
> >>>
> >>> Greetings, -- Thiago V. dos Santos
> >>> Postdoctoral Research FellowDepartment of Climate and Space Science and
> >>> EngineeringUniversity of Michigan
> >>>
> >>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
> >>> [hidden email]> wrote:
> >>>
> >>>  Hi folks,
> >>>
> >>> I updated all of my linux computers to Fedora 28, and now can’t install
> >>> rgdal.
> >>>
> >>> I can install sf with no problems, so it doesn't appear to be an issue
> >>> with GDAL or with proj.
> >>>
> >>> I checked with Roger Bivand, the package maintainer, who asked me to
> >>> confirm whether I could install sf, to make sure it wasn’t a
> >>> dependency issue, and to post the logs online, then ask on the
> >>> R-sig-geo mailing list. I’m putting the full problem here, and the
> >>> abbreviated version on the mailing list.
> >>>
> >>> I’d appreciate any thoughts: I rely very heavily on the incredibly
> >>> useful rgdal package.
> >>>
> >>>> sessionInfo()
> >>>
> >>> R version 3.5.0 (2018-04-23)
> >>> Platform: x86_64-redhat-linux-gnu (64-bit)
> >>> Running under: Fedora 28 (Workstation Edition)
> >>>
> >>> Matrix products: default
> >>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
> >>>
> >>> locale:
> >>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
> >>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
> >>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
> >>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
> >>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
> >>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >>>
> >>> attached base packages:
> >>> [1] stats    graphics  grDevices utils    datasets  methods  base
> >>>
> >>> loaded via a namespace (and not attached):
> >>> [1] compiler_3.5.0 tools_3.5.0</code>
> >>>
> >>>
> >>> The install message is:
> >>>
> >>> installing *source* package ‘rgdal’ ...
> >>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> >>> configure: CC: gcc -m64
> >>> configure: CXX: g++ -m64
> >>> configure: rgdal: 1.3-2
> >>> checking for /usr/bin/svnversion... no
> >>> configure: svn revision: 755
> >>> 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... configure: error: in
> >>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
> >>> configure: error: cannot run C++ compiled programs.
> >>> If you meant to cross compile, use `--host'.
> >>> See `config.log' for more details
> >>> ERROR: configuration failed for package ‘rgdal’
> >>> * removing ‘/usr/lib64/R/library/rgdal’
> >>> * restoring previous ‘/usr/lib64/R/library/rgdal’
> >>>
> >>>
> >>> The complete information and config.log are posted online at:
> >>>
> >>> http://numberwright.com/2018/06/stuck-on-rgdal/
> >>>
> >>>
> >>> Any ideas? Or any other information that would be useful?
> >>>
> >>> Thanks!
> >>> Sarah
> >>>
>
> _______________________________________________
> 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: rgdal installation on Fedora 28

Sun, 06/17/2018 - 08:56
Sarah, thanks for checking and reporting back!

Roger

Roger Bivand
Norwegian School of Economics
Bergen, Norway



Fra: Sarah Goslee
Sendt: søndag 17. juni, 14.50
Emne: Re: [R-sig-Geo] rgdal installation on Fedora 28
Til: Roger Bivand
Kopi: Colin Rundel, [hidden email]


I can confirm that the patched R-Forge version of rgdal installs correctly on my systems with no other change. Thank you to Roger and Colin, and everyone else who took a look. The R community is the BEST. Sarah On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand wrote: > On Sat, 16 Jun 2018, Colin Rundel wrote: > >> As I mentioned in the tweet, I was able to fix this on both a Fedora 23 >> and >> Fedora 27 machine by making the following change to configure.ac: >> >> diff --git a/configure.ac b/configure.ac >> index 8ff72be..ab4c772 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version: >> DESCRIPTION | cut -d' ' -f2 | >> AC_INIT(rgdal, [pkgversion], [hidden email]) >> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp) >> >> +AC_PROG_CXX() >> + >> # find R home and set correct compiler + flags >> : ${R_HOME=`R RHOME`} >> if test -z "${R_HOME}"; then >> >> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added) >> results in ./configure working for me. I don't have a deep enough >> understanding of the vagaries of autoconf to know why exactly this is >> necessary on redhat systems and why this fixes it but at least everything >> seems to work. > > > Thanks very much, committed to R-forge as revision 758. > > Roger > > >> >> -Colin >> >> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo < >> [hidden email]> wrote: >> >>> The following lines in your config.log: >>> >>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can >>> not be used when making a shared object; recompile with -fPIC >>> >>> make me wonder: maybe there is a -fPIC compilation flag lacking for you >>> platform in the makefile? >>> >>> Greetings, -- Thiago V. dos Santos >>> Postdoctoral Research FellowDepartment of Climate and Space Science and >>> EngineeringUniversity of Michigan >>> >>> On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee < >>> [hidden email]> wrote: >>> >>> Hi folks, >>> >>> I updated all of my linux computers to Fedora 28, and now can’t install >>> rgdal. >>> >>> I can install sf with no problems, so it doesn't appear to be an issue >>> with GDAL or with proj. >>> >>> I checked with Roger Bivand, the package maintainer, who asked me to >>> confirm whether I could install sf, to make sure it wasn’t a >>> dependency issue, and to post the logs online, then ask on the >>> R-sig-geo mailing list. I’m putting the full problem here, and the >>> abbreviated version on the mailing list. >>> >>> I’d appreciate any thoughts: I rely very heavily on the incredibly >>> useful rgdal package. >>> >>>> sessionInfo() >>> >>> R version 3.5.0 (2018-04-23) >>> Platform: x86_64-redhat-linux-gnu (64-bit) >>> Running under: Fedora 28 (Workstation Edition) >>> >>> Matrix products: default >>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so >>> >>> locale: >>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >>> [9] LC_ADDRESS=C LC_TELEPHONE=C >>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >>> >>> attached base packages: >>> [1] stats graphics grDevices utils datasets methods base >>> >>> loaded via a namespace (and not attached): >>> [1] compiler_3.5.0 tools_3.5.0 >>> >>> >>> The install message is: >>> >>> installing *source* package ‘rgdal’ ... >>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked >>> configure: CC: gcc -m64 >>> configure: CXX: g++ -m64 >>> configure: rgdal: 1.3-2 >>> checking for /usr/bin/svnversion... no >>> configure: svn revision: 755 >>> 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... configure: error: in >>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal': >>> configure: error: cannot run C++ compiled programs. >>> If you meant to cross compile, use `--host'. >>> See `config.log' for more details >>> ERROR: configuration failed for package ‘rgdal’ >>> * removing ‘/usr/lib64/R/library/rgdal’ >>> * restoring previous ‘/usr/lib64/R/library/rgdal’ >>> >>> >>> The complete information and config.log are posted online at: >>> >>> http://numberwright.com/2018/06/stuck-on-rgdal/ >>> >>> >>> Any ideas? Or any other information that would be useful? >>> >>> Thanks! >>> Sarah >>>


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

Pages