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: 33 min 51 sec ago

Re: Issues installing rgeos on linux server

Tue, 06/20/2017 - 04:26
On Tue, 20 Jun 2017, Matthew Simpson wrote:

> I'm installing some spatial packages on a linux server and due to
> university constraints, cannot install anything using a package manager.
> I've managed to get rgdal installed successfully, but rgeos is causing
> problems.
>
> I've installed the geos library already, but when I attempt to install
> rgeos within R, it complains that that it cannot run C compiled programs.

Could you please say how you installed GEOS? Could you try out geos-config
with each of the settings? Do you need 3.7.0dev (I haven't tried this as a
source of difficulty as it seems implausible, but neither rgeos nor sf
need bleeding edge functionality from GEOS)? Could you try to install sf
from source (it also uses GEOS)? Is this the GEOS geos-config -m library
bug (probably not)? Unpacking rgeos, running ./configure in the package
root, I see (Fedora 25, R 3.4.0):

$ ./configure
configure: CC: gcc
configure: CXX: g++
configure: rgeos: 0.3-23
checking for /usr/bin/svnversion... yes
configure: svn revision: 547
checking for geos-config... /usr/local/bin/geos-config
checking geos-config usability... yes
configure: GEOS version: 3.6.1
checking geos version at least 3.2.0... yes
checking geos-config clibs... yes
checking for gcc... gcc
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 gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking geos_c.h usability... yes
checking geos_c.h presence... yes
checking for geos_c.h... yes
checking geos: linking with libgeos_c... yes
configure: PKG_CPPFLAGS:  -I/usr/local/include
configure: PKG_LIBS:  -L/usr/local/lib -lgeos -L/usr/local/lib -lgeos_c
configure: creating ./config.status
config.status: creating src/Makevars

but you fail about half-way down at the standard croos-compilation test.
For rgdal/configure - you said your rgdal install on the same system
succeeded, I see:

...
checking for gcc... gcc
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 gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
...

What do you see (just running ./configure in the package root)?

Roger

>
> I've also tried downloading the tarball myself and running R CMD check, and
> it gives me the same complaint.
>
> I've successfully reinstalled Rcpp from source, but that seemed to do
> nothing.
>
> Below is: 1) the console input from the attempted installation, 2) shell
> output from running R CMD check, and 3) my sessionInfo()
>
> Any help would be appreciated.
>
> Matt
>
> 1) Here is the result of attempted installation: (note: removing type =
> "source" changes nothing):
>
>> install.packages("rgeos", type = "source",
> +         configure.args =
> "--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config",
> +         repos = "https://cloud.r-project.org")
> Installing package into ‘/home/msimpson/R/x86_64-pc-linux-gnu-library/3.3’
> (as ‘lib’ is unspecified)
> trying URL 'https://cloud.r-project.org/src/contrib/rgeos_0.3-23.tar.gz'
> Content type 'application/x-gzip' length 257486 bytes (251 KB)
> ==================================================
> downloaded 251 KB
>
> * installing *source* package ‘rgeos’ ...
> ** package ‘rgeos’ successfully unpacked and MD5 sums checked
> configure: CC: /usr/bin/gcc -std=gnu99
> configure: CXX: /usr/bin/g++
> configure: rgeos: 0.3-23
> checking for /usr/bin/svnversion... no
> configure: svn revision: 546
> configure: geos-config set to /group/stsn/shared_libs/geos/bin/geos-config
> checking geos-config exists... yes
> checking geos-config executable... yes
> checking geos-config usability... yes
> configure: GEOS version: 3.7.0dev
> checking geos version at least 3.2.0... yes
> checking geos-config clibs... yes
> checking for gcc... /usr/bin/gcc -std=gnu99
> 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/RtmppP5J2b/R.INSTALL236bb22fea27c/rgeos':
> 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 ‘rgeos’
> * removing ‘/home/msimpson/R/x86_64-pc-linux-gnu-library/3.3/rgeos’
>
> The downloaded source packages are in
>        ‘/tmp/RtmpwkU04N/downloaded_packages’
> Warning message:
> In install.packages("rgeos", type = "source", configure.args =
> "--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config",  :
>  installation of package ‘rgeos’ had non-zero exit status
>
> 2) Here's the result from running R CMD check:
>
> R CMD check
> --install-args='--configure-args=--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config'
> rgeos_0.3-23.tar.gz
> * using log directory ‘/group/stsn/src/test/rgeos.Rcheck’
> * using R version 3.3.1 (2016-06-21)
> * using platform: x86_64-pc-linux-gnu (64-bit)
> * using session charset: UTF-8
> * checking for file ‘rgeos/DESCRIPTION’ ... OK
> * this is package ‘rgeos’ version ‘0.3-23’
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking for sufficient/correct file permissions ... OK
> * checking whether package ‘rgeos’ can be installed ... ERROR
> Installation failed.
> See ‘/group/stsn/src/test/rgeos.Rcheck/00install.out’ for details.
> * DONE
>
> Status: 1 ERROR
> See
>  ‘/group/stsn/src/test/rgeos.Rcheck/00check.log’
> for details.
>
> cat /group/stsn/src/test/rgeos.Rcheck/00install.out
> * installing *source* package ‘rgeos’ ...
> ** package ‘rgeos’ successfully unpacked and MD5 sums checked
> configure: CC: /usr/bin/gcc -std=gnu99
> configure: CXX: /usr/bin/g++
> configure: rgeos: 0.3-23
> checking for /usr/bin/svnversion... no
> configure: svn revision: 546
> configure: geos-config set to /group/stsn/shared_libs/geos/bin/geos-config
> checking geos-config exists... yes
> checking geos-config executable... yes
> checking geos-config usability... yes
> configure: GEOS version: 3.7.0dev
> checking geos version at least 3.2.0... yes
> checking geos-config clibs... yes
> checking for gcc... /usr/bin/gcc -std=gnu99
> 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
> `/group/stsn/src/test/rgeos.Rcheck/00_pkg_src/rgeos':
> 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 ‘rgeos’
> * removing ‘/group/stsn/src/test/rgeos.Rcheck/rgeos’
>
> 3) And here's my session info:
>
> sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: CentOS Linux 7 (Core)
>
> 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
>
> [[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]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
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

Issues installing rgeos on linux server

Mon, 06/19/2017 - 17:26
I'm installing some spatial packages on a linux server and due to
university constraints, cannot install anything using a package manager.
I've managed to get rgdal installed successfully, but rgeos is causing
problems.

I've installed the geos library already, but when I attempt to install
rgeos within R, it complains that that it cannot run C compiled programs.

I've also tried downloading the tarball myself and running R CMD check, and
it gives me the same complaint.

I've successfully reinstalled Rcpp from source, but that seemed to do
nothing.

Below is: 1) the console input from the attempted installation, 2) shell
output from running R CMD check, and 3) my sessionInfo()

Any help would be appreciated.

Matt

1) Here is the result of attempted installation: (note: removing type =
"source" changes nothing):

> install.packages("rgeos", type = "source",
+         configure.args =
"--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config",
+         repos = "https://cloud.r-project.org")
Installing package into ‘/home/msimpson/R/x86_64-pc-linux-gnu-library/3.3’
(as ‘lib’ is unspecified)
trying URL 'https://cloud.r-project.org/src/contrib/rgeos_0.3-23.tar.gz'
Content type 'application/x-gzip' length 257486 bytes (251 KB)
==================================================
downloaded 251 KB

* installing *source* package ‘rgeos’ ...
** package ‘rgeos’ successfully unpacked and MD5 sums checked
configure: CC: /usr/bin/gcc -std=gnu99
configure: CXX: /usr/bin/g++
configure: rgeos: 0.3-23
checking for /usr/bin/svnversion... no
configure: svn revision: 546
configure: geos-config set to /group/stsn/shared_libs/geos/bin/geos-config
checking geos-config exists... yes
checking geos-config executable... yes
checking geos-config usability... yes
configure: GEOS version: 3.7.0dev
checking geos version at least 3.2.0... yes
checking geos-config clibs... yes
checking for gcc... /usr/bin/gcc -std=gnu99
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/RtmppP5J2b/R.INSTALL236bb22fea27c/rgeos':
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 ‘rgeos’
* removing ‘/home/msimpson/R/x86_64-pc-linux-gnu-library/3.3/rgeos’

The downloaded source packages are in
        ‘/tmp/RtmpwkU04N/downloaded_packages’
Warning message:
In install.packages("rgeos", type = "source", configure.args =
"--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config",  :
  installation of package ‘rgeos’ had non-zero exit status

2) Here's the result from running R CMD check:

R CMD check
--install-args='--configure-args=--with-geos-config=/group/stsn/shared_libs/geos/bin/geos-config'
rgeos_0.3-23.tar.gz
* using log directory ‘/group/stsn/src/test/rgeos.Rcheck’
* using R version 3.3.1 (2016-06-21)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘rgeos/DESCRIPTION’ ... OK
* this is package ‘rgeos’ version ‘0.3-23’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘rgeos’ can be installed ... ERROR
Installation failed.
See ‘/group/stsn/src/test/rgeos.Rcheck/00install.out’ for details.
* DONE

Status: 1 ERROR
See
  ‘/group/stsn/src/test/rgeos.Rcheck/00check.log’
for details.

cat /group/stsn/src/test/rgeos.Rcheck/00install.out
* installing *source* package ‘rgeos’ ...
** package ‘rgeos’ successfully unpacked and MD5 sums checked
configure: CC: /usr/bin/gcc -std=gnu99
configure: CXX: /usr/bin/g++
configure: rgeos: 0.3-23
checking for /usr/bin/svnversion... no
configure: svn revision: 546
configure: geos-config set to /group/stsn/shared_libs/geos/bin/geos-config
checking geos-config exists... yes
checking geos-config executable... yes
checking geos-config usability... yes
configure: GEOS version: 3.7.0dev
checking geos version at least 3.2.0... yes
checking geos-config clibs... yes
checking for gcc... /usr/bin/gcc -std=gnu99
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
`/group/stsn/src/test/rgeos.Rcheck/00_pkg_src/rgeos':
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 ‘rgeos’
* removing ‘/group/stsn/src/test/rgeos.Rcheck/rgeos’

3) And here's my session info:

 sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

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

        [[alternative HTML version deleted]]

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

Re: Problem with Proj when loading 'rgdal' on Super Computer Facility

Mon, 06/19/2017 - 13:16
On Mon, 19 Jun 2017, Shaun Walbridge wrote:

> Try passing the configure arguments to the command directly to rproj:
>
> install.packages('rgdal', configure.args =
> '--with-proj-include=/correct/proj4/include
> --with-proj-lib=/correct/proj4/lib
> --with-proj-share=/correct/proj4/share')

Thanks, Shaun! My reply when approached off-list initially, was:

"Did you consider reading the help file of install.packages? Did you
consider unpacking the source tarball of rgdal and running ./configure
--help and reading the README file, also at:

https://r-forge.r-project.org/scm/viewvc.php/pkg/inst/README?view=markup&roo
t=rgdal

or

library(rgdal)
file.show(system.file("README", package="rgdal"))

which details configure arguments, which tell the install system where to
find external dependencies.

You also typically need each core to have access to the same external
dependencies, so you may wish to build GDAL, etc. static, so that the
rgdal.so in the package that you build from source is self-contained, that
is your choice."

Installing on clusters can be a problem, so choosing the static route is
actually more predictable, but is quite a lot of work the first time
round. The build scripts for the Windows sf and rgdal binary package
external dependencies at for example:

https://github.com/rwinlib/gdal2/blob/master/build64.sh

give a flavour - you will probably only need a subset of drivers. If you
build such a static binary package, it will protect you from missing
dependencies on the nodes, at the cost of few drivers and a big shared
object. If the nodes are the homogeneous, this route should be robust.
Does anyone have recent experience of a static install under Linux (build
GDAL and its dependencies, and PROJ4, static only)?

Roger


>
> On 6/19/17, 10:33 AM, "R-sig-Geo on behalf of Ryan Runquist" <[hidden email] on behalf of [hidden email]> wrote:
>
>    Hello,
>
>    I am working on manipulating some spatial data and performing SDMs on
>    invasive species. I have been using R and the package 'rgdal' to do some of
>    these analyses.
>
>    On my own computer, Mac OSX 10.12.2 running R 3.3.3, I have had not
>    problems installing 'rgdal', loading the library, and using the functions.
>
>    However, we are starting to work on the UMN MSI facility and we are having
>    problems installing 'rgdal' on their Linux supercomputing cluster.
>
>    In order to install this package, we have to load the GDAL library and the
>    PROJ4 library in Linux. We have not had any problems loading their GDAL
>    module and accessing the libraries. They work fine for 'rgeos'. However, we
>    are having problems with the PROJ module.
>
>    When we run 'install.packages('rgdal')', the installation process begins,
>    but it stalls when it checks for "'pj_init_plus' in -lproj", and then
>    fails.
>
>    We have been working with someone at MSI to remedy this problem. They are
>    able to see that the file does in fact exist and don't know why 'rgdal' is
>    having problems locating it.
>
>    So far, we have tried different versions of PROJ (Proj 4.4.9, Proj 4.9.2,
>    Proj 4.9.3_gcc4.8.2 - meaning it was compiled with gcc 4.8.2) and they have
>    complied PROJ with GCC 4.8.2 instead of their default complier. They also
>    tried to compile it with  GCC 6.3, but that failed with a complier error.
>
>    I have copied the full error message below.
>
>    Sincerely,
>
>    Ryan
>
>
>
>    > install.packages("rgdal")
>    Installing package into ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
>    linux-gnu-library/3.3’
>    (as ‘lib’ is unspecified)
>    --- Please select a CRAN mirror for use in this session ---
>    trying URL 'https://urldefense.proofpoint.com/v2/url?u=https-3A__mirror.las.iastate.edu_CRAN_src_contrib_rgdal-5F1&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SJ8UGKdbyg0VNXfUCOOVJNKZJSQbEZ1KRCyHR_oEtC8&s=sqbCt8BPZes79H33y7aSpNnE5tALDJOhMfpOybZ4e7c&e= .
>    2-7.tar.gz'
>    Content type 'application/x-gzip' length 1653897 bytes (1.6 MB)
>    ==================================================
>    downloaded 1.6 MB
>
>    * installing *source* package ‘rgdal’ ...
>    ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>    configure: CC: /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
>    configure: CXX: /panfs/roc/msisoft/gcc/6.1.0/bin/g++
>    configure: rgdal: 1.2-7
>    checking for /usr/bin/svnversion... yes
>    configure: svn revision: 660
>    checking for gdal-config... /panfs/roc/msisoft/gdal/2.0.1/bin/gdal-config
>    checking gdal-config usability... yes
>    configure: GDAL: 2.0.1
>    checking GDAL version >= 1.6.3... yes
>    checking for gcc... /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
>    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 /panfs/roc/msisoft/gcc/6.1.0/bin/gcc accepts -g... yes
>    checking for /panfs/roc/msisoft/gcc/6.1.0/bin/gcc option to accept ISO
>    C89... none needed
>    checking how to run the C preprocessor... /panfs/roc/msisoft/gcc/6.1.0/b
>    in/gcc
>    -E
>    checking for grep that handles long lines and -e... /bin/grep
>    checking for egrep... /bin/grep -E
>    checking for ANSI C header files... yes
>    checking for sys/types.h... yes
>    checking for sys/stat.h... yes
>    checking for stdlib.h... yes
>    checking for string.h... yes
>    checking for memory.h... yes
>    checking for strings.h... yes
>    checking for inttypes.h... yes
>    checking for stdint.h... yes
>    checking for unistd.h... yes
>    checking gdal.h usability... yes
>    checking gdal.h presence... yes
>    checking for gdal.h... yes
>    checking gdal: linking with --libs only... yes
>    checking GDAL: /soft/gdal/2.0.1/share/gdal/pcs.csv readable... yes
>    checking proj_api.h usability... yes
>    checking proj_api.h presence... yes
>    checking for proj_api.h... yes
>    checking for pj_init_plus in -lproj... no
>    configure: error: libproj not found in standard or given locations.
>    ERROR: configuration failed for package ‘rgdal’
>    * removing ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
>    linux-gnu-library/3.3/rgdal’
>
>    The downloaded source packages are in
>    â€˜/tmp/RtmpBVhI5E/downloaded_packages’
>    Warning message:
>    In install.packages("rgdal") :
>      installation of package ‘rgdal’ had non-zero exit status
>
>     [[alternative HTML version deleted]]
>
>    _______________________________________________
>    R-sig-Geo mailing list
>    [hidden email]
>    https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SJ8UGKdbyg0VNXfUCOOVJNKZJSQbEZ1KRCyHR_oEtC8&s=K2N5LvwRn4RSLJNVBjbxQyBFejL-jaD1fky4cOX6WwU&e=
>
> _______________________________________________
> 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]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
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: Problem with Proj when loading 'rgdal' on Super Computer Facility

Mon, 06/19/2017 - 10:40
I had trouble installing gdal and proj4 as well, but not trouble installing rgdal.

Is the path to proj4 and the proj4 library in your path? I put it in my .bashrc and it worked okay.

export LD_LIBRARY_PATH=/pathTobin/bin/proj4/lib:$LD_LIBRARY_PATH
export PATH==/pathTobin/bin/proj4/bin:$PATH

HTH,
Wade

-----Original Message-----
From: R-sig-Geo [mailto:[hidden email]] On Behalf Of Ryan Runquist
Sent: Monday, June 19, 2017 9:34 AM
To: [hidden email]
Subject: [R-sig-Geo] Problem with Proj when loading 'rgdal' on Super Computer Facility

Hello,

I am working on manipulating some spatial data and performing SDMs on invasive species. I have been using R and the package 'rgdal' to do some of these analyses.

On my own computer, Mac OSX 10.12.2 running R 3.3.3, I have had not problems installing 'rgdal', loading the library, and using the functions.

However, we are starting to work on the UMN MSI facility and we are having problems installing 'rgdal' on their Linux supercomputing cluster.

In order to install this package, we have to load the GDAL library and the
PROJ4 library in Linux. We have not had any problems loading their GDAL module and accessing the libraries. They work fine for 'rgeos'. However, we are having problems with the PROJ module.

When we run 'install.packages('rgdal')', the installation process begins, but it stalls when it checks for "'pj_init_plus' in -lproj", and then fails.

We have been working with someone at MSI to remedy this problem. They are able to see that the file does in fact exist and don't know why 'rgdal' is having problems locating it.

So far, we have tried different versions of PROJ (Proj 4.4.9, Proj 4.9.2, Proj 4.9.3_gcc4.8.2 - meaning it was compiled with gcc 4.8.2) and they have complied PROJ with GCC 4.8.2 instead of their default complier. They also tried to compile it with  GCC 6.3, but that failed with a complier error.

I have copied the full error message below.

Sincerely,

Ryan



> install.packages("rgdal")
Installing package into ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
linux-gnu-library/3.3’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session --- trying URL 'Blockedhttps://mirror.las.iastate.edu/CRAN/src/contrib/rgdal_1Blocked.
2-7.tar.gz'
Content type 'application/x-gzip' length 1653897 bytes (1.6 MB) ==================================================
downloaded 1.6 MB

* installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
configure: CC: /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
configure: CXX: /panfs/roc/msisoft/gcc/6.1.0/bin/g++
configure: rgdal: 1.2-7
checking for /usr/bin/svnversion... yes
configure: svn revision: 660
checking for gdal-config... /panfs/roc/msisoft/gdal/2.0.1/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 2.0.1
checking GDAL version >= 1.6.3... yes
checking for gcc... /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
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 /panfs/roc/msisoft/gcc/6.1.0/bin/gcc accepts -g... yes checking for /panfs/roc/msisoft/gcc/6.1.0/bin/gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /panfs/roc/msisoft/gcc/6.1.0/b in/gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking gdal.h usability... yes checking gdal.h presence... yes checking for gdal.h... yes checking gdal: linking with --libs only... yes checking GDAL: /soft/gdal/2.0.1/share/gdal/pcs.csv readable... yes checking proj_api.h usability... yes checking proj_api.h presence... yes checking for proj_api.h... yes checking for pj_init_plus in -lproj... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package ‘rgdal’
* removing ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
linux-gnu-library/3.3/rgdal’

The downloaded source packages are in
‘/tmp/RtmpBVhI5E/downloaded_packages’
Warning message:
In install.packages("rgdal") :
  installation of package ‘rgdal’ had non-zero exit status

        [[alternative HTML version deleted]]

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

Re: Problem with Proj when loading 'rgdal' on Super Computer Facility

Mon, 06/19/2017 - 10:16
Dear Ryan,

You **first** need to install the dependencies of rgdal.

sudo apt-get update && sudo apt-get install libgdal-dev libproj-dev

Then you should be able to install rgdal.

For more details google "rgdal install linux"

Best regards,


ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey

2017-06-19 16:33 GMT+02:00 Ryan Runquist <[hidden email]>:

> Hello,
>
> I am working on manipulating some spatial data and performing SDMs on
> invasive species. I have been using R and the package 'rgdal' to do some of
> these analyses.
>
> On my own computer, Mac OSX 10.12.2 running R 3.3.3, I have had not
> problems installing 'rgdal', loading the library, and using the functions.
>
> However, we are starting to work on the UMN MSI facility and we are having
> problems installing 'rgdal' on their Linux supercomputing cluster.
>
> In order to install this package, we have to load the GDAL library and the
> PROJ4 library in Linux. We have not had any problems loading their GDAL
> module and accessing the libraries. They work fine for 'rgeos'. However, we
> are having problems with the PROJ module.
>
> When we run 'install.packages('rgdal')', the installation process begins,
> but it stalls when it checks for "'pj_init_plus' in -lproj", and then
> fails.
>
> We have been working with someone at MSI to remedy this problem. They are
> able to see that the file does in fact exist and don't know why 'rgdal' is
> having problems locating it.
>
> So far, we have tried different versions of PROJ (Proj 4.4.9, Proj 4.9.2,
> Proj 4.9.3_gcc4.8.2 - meaning it was compiled with gcc 4.8.2) and they have
> complied PROJ with GCC 4.8.2 instead of their default complier. They also
> tried to compile it with  GCC 6.3, but that failed with a complier error.
>
> I have copied the full error message below.
>
> Sincerely,
>
> Ryan
>
>
>
> > install.packages("rgdal")
> Installing package into ‘/panfs/roc/groups/7/
> moeller/rbriscoe/R/x86_64-pc-
> linux-gnu-library/3.3’
> (as ‘lib’ is unspecified)
> --- Please select a CRAN mirror for use in this session ---
> trying URL 'https://mirror.las.iastate.edu/CRAN/src/contrib/rgdal_1.
> 2-7.tar.gz'
> Content type 'application/x-gzip' length 1653897 bytes (1.6 MB)
> ==================================================
> downloaded 1.6 MB
>
> * installing *source* package ‘rgdal’ ...
> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> configure: CC: /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
> configure: CXX: /panfs/roc/msisoft/gcc/6.1.0/bin/g++
> configure: rgdal: 1.2-7
> checking for /usr/bin/svnversion... yes
> configure: svn revision: 660
> checking for gdal-config... /panfs/roc/msisoft/gdal/2.0.1/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 2.0.1
> checking GDAL version >= 1.6.3... yes
> checking for gcc... /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
> 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 /panfs/roc/msisoft/gcc/6.1.0/bin/gcc accepts -g... yes
> checking for /panfs/roc/msisoft/gcc/6.1.0/bin/gcc option to accept ISO
> C89... none needed
> checking how to run the C preprocessor... /panfs/roc/msisoft/gcc/6.1.0/b
> in/gcc
> -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking gdal.h usability... yes
> checking gdal.h presence... yes
> checking for gdal.h... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /soft/gdal/2.0.1/share/gdal/pcs.csv readable... yes
> checking proj_api.h usability... yes
> checking proj_api.h presence... yes
> checking for proj_api.h... yes
> checking for pj_init_plus in -lproj... no
> configure: error: libproj not found in standard or given locations.
> ERROR: configuration failed for package ‘rgdal’
> * removing ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
> linux-gnu-library/3.3/rgdal’
>
> The downloaded source packages are in
> ‘/tmp/RtmpBVhI5E/downloaded_packages’
> Warning message:
> In install.packages("rgdal") :
>   installation of package ‘rgdal’ had non-zero exit status
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> 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: Problem with Proj when loading 'rgdal' on Super Computer Facility

Mon, 06/19/2017 - 10:13
Try passing the configure arguments to the command directly to rproj:

install.packages('rgdal', configure.args = '--with-proj-include=/correct/proj4/include --with-proj-lib=/correct/proj4/lib --with-proj-share=/correct/proj4/share')

On 6/19/17, 10:33 AM, "R-sig-Geo on behalf of Ryan Runquist" <[hidden email] on behalf of [hidden email]> wrote:

    Hello,
   
    I am working on manipulating some spatial data and performing SDMs on
    invasive species. I have been using R and the package 'rgdal' to do some of
    these analyses.
   
    On my own computer, Mac OSX 10.12.2 running R 3.3.3, I have had not
    problems installing 'rgdal', loading the library, and using the functions.
   
    However, we are starting to work on the UMN MSI facility and we are having
    problems installing 'rgdal' on their Linux supercomputing cluster.
   
    In order to install this package, we have to load the GDAL library and the
    PROJ4 library in Linux. We have not had any problems loading their GDAL
    module and accessing the libraries. They work fine for 'rgeos'. However, we
    are having problems with the PROJ module.
   
    When we run 'install.packages('rgdal')', the installation process begins,
    but it stalls when it checks for "'pj_init_plus' in -lproj", and then
    fails.
   
    We have been working with someone at MSI to remedy this problem. They are
    able to see that the file does in fact exist and don't know why 'rgdal' is
    having problems locating it.
   
    So far, we have tried different versions of PROJ (Proj 4.4.9, Proj 4.9.2,
    Proj 4.9.3_gcc4.8.2 - meaning it was compiled with gcc 4.8.2) and they have
    complied PROJ with GCC 4.8.2 instead of their default complier. They also
    tried to compile it with  GCC 6.3, but that failed with a complier error.
   
    I have copied the full error message below.
   
    Sincerely,
   
    Ryan
   
   
   
    > install.packages("rgdal")
    Installing package into ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
    linux-gnu-library/3.3’
    (as ‘lib’ is unspecified)
    --- Please select a CRAN mirror for use in this session ---
    trying URL 'https://urldefense.proofpoint.com/v2/url?u=https-3A__mirror.las.iastate.edu_CRAN_src_contrib_rgdal-5F1&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SJ8UGKdbyg0VNXfUCOOVJNKZJSQbEZ1KRCyHR_oEtC8&s=sqbCt8BPZes79H33y7aSpNnE5tALDJOhMfpOybZ4e7c&e= .
    2-7.tar.gz'
    Content type 'application/x-gzip' length 1653897 bytes (1.6 MB)
    ==================================================
    downloaded 1.6 MB
   
    * installing *source* package ‘rgdal’ ...
    ** package ‘rgdal’ successfully unpacked and MD5 sums checked
    configure: CC: /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
    configure: CXX: /panfs/roc/msisoft/gcc/6.1.0/bin/g++
    configure: rgdal: 1.2-7
    checking for /usr/bin/svnversion... yes
    configure: svn revision: 660
    checking for gdal-config... /panfs/roc/msisoft/gdal/2.0.1/bin/gdal-config
    checking gdal-config usability... yes
    configure: GDAL: 2.0.1
    checking GDAL version >= 1.6.3... yes
    checking for gcc... /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
    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 /panfs/roc/msisoft/gcc/6.1.0/bin/gcc accepts -g... yes
    checking for /panfs/roc/msisoft/gcc/6.1.0/bin/gcc option to accept ISO
    C89... none needed
    checking how to run the C preprocessor... /panfs/roc/msisoft/gcc/6.1.0/b
    in/gcc
    -E
    checking for grep that handles long lines and -e... /bin/grep
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking gdal.h usability... yes
    checking gdal.h presence... yes
    checking for gdal.h... yes
    checking gdal: linking with --libs only... yes
    checking GDAL: /soft/gdal/2.0.1/share/gdal/pcs.csv readable... yes
    checking proj_api.h usability... yes
    checking proj_api.h presence... yes
    checking for proj_api.h... yes
    checking for pj_init_plus in -lproj... no
    configure: error: libproj not found in standard or given locations.
    ERROR: configuration failed for package ‘rgdal’
    * removing ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
    linux-gnu-library/3.3/rgdal’
   
    The downloaded source packages are in
    ‘/tmp/RtmpBVhI5E/downloaded_packages’
    Warning message:
    In install.packages("rgdal") :
      installation of package ‘rgdal’ had non-zero exit status
   
    [[alternative HTML version deleted]]
   
    _______________________________________________
    R-sig-Geo mailing list
    [hidden email]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SJ8UGKdbyg0VNXfUCOOVJNKZJSQbEZ1KRCyHR_oEtC8&s=K2N5LvwRn4RSLJNVBjbxQyBFejL-jaD1fky4cOX6WwU&e= 

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

Problem with Proj when loading 'rgdal' on Super Computer Facility

Mon, 06/19/2017 - 09:33
Hello,

I am working on manipulating some spatial data and performing SDMs on
invasive species. I have been using R and the package 'rgdal' to do some of
these analyses.

On my own computer, Mac OSX 10.12.2 running R 3.3.3, I have had not
problems installing 'rgdal', loading the library, and using the functions.

However, we are starting to work on the UMN MSI facility and we are having
problems installing 'rgdal' on their Linux supercomputing cluster.

In order to install this package, we have to load the GDAL library and the
PROJ4 library in Linux. We have not had any problems loading their GDAL
module and accessing the libraries. They work fine for 'rgeos'. However, we
are having problems with the PROJ module.

When we run 'install.packages('rgdal')', the installation process begins,
but it stalls when it checks for "'pj_init_plus' in -lproj", and then
fails.

We have been working with someone at MSI to remedy this problem. They are
able to see that the file does in fact exist and don't know why 'rgdal' is
having problems locating it.

So far, we have tried different versions of PROJ (Proj 4.4.9, Proj 4.9.2,
Proj 4.9.3_gcc4.8.2 - meaning it was compiled with gcc 4.8.2) and they have
complied PROJ with GCC 4.8.2 instead of their default complier. They also
tried to compile it with  GCC 6.3, but that failed with a complier error.

I have copied the full error message below.

Sincerely,

Ryan



> install.packages("rgdal")
Installing package into ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
linux-gnu-library/3.3’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'https://mirror.las.iastate.edu/CRAN/src/contrib/rgdal_1.
2-7.tar.gz'
Content type 'application/x-gzip' length 1653897 bytes (1.6 MB)
==================================================
downloaded 1.6 MB

* installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
configure: CC: /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
configure: CXX: /panfs/roc/msisoft/gcc/6.1.0/bin/g++
configure: rgdal: 1.2-7
checking for /usr/bin/svnversion... yes
configure: svn revision: 660
checking for gdal-config... /panfs/roc/msisoft/gdal/2.0.1/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 2.0.1
checking GDAL version >= 1.6.3... yes
checking for gcc... /panfs/roc/msisoft/gcc/6.1.0/bin/gcc
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 /panfs/roc/msisoft/gcc/6.1.0/bin/gcc accepts -g... yes
checking for /panfs/roc/msisoft/gcc/6.1.0/bin/gcc option to accept ISO
C89... none needed
checking how to run the C preprocessor... /panfs/roc/msisoft/gcc/6.1.0/b
in/gcc
-E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking gdal.h usability... yes
checking gdal.h presence... yes
checking for gdal.h... yes
checking gdal: linking with --libs only... yes
checking GDAL: /soft/gdal/2.0.1/share/gdal/pcs.csv readable... yes
checking proj_api.h usability... yes
checking proj_api.h presence... yes
checking for proj_api.h... yes
checking for pj_init_plus in -lproj... no
configure: error: libproj not found in standard or given locations.
ERROR: configuration failed for package ‘rgdal’
* removing ‘/panfs/roc/groups/7/moeller/rbriscoe/R/x86_64-pc-
linux-gnu-library/3.3/rgdal’

The downloaded source packages are in
‘/tmp/RtmpBVhI5E/downloaded_packages’
Warning message:
In install.packages("rgdal") :
  installation of package ‘rgdal’ had non-zero exit status

        [[alternative HTML version deleted]]

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

r-spatial meetup @ dinner on Jul 5, Brussels

Mon, 06/19/2017 - 04:30
I'm planning an r-spatial meetup on the evening of Jul 5, during UseR!
in Brussels. If you want to take part & join, please let me know and
I'll include you in the reservation. Not limited to developers.

As of now, no sponsors are available meaning that the costs would be on
your own; offers to sponsor this event are also highly welcome.

The venue I have in mind is http://www.auxarmesdebruxelles.com/en/ -
they can handle larger groups well, and have a great kitchen, and the
last times I've been there they had a good price/quality ratio.

So far (twitter), we're 10:
https://docs.google.com/spreadsheets/d/10YikeTkQzo708yyrNWDxwBPS56kEksPe94obSAeFxIY/edit?usp=sharing

Many regards,
--
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

Re: [FORGED] spatstat residuals.ppm with an intensity given as an image?

Wed, 06/14/2017 - 19:39

On 07/06/17 22:22, Seth Flaxman wrote:

> I've got the intensity of an inhomogeneous Poisson process (fit using
> some new methods I'm working on, so not created by spatstat) as an
> image object, the observed point pattern as a ppp object, and I'd like
> to call residuals.ppm to compute residuals. Is there a simple way to
> create a fitted point process model (ppm) from an image and points so
> I can pass this directly to residuals.ppm?

Sorry for the long delay in responding.

There are two ways to do this:

[1] Fit a model using the putative intensity as an offset:

              fit1 <- ppm(X ~ offset(log(lam)))

where 'lam' is the pixel image of intensity, and 'X' is the point pattern.

Then do:

            res <- residuals(fit1)

[2] Fit some other model (e.g. just a constant intensity model) and use
the argument 'fittedvalues' of residuals.ppm to specify the fitted
intensity values.

            fit2 <- ppm(X ~ 1, forcefit=TRUE)

            res  <- residuals(fit2, fittedvalues=lam[quad.ppm(fit2)])

cheers,

Rolf Turner

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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

Re: rgdal PROJ.4 and a Mac

Wed, 06/14/2017 - 16:43
As a start I would suggest to
1) update R
2) update all packages
3 install latest proj4 version (currently 4.9.3)
5) use sf::st_read instead of rgdal::readOGR
4) update OSX


On 14. Jun 2017, 23:26 +0200, Adel Heenan <[hidden email]>, wrote:
> Hi all,
>
> I am new to using R for spatial analysis and have encountered what seems to
> be a common, known issue. When I use the functions readOGR or ssplot
> or proj4string() I get the following error message:
>
> NOTE: rgdal::checkCRSArgs: no proj_defs.dat in PROJ.4 shared files
>
> Here is my sessionInfo()
>
> R version 3.2.4 (2016-03-10)
> Platform: x86_64-apple-darwin13.4.0 (64-bit)
> Running under: OS X 10.10.3 (Yosemite)
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] rgdal_1.2-5 GISTools_0.7-4 rgeos_0.3-23 MASS_7.3-45
> RColorBrewer_1.1-2
> [6] maptools_0.9-2 sp_1.2-4
>
> I tried the fix suggested here:
>
> *https://stat.ethz.ch/pipermail/r-sig-geo/2017-January/025350.html
> <https://stat.ethz.ch/pipermail/r-sig-geo/2017-January/025350.html>*
>
> Specifically, I downloaded the windows binaries (the r-devel one - not sure
> if it matters) from here:
>
> https://cran.r-project.org/web/packages/rgdal/index.html
>
> And placed the proj and gdal folders in the rdgal folder -
>
> list.files(system.file("", package="rgdal"))
> [1] "ChangeLog" "data" "DESCRIPTION" "doc"
> "etc" "gdal"
> [7] "help" "html" "INDEX" "libs"
> "LICENSE.TXT" "Meta"
> [13] "NAMESPACE" "OSGeo4W_test" "pictures" "proj"
> "R" "README"
> [19] "README.windows" "SVN_VERSION" "vectors"
>
> But the same error comes up.
>
> Is there a different way in which I can try and fix this? I am unfamiliar
> with how to compile things from source.
>
> Many thanks,
>
> Adel
> [1] tools_3.2.4 foreign_0.8-66 grid_3.2.4 lattice_0.20-33
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> 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

rgdal PROJ.4 and a Mac

Wed, 06/14/2017 - 16:26
Hi all,

I am new to using R for spatial analysis and have encountered what seems to
be a common, known issue. When I use the functions readOGR or ssplot
or proj4string() I get the following error message:

NOTE: rgdal::checkCRSArgs: no proj_defs.dat in PROJ.4 shared files

Here is my sessionInfo()

R version 3.2.4 (2016-03-10)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] rgdal_1.2-5        GISTools_0.7-4     rgeos_0.3-23       MASS_7.3-45
     RColorBrewer_1.1-2
[6] maptools_0.9-2     sp_1.2-4

I tried the fix suggested here:

*https://stat.ethz.ch/pipermail/r-sig-geo/2017-January/025350.html
<https://stat.ethz.ch/pipermail/r-sig-geo/2017-January/025350.html>*

Specifically, I downloaded the windows binaries (the r-devel one - not sure
if it matters) from here:

https://cran.r-project.org/web/packages/rgdal/index.html

And placed the proj and gdal folders in the rdgal folder -

list.files(system.file("", package="rgdal"))
 [1] "ChangeLog"      "data"           "DESCRIPTION"    "doc"
 "etc"            "gdal"
 [7] "help"           "html"           "INDEX"          "libs"
"LICENSE.TXT"    "Meta"
[13] "NAMESPACE"      "OSGeo4W_test"   "pictures"       "proj"
"R"              "README"
[19] "README.windows" "SVN_VERSION"    "vectors"

But the same error comes up.

Is there a different way in which I can try and fix this? I am unfamiliar
with how to compile things from source.

Many thanks,

Adel
[1] tools_3.2.4     foreign_0.8-66  grid_3.2.4      lattice_0.20-33

        [[alternative HTML version deleted]]

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

Re: proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 15:52
Hi Shaun,

Yes, this would be an option, as would be avoiding shapefiles. Could you
(or Glenn) check that the same problem exists with a GPKG written by
ArcGIS and read into R using rgdal::readOGR() and sf::st_read(), and then
written out again using rgdal::writeOGR() and sf::st_write? A recent issue
on github at edzer/sfr showed that GPKG can be more effective at handing
this kind of issue than ESRI Shapefile formats. OGC GPKG should be
advanced strongly as the preferred modern format eradicating Shapefiles as
soon as possible (for numerous reasons, including encoding, field name
lengths, etc.). I don't have a current ESRI license, or I'd try the GPKG
roundtrip myself. I'd much rather spend time fixing things for GPKG (or
SQLite) than shapefiles.

Best wishes,

Roger

On Wed, 14 Jun 2017, Shaun Walbridge wrote:

> Glen,
>
> Round-tripping projection information can be tricky, in part because the
> normalization routines vary between different stacks, and what counts
> as the same form is also implementation dependent. In this case
> (round-tripping with ArcGIS), you may be better off using the
> arcgisbinding package [1], which can do the conversion to and from
> ArcGIS native data types (including some that aren't available via
> OGR/GDAL). It's easy enough to install [2], and also lets you build
> Geoprocessing tools which speak directly to R. I imagine there's also a
> pure R solution to the normalization, but it would likely have side
> effects for existing packages, and may not be easily solved.
>
> If you know that your data is fine and want a simple solution, you could
> also just overwrite the new shapefile’s .prj file with a copy of the
> original.
>
> Cheers,
> Shaun
>
> 1. https://urldefense.proofpoint.com/v2/url?u=https-3A__r-2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e=
> 2. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_R-2DArcGIS_r-2Dbridge-2Dinstall&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e=
>
> On 6/14/17, 9:35 AM, "R-sig-Geo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote:
>
>    I have a shapefile that I imported into R using readOGR from the rgdal
>    package. I do a little bit of work with it, like adding attribute
>    information, etc, then export it as an ESRI shapefile again, with a new
>    name. However, when I bring both the original and new shapefile into ArcGIS,
>    it tells me that the CRS do not match.
>
>    So, noting that all the projection parameters remain the same, but the
>    projection and coordinate system names are different, and the datum name is
>    dropped, my questions are:
>
>    1. Is the second CRS the same as the first?
>    2. If so, why did the names change, and why does ArcGIS no longer
>    recognize it as the same?
>    3. If not, how did it get changed?
>    4. Can the proj4string be modified to be more specific, and if so, why
>    did readOGR not already do this to preserve all the information?
>
>    I can use the new shapefiles just fine and readOGR interprets them as
>    identical, but it is a bit vexing that ArcGIS does not. And, I could of
>    course define it again in ArcGIS, but part of the motivation to work in R is
>    to obviate the need to point and click for many files.
>
>    I appreciate any insights or enlightenment.
>
>    Thanks,
>
>    Glenn
>
>    Here is the original projection information from ArcGIS:
>
>    Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator
>
>    Projection: Transverse_Mercator
>
>    False_Easting:  520000.00000000
>
>    False_Northing: -4480000.00000000
>
>    Central_Meridian:   -90.00000000
>
>    Scale_Factor:   0.99960000
>
>    Latitude_Of_Origin: 0.00000000
>
>    Linear Unit:    Meter
>
>
>
>    Geographic Coordinate System:   GCS_North_American_1983_HARN
>
>    Datum:  D_North_American_1983_HARN
>
>    Prime Meridian:     Greenwich
>
>    Angular Unit:   Degree
>
>    Here is the proj4string from R, which also agrees with the proj4string given
>    for this projection at www.spatialreference.org for epsg:3071 and also for
>    SR-ORG:7396.
>
>    +proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000
>    +ellps=GRS80 +units=m +no_defs
>
>    When I use writeOGR to export the SpatialPolygonsDataFrame with the above
>    proj4string, then bring it back into ArcGIS, the projection information is
>    given as the following, and is no longer recognized as identical to the
>    original.
>
>    Projected Coordinate System:    Transverse_Mercator
>
>    Projection: Transverse_Mercator
>
>    false_easting:  520000.00000000
>
>    false_northing: -4480000.00000000
>
>    central_meridian:   -90.00000000
>
>    scale_factor:   0.99960000
>
>    latitude_of_origin: 0.00000000
>
>    Linear Unit:    Meter
>
>
>
>    Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)
>
>    Datum:  D_unknown
>
>    Prime Meridian:     Greenwich
>
>    Angular Unit:   Degree
>
>
>
>
>
>
>     [[alternative HTML version deleted]]
>
>    _______________________________________________
>    R-sig-Geo mailing list
>    [hidden email]
>    https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia-3XoimuEiDzcY4Wh-CLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e=
>
>
>
> _______________________________________________
> 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]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
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: proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 12:48
Thanks for the link. That does shed some light, but I'm not sure I entirely understand. The .prj file does not store the EPSG ID, but it looks like the shapefile properties does include that information. Furthermore, when I overwrite the .prj file as Shaun suggested, the properties of the associated shapefile now does show " WKID: 3071 Authority: EPSG " whereas it did not previously. But aside from that, I'm  not sure why readOGR didn't identify the datum information in the first place. When I add "+datum=NAD83" to the proj4string, ArcGIS seems to accept it as the same CRS, even though the original datum was NAD83 HARN (which I don't know how to specify in R). But I am pretty new to this.... For now, overwriting the .prj with the desired one seems to work for me (and it is easy to do in a script).
Glenn

-----Original Message-----
From: R-sig-Geo [mailto:[hidden email]] On Behalf Of Edzer Pebesma
Sent: Wednesday, June 14, 2017 11:12 AM
To: [hidden email]
Subject: Re: [R-sig-Geo] proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Also relevant to this question is this discussion/issue:

https://github.com/edzer/sfr/issues/380

On 14/06/17 17:14, Shaun Walbridge wrote:
> Glen,
>
> Round-tripping projection information can be tricky, in part because
> the normalization routines vary between different stacks, and what
> counts as the same form is also implementation dependent. In this case
> (round-tripping with ArcGIS), you may be better off using the
> arcgisbinding package [1], which can do the conversion to and from
> ArcGIS native data types (including some that aren't available via
> OGR/GDAL). It's easy enough to install [2], and also lets you build
> Geoprocessing tools which speak directly to R. I imagine there's also
> a pure R solution to the normalization, but it would likely have side
> effects for existing packages, and may not be easily solved.
>
> If you know that your data is fine and want a simple solution, you
> could also just overwrite the new shapefile’s .prj file with a copy of
> the original.
>
> Cheers,
> Shaun
>
> 1.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__r-2Darcgis.github
> .io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb
> 7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W
> 0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e=
> 2.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_R-2DAr
> cGIS_r-2Dbridge-2Dinstall&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX
> -vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm
> 65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e=
>
> On 6/14/17, 9:35 AM, "R-sig-Geo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote:
>
>     I have a shapefile that I imported into R using readOGR from the rgdal
>     package. I do a little bit of work with it, like adding attribute
>     information, etc, then export it as an ESRI shapefile again, with a new
>     name. However, when I bring both the original and new shapefile into ArcGIS,
>     it tells me that the CRS do not match.
>    
>     So, noting that all the projection parameters remain the same, but the
>     projection and coordinate system names are different, and the datum name is
>     dropped, my questions are:
>    
>     1. Is the second CRS the same as the first?
>     2. If so, why did the names change, and why does ArcGIS no longer
>     recognize it as the same?
>     3. If not, how did it get changed?
>     4. Can the proj4string be modified to be more specific, and if so, why
>     did readOGR not already do this to preserve all the information?
>    
>     I can use the new shapefiles just fine and readOGR interprets them as
>     identical, but it is a bit vexing that ArcGIS does not. And, I could of
>     course define it again in ArcGIS, but part of the motivation to work in R is
>     to obviate the need to point and click for many files.
>    
>     I appreciate any insights or enlightenment.
>    
>     Thanks,
>    
>     Glenn
>    
>     Here is the original projection information from ArcGIS:
>    
>     Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator
>    
>     Projection: Transverse_Mercator
>    
>     False_Easting:  520000.00000000
>    
>     False_Northing: -4480000.00000000
>    
>     Central_Meridian:   -90.00000000
>    
>     Scale_Factor:   0.99960000
>    
>     Latitude_Of_Origin: 0.00000000
>    
>     Linear Unit:    Meter
>    
>      
>    
>     Geographic Coordinate System:   GCS_North_American_1983_HARN
>    
>     Datum:  D_North_American_1983_HARN
>    
>     Prime Meridian:     Greenwich
>    
>     Angular Unit:   Degree
>    
>     Here is the proj4string from R, which also agrees with the proj4string given
>     for this projection at www.spatialreference.org for epsg:3071 and also for
>     SR-ORG:7396.
>    
>     +proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000
>     +ellps=GRS80 +units=m +no_defs
>    
>     When I use writeOGR to export the SpatialPolygonsDataFrame with the above
>     proj4string, then bring it back into ArcGIS, the projection information is
>     given as the following, and is no longer recognized as identical to the
>     original.
>    
>     Projected Coordinate System:    Transverse_Mercator
>    
>     Projection: Transverse_Mercator
>    
>     false_easting:  520000.00000000
>    
>     false_northing: -4480000.00000000
>    
>     central_meridian:   -90.00000000
>    
>     scale_factor:   0.99960000
>    
>     latitude_of_origin: 0.00000000
>    
>     Linear Unit:    Meter
>    
>      
>    
>     Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)
>    
>     Datum:  D_unknown
>    
>     Prime Meridian:     Greenwich
>    
>     Angular Unit:   Degree
>    
>      
>    
>      
>    
>    
>     [[alternative HTML version deleted]]
>    
>     _______________________________________________
>     R-sig-Geo mailing list
>     [hidden email]
>    
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail
> man_listinfo_r-2Dsig-2Dgeo&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkc
> UCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia-3XoimuEiDzcY
> 4Wh-CLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e=
>    
>
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/

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

Re: proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 12:23
Thanks Shaun,
I have not gotten the arcgisbinding package to work yet, and will play around with it some more later. For now, overwriting the .prj file works just fine and does what I want, but it seems like a less-than-satisfactory general solution.

Glenn

-----Original Message-----
From: Shaun Walbridge [mailto:[hidden email]]
Sent: Wednesday, June 14, 2017 10:14 AM
To: Glenn Stauffer; [hidden email]
Subject: Re: [R-sig-Geo] proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Glen,



Round-tripping projection information can be tricky, in part because the

normalization routines vary between different stacks, and what counts

as the same form is also implementation dependent. In this case

(round-tripping with ArcGIS), you may be better off using the

arcgisbinding package [1], which can do the conversion to and from

ArcGIS native data types (including some that aren't available via

OGR/GDAL). It's easy enough to install [2], and also lets you build

Geoprocessing tools which speak directly to R. I imagine there's also a

pure R solution to the normalization, but it would likely have side

effects for existing packages, and may not be easily solved.



If you know that your data is fine and want a simple solution, you could

also just overwrite the new shapefile’s .prj file with a copy of the

original.



Cheers,

Shaun



1. https://urldefense.proofpoint.com/v2/url?u=https-3A__r-2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=5UpQjHXPqFUScg58BUIFe0V27sq0j0SU7iU72HpYMRE&m=_FSAFRAGaC_k8hnGwM32OZirmWVi4Y5JSgcMf6lcemc&s=_ZSX1hSgmnuhYzWoUo1N-3o_6nKHXkyG4VwSmOB276M&e= 

2. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_R-2DArcGIS_r-2Dbridge-2Dinstall&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=5UpQjHXPqFUScg58BUIFe0V27sq0j0SU7iU72HpYMRE&m=_FSAFRAGaC_k8hnGwM32OZirmWVi4Y5JSgcMf6lcemc&s=xV9M4ZmMdIeeGjFZaKaEt-SQA4CAvcB0_UWCjm-qUX0&e= 



On 6/14/17, 9:35 AM, "R-sig-Geo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote:



    I have a shapefile that I imported into R using readOGR from the rgdal

    package. I do a little bit of work with it, like adding attribute

    information, etc, then export it as an ESRI shapefile again, with a new

    name. However, when I bring both the original and new shapefile into ArcGIS,

    it tells me that the CRS do not match.

   

    So, noting that all the projection parameters remain the same, but the

    projection and coordinate system names are different, and the datum name is

    dropped, my questions are:

   

    1. Is the second CRS the same as the first?

    2. If so, why did the names change, and why does ArcGIS no longer

    recognize it as the same?

    3. If not, how did it get changed?

    4. Can the proj4string be modified to be more specific, and if so, why

    did readOGR not already do this to preserve all the information?

   

    I can use the new shapefiles just fine and readOGR interprets them as

    identical, but it is a bit vexing that ArcGIS does not. And, I could of

    course define it again in ArcGIS, but part of the motivation to work in R is

    to obviate the need to point and click for many files.

   

    I appreciate any insights or enlightenment.

   

    Thanks,

   

    Glenn

   

    Here is the original projection information from ArcGIS:

   

    Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator

   

    Projection: Transverse_Mercator

   

    False_Easting:  520000.00000000

   

    False_Northing: -4480000.00000000

   

    Central_Meridian:   -90.00000000

   

    Scale_Factor:   0.99960000

   

    Latitude_Of_Origin: 0.00000000

   

    Linear Unit:    Meter

   

     

   

    Geographic Coordinate System:   GCS_North_American_1983_HARN

   

    Datum:  D_North_American_1983_HARN

   

    Prime Meridian:     Greenwich

   

    Angular Unit:   Degree

   

    Here is the proj4string from R, which also agrees with the proj4string given

    for this projection at www.spatialreference.org for epsg:3071 and also for

    SR-ORG:7396.

   

    +proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000

    +ellps=GRS80 +units=m +no_defs

   

    When I use writeOGR to export the SpatialPolygonsDataFrame with the above

    proj4string, then bring it back into ArcGIS, the projection information is

    given as the following, and is no longer recognized as identical to the

    original.

   

    Projected Coordinate System:    Transverse_Mercator

   

    Projection: Transverse_Mercator

   

    false_easting:  520000.00000000

   

    false_northing: -4480000.00000000

   

    central_meridian:   -90.00000000

   

    scale_factor:   0.99960000

   

    latitude_of_origin: 0.00000000

   

    Linear Unit:    Meter

   

     

   

    Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)

   

    Datum:  D_unknown

   

    Prime Meridian:     Greenwich

   

    Angular Unit:   Degree

   

     

   

     

   

   

    [[alternative HTML version deleted]]

   

    _______________________________________________

    R-sig-Geo mailing list

    [hidden email]

    https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia-3XoimuEiDzcY4Wh-CLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= 

   

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

Re: proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 11:11
Also relevant to this question is this discussion/issue:

https://github.com/edzer/sfr/issues/380

On 14/06/17 17:14, Shaun Walbridge wrote:
> Glen,
>
> Round-tripping projection information can be tricky, in part because the
> normalization routines vary between different stacks, and what counts
> as the same form is also implementation dependent. In this case
> (round-tripping with ArcGIS), you may be better off using the
> arcgisbinding package [1], which can do the conversion to and from
> ArcGIS native data types (including some that aren't available via
> OGR/GDAL). It's easy enough to install [2], and also lets you build
> Geoprocessing tools which speak directly to R. I imagine there's also a
> pure R solution to the normalization, but it would likely have side
> effects for existing packages, and may not be easily solved.
>
> If you know that your data is fine and want a simple solution, you could
> also just overwrite the new shapefile’s .prj file with a copy of the
> original.
>
> Cheers,
> Shaun
>
> 1. https://urldefense.proofpoint.com/v2/url?u=https-3A__r-2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= 
> 2. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_R-2DArcGIS_r-2Dbridge-2Dinstall&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= 
>
> On 6/14/17, 9:35 AM, "R-sig-Geo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote:
>
>     I have a shapefile that I imported into R using readOGR from the rgdal
>     package. I do a little bit of work with it, like adding attribute
>     information, etc, then export it as an ESRI shapefile again, with a new
>     name. However, when I bring both the original and new shapefile into ArcGIS,
>     it tells me that the CRS do not match.
>    
>     So, noting that all the projection parameters remain the same, but the
>     projection and coordinate system names are different, and the datum name is
>     dropped, my questions are:
>    
>     1. Is the second CRS the same as the first?
>     2. If so, why did the names change, and why does ArcGIS no longer
>     recognize it as the same?
>     3. If not, how did it get changed?
>     4. Can the proj4string be modified to be more specific, and if so, why
>     did readOGR not already do this to preserve all the information?
>    
>     I can use the new shapefiles just fine and readOGR interprets them as
>     identical, but it is a bit vexing that ArcGIS does not. And, I could of
>     course define it again in ArcGIS, but part of the motivation to work in R is
>     to obviate the need to point and click for many files.
>    
>     I appreciate any insights or enlightenment.
>    
>     Thanks,
>    
>     Glenn
>    
>     Here is the original projection information from ArcGIS:
>    
>     Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator
>    
>     Projection: Transverse_Mercator
>    
>     False_Easting:  520000.00000000
>    
>     False_Northing: -4480000.00000000
>    
>     Central_Meridian:   -90.00000000
>    
>     Scale_Factor:   0.99960000
>    
>     Latitude_Of_Origin: 0.00000000
>    
>     Linear Unit:    Meter
>    
>      
>    
>     Geographic Coordinate System:   GCS_North_American_1983_HARN
>    
>     Datum:  D_North_American_1983_HARN
>    
>     Prime Meridian:     Greenwich
>    
>     Angular Unit:   Degree
>    
>     Here is the proj4string from R, which also agrees with the proj4string given
>     for this projection at www.spatialreference.org for epsg:3071 and also for
>     SR-ORG:7396.
>    
>     +proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000
>     +ellps=GRS80 +units=m +no_defs
>    
>     When I use writeOGR to export the SpatialPolygonsDataFrame with the above
>     proj4string, then bring it back into ArcGIS, the projection information is
>     given as the following, and is no longer recognized as identical to the
>     original.
>    
>     Projected Coordinate System:    Transverse_Mercator
>    
>     Projection: Transverse_Mercator
>    
>     false_easting:  520000.00000000
>    
>     false_northing: -4480000.00000000
>    
>     central_meridian:   -90.00000000
>    
>     scale_factor:   0.99960000
>    
>     latitude_of_origin: 0.00000000
>    
>     Linear Unit:    Meter
>    
>      
>    
>     Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)
>    
>     Datum:  D_unknown
>    
>     Prime Meridian:     Greenwich
>    
>     Angular Unit:   Degree
>    
>      
>    
>      
>    
>    
>     [[alternative HTML version deleted]]
>    
>     _______________________________________________
>     R-sig-Geo mailing list
>     [hidden email]
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia-3XoimuEiDzcY4Wh-CLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= 
>    
>
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

Re: proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 10:14
Glen,

Round-tripping projection information can be tricky, in part because the
normalization routines vary between different stacks, and what counts
as the same form is also implementation dependent. In this case
(round-tripping with ArcGIS), you may be better off using the
arcgisbinding package [1], which can do the conversion to and from
ArcGIS native data types (including some that aren't available via
OGR/GDAL). It's easy enough to install [2], and also lets you build
Geoprocessing tools which speak directly to R. I imagine there's also a
pure R solution to the normalization, but it would likely have side
effects for existing packages, and may not be easily solved.

If you know that your data is fine and want a simple solution, you could
also just overwrite the new shapefile’s .prj file with a copy of the
original.

Cheers,
Shaun

1. https://urldefense.proofpoint.com/v2/url?u=https-3A__r-2Darcgis.github.io_assets_arcgisbinding.pdf&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=pIBxR3icnDLcn639TzBc0mkXy6Tv7G9Ip7xcWSAMweU&e= 
2. https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_R-2DArcGIS_r-2Dbridge-2Dinstall&d=DwIGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=fCPRb7QX-vd5bnO9gIJHCiX852SVUtyYX--xtCKtpfk&m=9su2o7yjMBqHmqZT3kZAlTRZwPC_W0Tm65yvo7NmjLw&s=JADt055JJUuCG1eltd7N9o5f_fu_geqGlnzO62SGtGM&e= 

On 6/14/17, 9:35 AM, "R-sig-Geo on behalf of Glenn Stauffer" <[hidden email] on behalf of [hidden email]> wrote:

    I have a shapefile that I imported into R using readOGR from the rgdal
    package. I do a little bit of work with it, like adding attribute
    information, etc, then export it as an ESRI shapefile again, with a new
    name. However, when I bring both the original and new shapefile into ArcGIS,
    it tells me that the CRS do not match.
   
    So, noting that all the projection parameters remain the same, but the
    projection and coordinate system names are different, and the datum name is
    dropped, my questions are:
   
    1. Is the second CRS the same as the first?
    2. If so, why did the names change, and why does ArcGIS no longer
    recognize it as the same?
    3. If not, how did it get changed?
    4. Can the proj4string be modified to be more specific, and if so, why
    did readOGR not already do this to preserve all the information?
   
    I can use the new shapefiles just fine and readOGR interprets them as
    identical, but it is a bit vexing that ArcGIS does not. And, I could of
    course define it again in ArcGIS, but part of the motivation to work in R is
    to obviate the need to point and click for many files.
   
    I appreciate any insights or enlightenment.
   
    Thanks,
   
    Glenn
   
    Here is the original projection information from ArcGIS:
   
    Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator
   
    Projection: Transverse_Mercator
   
    False_Easting:  520000.00000000
   
    False_Northing: -4480000.00000000
   
    Central_Meridian:   -90.00000000
   
    Scale_Factor:   0.99960000
   
    Latitude_Of_Origin: 0.00000000
   
    Linear Unit:    Meter
   
     
   
    Geographic Coordinate System:   GCS_North_American_1983_HARN
   
    Datum:  D_North_American_1983_HARN
   
    Prime Meridian:     Greenwich
   
    Angular Unit:   Degree
   
    Here is the proj4string from R, which also agrees with the proj4string given
    for this projection at www.spatialreference.org for epsg:3071 and also for
    SR-ORG:7396.
   
    +proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000
    +ellps=GRS80 +units=m +no_defs
   
    When I use writeOGR to export the SpatialPolygonsDataFrame with the above
    proj4string, then bring it back into ArcGIS, the projection information is
    given as the following, and is no longer recognized as identical to the
    original.
   
    Projected Coordinate System:    Transverse_Mercator
   
    Projection: Transverse_Mercator
   
    false_easting:  520000.00000000
   
    false_northing: -4480000.00000000
   
    central_meridian:   -90.00000000
   
    scale_factor:   0.99960000
   
    latitude_of_origin: 0.00000000
   
    Linear Unit:    Meter
   
     
   
    Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)
   
    Datum:  D_unknown
   
    Prime Meridian:     Greenwich
   
    Angular Unit:   Degree
   
     
   
     
   
   
    [[alternative HTML version deleted]]
   
    _______________________________________________
    R-sig-Geo mailing list
    [hidden email]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=DwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=Ws5QzgjxjD1HGvdDia-3XoimuEiDzcY4Wh-CLS905w0&s=gBdaQAI6IxVnnl8qdt_GTEeiM7f2_5dd15qzQOsQ_64&e= 
   


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

proj4string read by readOGR doesn't seem to precisely specify source shapefile projection

Wed, 06/14/2017 - 08:35
I have a shapefile that I imported into R using readOGR from the rgdal
package. I do a little bit of work with it, like adding attribute
information, etc, then export it as an ESRI shapefile again, with a new
name. However, when I bring both the original and new shapefile into ArcGIS,
it tells me that the CRS do not match.

So, noting that all the projection parameters remain the same, but the
projection and coordinate system names are different, and the datum name is
dropped, my questions are:

1. Is the second CRS the same as the first?
2. If so, why did the names change, and why does ArcGIS no longer
recognize it as the same?
3. If not, how did it get changed?
4. Can the proj4string be modified to be more specific, and if so, why
did readOGR not already do this to preserve all the information?

I can use the new shapefiles just fine and readOGR interprets them as
identical, but it is a bit vexing that ArcGIS does not. And, I could of
course define it again in ArcGIS, but part of the motivation to work in R is
to obviate the need to point and click for many files.

I appreciate any insights or enlightenment.

Thanks,

Glenn

Here is the original projection information from ArcGIS:

Projected Coordinate System:    NAD_1983_HARN_Transverse_Mercator

Projection: Transverse_Mercator

False_Easting:  520000.00000000

False_Northing: -4480000.00000000

Central_Meridian:   -90.00000000

Scale_Factor:   0.99960000

Latitude_Of_Origin: 0.00000000

Linear Unit:    Meter

 

Geographic Coordinate System:   GCS_North_American_1983_HARN

Datum:  D_North_American_1983_HARN

Prime Meridian:     Greenwich

Angular Unit:   Degree

Here is the proj4string from R, which also agrees with the proj4string given
for this projection at www.spatialreference.org for epsg:3071 and also for
SR-ORG:7396.

+proj=tmerc +lat_0=0 +lon_0=-90 +k=0.9996 +x_0=520000 +y_0=-4480000
+ellps=GRS80 +units=m +no_defs

When I use writeOGR to export the SpatialPolygonsDataFrame with the above
proj4string, then bring it back into ArcGIS, the projection information is
given as the following, and is no longer recognized as identical to the
original.

Projected Coordinate System:    Transverse_Mercator

Projection: Transverse_Mercator

false_easting:  520000.00000000

false_northing: -4480000.00000000

central_meridian:   -90.00000000

scale_factor:   0.99960000

latitude_of_origin: 0.00000000

Linear Unit:    Meter

 

Geographic Coordinate System:   GCS_GRS 1980(IUGG, 1980)

Datum:  D_unknown

Prime Meridian:     Greenwich

Angular Unit:   Degree

 

 


        [[alternative HTML version deleted]]

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

Using multiple transition layers in gdistance (least cost analysis)

Wed, 06/14/2017 - 05:17
Dear all,

I have created shortest paths using slope with Tobler's (and others) cost
functions, but I'm wondering if anyone has used multiple transition layers
to create a more 'realistic' model?

I currently have a raster of rivers, with the rivers having a value of 1000
and the land as a value of 1. I would like to integrate this within the
model so as to block the travel through rivers.

I have found that I can do the following, which will define areas where
paths can go:


*rfac = asFactor(rivers == 0)rfactr <-  transition(rfac, "areas", 8)*

However, I'm not sure whether there needs to be a geocorrection after each
transition calculation, then multiplying the slope-transition layer and the
river-transition layer, or whether a single geocorrection should be done
after the two layers are multiplied together.

Any help, or links to where this has been done before would be appreciated.

Kind regards,
Joe

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

        [[alternative HTML version deleted]]

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

Re: Increasing resolution of stkrige maps

Tue, 06/13/2017 - 15:18
Thank you so much dr. Carlson I will try this I think it might help

On 13 Jun 2017 22:00, "David L Carlson" <[hidden email]> wrote:

> There is no stkrige() function in package gstat. Do you mean krigeST()?
>
> You have many options in R for producing plots and charts in various
> formats and resolutions depending on your operating system:
>
> > ?Devices
>
> will give you more details for your specific operating system. For example,
>
> pdf("MyFigure.pdf")
> plot(. . .)
> dev.off()
>
> will produce a .pdf file in your current directory. You have control over
> the size and resolution of the plot and whether it should be vector or
> raster.
>
> -------------------------------------
> David L Carlson
> Department of Anthropology
> Texas A&M University
> College Station, TX 77840-4352
>
> -----Original Message-----
> From: R-sig-Geo [mailto:[hidden email]] On Behalf Of
> sara osama
> Sent: Tuesday, June 13, 2017 1:26 PM
> To: [hidden email]
> Subject: [R-sig-Geo] Increasing resolution of stkrige maps
>
> Dear all
> I have created interpolated maps using stkrige in gstat but when copying it
> and paste in word file the resolution  is not good enough is there any way
> to increase the resolution of the created maps in R
>
> Thanks in advance
> Sara
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> 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: Increasing resolution of stkrige maps

Tue, 06/13/2017 - 15:00
There is no stkrige() function in package gstat. Do you mean krigeST()?

You have many options in R for producing plots and charts in various formats and resolutions depending on your operating system:

> ?Devices

will give you more details for your specific operating system. For example,

pdf("MyFigure.pdf")
plot(. . .)
dev.off()

will produce a .pdf file in your current directory. You have control over the size and resolution of the plot and whether it should be vector or raster.

-------------------------------------
David L Carlson
Department of Anthropology
Texas A&M University
College Station, TX 77840-4352

-----Original Message-----
From: R-sig-Geo [mailto:[hidden email]] On Behalf Of sara osama
Sent: Tuesday, June 13, 2017 1:26 PM
To: [hidden email]
Subject: [R-sig-Geo] Increasing resolution of stkrige maps

Dear all
I have created interpolated maps using stkrige in gstat but when copying it
and paste in word file the resolution  is not good enough is there any way
to increase the resolution of the created maps in R

Thanks in advance
Sara

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

Pages