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: 2 hours 16 min ago

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 11:52
On Fri, 21 Sep 2018, Rich Shepard wrote:

> On Fri, 21 Sep 2018, [hidden email] wrote:
>
>>  I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems
>>  that the minimun required version has been satisfied. But on the system I
>>  have two version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the
>>  version v4.9.1 ( /usr/local/bin/proj ).
>
> David,
>
>  This is the cause of many problems: two different versions of software on
> the same host.
>
>>  So can I force the use of the new version of PROJ with some parameters
>>  during the installation of RGDAL?
>
>  Take a look at your $PATH; it's likely that /usr/local/bin/ is checked
> before usr/bin/. And different applications using, e.g., proj4, may look for
> it in either place. This means that one application finds the 4.9.1 version
> while another application finds the 4.8.0 version.
Rich: thanks - having multiple versions is indeed a challenge on platforms
where R uses dynamically loaded libraries. On Windows and MacOS, most CRAN
packages with external dependencies are built with static linking (the
*old* way). However, executables are on the PATH, but dynamically loaded
libraries - shared objects - are on LD_LIBRARY_PATH. Try:

echo $LD_LIBRARY_PATH

at the shell prompt, then inside R:

Sys.getenv("LD_LIBRARY_PATH")

and you'll see that R may have made modifications on startup. A typical
trap is also forgetting to run /sbin/ldconfig -v as root after installing
software in /usr/local/lib (and adding /usr/local/lib to a file in
/etc/ld.so.conf.d) so that the shared objects are visible.

The easier route is to have just one version of external software
installed where R can see it; it is harder but possibly on a cluster
necessary to modify LD_LIBRARY_PATH locally and consistently. Also look at
closed sf issues on github; there we stepped back from messing with
LD_LIBRARY_PATH on a general basis.

Hope this helps,

Roger


>
>  I recommend that you put all core binaries in /usr/bin (which means moving
> 4.9.1 from /usr/local/bin/ to /usr/bin/ and keeping in the latter only
> software developed locally.
>
>  My network runs Slackware so I don't know how difficult it might be for
> you to re-organize your CentOS installations, but making the time to do this
> will make life easier for you.
>
> Best regards,
>
> Rich
>
> _______________________________________________
> 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: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 09:02
On Fri, 21 Sep 2018, [hidden email] wrote:

> I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems
> that the minimun required version has been satisfied. But on the system I
> have two version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the
> version v4.9.1 ( /usr/local/bin/proj ).

David,

   This is the cause of many problems: two different versions of software on
the same host.

> So can I force the use of the new version of PROJ with some parameters
> during the installation of RGDAL?

   Take a look at your $PATH; it's likely that /usr/local/bin/ is checked
before usr/bin/. And different applications using, e.g., proj4, may look for
it in either place. This means that one application finds the 4.9.1 version
while another application finds the 4.8.0 version.

   I recommend that you put all core binaries in /usr/bin (which means moving
4.9.1 from /usr/local/bin/ to /usr/bin/ and keeping in the latter only
software developed locally.

   My network runs Slackware so I don't know how difficult it might be for
you to re-organize your CentOS installations, but making the time to do this
will make life easier for you.

Best regards,

Rich

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

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 08:35
Dear Roger, thanks for your reply.

I know, that this cluster have several problems, at first the pool software.
I'm the maintainer and not the creator, so I have inherited all this problems.

The version of OS is Centos 7.5 and unluckly all the software has been installed
via EPEL repository and not from source.

I have checked all the packages (GDAL v1.11.4, PROJ4 v4.9.1) and seems that
the minimun required version has been satisfied. But on the system I have two
version of PROJ4, the version v4.8.0 ( /usr/bin/proj ) and the version v4.9.1
( /usr/local/bin/proj ).

So can I force the use of the new version of PROJ with some parameters during
the installation of RGDAL?

Thanks in advance for your support.
David

-----Original Message-----
From: Roger Bivand [mailto:[hidden email]]
Sent: Friday, September 21, 2018 12:25 PM
To: GIOVANNINI David (JRC-ISPRA-EXT)
Cc: [hidden email]
Subject: Re: [R-sig-Geo] RGDAL installation fail after yum upgrade

On Fri, 21 Sep 2018, [hidden email] wrote:

> Dear list members, I'm tring to install RGDAL on a cluster, but after
> the update of R packages seems not possible to install it.

On a cluster running which very outdated version of which operating
system? How did you install PROJ and GDAL, hopefully from source? How did
you install R, again hopefully from source? If you install from source,
your upstream binaries should only use the limited resources of your
outdated platform; if you install binary packages, those packages will
make brave and possibly untrue assumptions about your platform. It is also
very possible that you have multiple versions of GDAL and/or PROJ on your
systems, and that (parts of) configure and install find different
versions. In particular, at least one version of PROJ does not have
pj_ctx_* file access functions, needed in several places.

If you can't fix your systems (PROJ 4.8.0 was released in 2012, over 6
years ago), use a version of rgdal, GDAL and driver software to match your
vintage. Possibly your compile trains are also very outdated too.

Maintainers cannot be expected to keep current package versions running
smoothly on ancient platforms (although we try to help) without active
contributions from interested users. Provide patches to configure.ac that
work for you and do not have any negative impacts on current systems, or
keep your systems more up to date.

Roger

>
> Below the error message:
>
>> install.packages("rgdal")
> Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
> (as 'lib' is unspecified)
> trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
> Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
> ==================================================
> downloaded 1.6 MB
>
> * installing *source* package 'rgdal' ...
> ** package 'rgdal' successfully unpacked and MD5 sums checked
> configure: R_HOME: /usr/lib64/R
> configure: CC: gcc -m64 -std=gnu99
> configure: CXX: g++ -m64
> configure: C++11 support available
> configure: rgdal: 1.3-4
> checking for /usr/bin/svnversion... yes
> configure: svn revision: 766
> checking for gdal-config... /bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 1.11.4
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /usr/share/gdal/pcs.csv readable... yes
> checking proj_api.h presence and usability... yes
> ./configure: line 2126: test: =: unary operator expected
> checking PROJ version >= 4.8.0... yes
> checking projects.h presence and usability... yes
> /tmp/ccnBOZCl.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2242: ./proj_conf_test2: No such file or directory
> checking PROJ.4: epsg found and readable... yes
> /tmp/ccu3xNdp.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2301: ./proj_conf_test3: No such file or directory
> checking PROJ.4: conus found and readable... yes
> configure: Package CPP flags:  -I/usr/include/gdal
> configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
> ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
> ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
>     double DINT_MAX = 2251799813685248.0;
>            ^
> ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
>     double DINT_MIN = -2251799813685248.0;
>            ^
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
> g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
> installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
>  converting help for package 'rgdal'
>    finding HTML links ... done
>    CRS-class                               html
>    GDALDataset-class                       html
>    GDALDriver-class                        html
>    GDALMajorObject-class                   html
>    GDALRasterBand-class                    html
>    GDALReadOnlyDataset-class               html
>    GDALReadOnlyDataset-methods             html
>    GDALTransientDataset-class              html
>    GridsDatums                             html
>    RGB2PCT                                 html
>    SGDF2PCT                                html
>    SpatialGDAL-class                       html
>    closeDataset-methods                    html
>    displayDataset                          html
>    llgrid                                  html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
>    make_EPSG                               html
>    nor2k                                   html
>    projInfo                                html
>    project                                 html
>    readGDAL                                html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
>    readOGR                                 html
>    showWKT                                 html
>    spTransform-methods                     html
>    wrappers                                html
>    writeOGR                                html
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
> unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
>  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'
>
> The downloaded source packages are in
>     '/tmp/RtmpXrQsj2/downloaded_packages'
> Warning message:
> In install.packages("rgdal") :
>  installation of package 'rgdal' had non-zero exit status
>
> I have tried several solutions but without any success.
>
> Have you any idea about the problem?
>
> Thanks in advance
> David
>
> [[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

Re: RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 05:25
On Fri, 21 Sep 2018, [hidden email] wrote:

> Dear list members, I'm tring to install RGDAL on a cluster, but after
> the update of R packages seems not possible to install it.

On a cluster running which very outdated version of which operating
system? How did you install PROJ and GDAL, hopefully from source? How did
you install R, again hopefully from source? If you install from source,
your upstream binaries should only use the limited resources of your
outdated platform; if you install binary packages, those packages will
make brave and possibly untrue assumptions about your platform. It is also
very possible that you have multiple versions of GDAL and/or PROJ on your
systems, and that (parts of) configure and install find different
versions. In particular, at least one version of PROJ does not have
pj_ctx_* file access functions, needed in several places.

If you can't fix your systems (PROJ 4.8.0 was released in 2012, over 6
years ago), use a version of rgdal, GDAL and driver software to match your
vintage. Possibly your compile trains are also very outdated too.

Maintainers cannot be expected to keep current package versions running
smoothly on ancient platforms (although we try to help) without active
contributions from interested users. Provide patches to configure.ac that
work for you and do not have any negative impacts on current systems, or
keep your systems more up to date.

Roger

>
> Below the error message:
>
>> install.packages("rgdal")
> Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
> (as 'lib' is unspecified)
> trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
> Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
> ==================================================
> downloaded 1.6 MB
>
> * installing *source* package 'rgdal' ...
> ** package 'rgdal' successfully unpacked and MD5 sums checked
> configure: R_HOME: /usr/lib64/R
> configure: CC: gcc -m64 -std=gnu99
> configure: CXX: g++ -m64
> configure: C++11 support available
> configure: rgdal: 1.3-4
> checking for /usr/bin/svnversion... yes
> configure: svn revision: 766
> checking for gdal-config... /bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 1.11.4
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... yes
> checking GDAL: /usr/share/gdal/pcs.csv readable... yes
> checking proj_api.h presence and usability... yes
> ./configure: line 2126: test: =: unary operator expected
> checking PROJ version >= 4.8.0... yes
> checking projects.h presence and usability... yes
> /tmp/ccnBOZCl.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2242: ./proj_conf_test2: No such file or directory
> checking PROJ.4: epsg found and readable... yes
> /tmp/ccu3xNdp.o: In function `main':
> /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
> collect2: error: ld returned 1 exit status
> ./configure: line 2301: ./proj_conf_test3: No such file or directory
> checking PROJ.4: conus found and readable... yes
> configure: Package CPP flags:  -I/usr/include/gdal
> configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
> configure: creating ./config.status
> config.status: creating src/Makevars
> ** libs
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
> gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
> ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
> ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
>     double DINT_MAX = 2251799813685248.0;
>            ^
> ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
>     double DINT_MIN = -2251799813685248.0;
>            ^
> g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
> g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
> installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
> ** R
> ** data
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
>  converting help for package 'rgdal'
>    finding HTML links ... done
>    CRS-class                               html
>    GDALDataset-class                       html
>    GDALDriver-class                        html
>    GDALMajorObject-class                   html
>    GDALRasterBand-class                    html
>    GDALReadOnlyDataset-class               html
>    GDALReadOnlyDataset-methods             html
>    GDALTransientDataset-class              html
>    GridsDatums                             html
>    RGB2PCT                                 html
>    SGDF2PCT                                html
>    SpatialGDAL-class                       html
>    closeDataset-methods                    html
>    displayDataset                          html
>    llgrid                                  html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
>    make_EPSG                               html
>    nor2k                                   html
>    projInfo                                html
>    project                                 html
>    readGDAL                                html
> Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
>    readOGR                                 html
>    showWKT                                 html
>    spTransform-methods                     html
>    wrappers                                html
>    writeOGR                                html
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
> unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
>  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'
>
> The downloaded source packages are in
>     '/tmp/RtmpXrQsj2/downloaded_packages'
> Warning message:
> In install.packages("rgdal") :
>  installation of package 'rgdal' had non-zero exit status
>
> I have tried several solutions but without any success.
>
> Have you any idea about the problem?
>
> Thanks in advance
> David
>
> [[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

RGDAL installation fail after yum upgrade

Fri, 09/21/2018 - 04:52
Dear list members,
I'm tring to install RGDAL on a cluster, but after the update of R packages seems not possible to install it.

Below the error message:

> install.packages("rgdal")
Installing package into '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5'
(as 'lib' is unspecified)
trying URL 'https://cran.stat.unipd.it/src/contrib/rgdal_1.3-4.tar.gz'
Content type 'application/octet-stream' length 1664774 bytes (1.6 MB)
==================================================
downloaded 1.6 MB

* installing *source* package 'rgdal' ...
** package 'rgdal' successfully unpacked and MD5 sums checked
configure: R_HOME: /usr/lib64/R
configure: CC: gcc -m64 -std=gnu99
configure: CXX: g++ -m64
configure: C++11 support available
configure: rgdal: 1.3-4
checking for /usr/bin/svnversion... yes
configure: svn revision: 766
checking for gdal-config... /bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 1.11.4
checking GDAL version >= 1.11.4... yes
checking gdal: linking with --libs only... yes
checking GDAL: /usr/share/gdal/pcs.csv readable... yes
checking proj_api.h presence and usability... yes
./configure: line 2126: test: =: unary operator expected
checking PROJ version >= 4.8.0... yes
checking projects.h presence and usability... yes
/tmp/ccnBOZCl.o: In function `main':
/tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test2.c:20: undefined reference to `pj_ctx_fclose'
collect2: error: ld returned 1 exit status
./configure: line 2242: ./proj_conf_test2: No such file or directory
checking PROJ.4: epsg found and readable... yes
/tmp/ccu3xNdp.o: In function `main':
/tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/proj_conf_test3.c:20: undefined reference to `pj_ctx_fclose'
collect2: error: ld returned 1 exit status
./configure: line 2301: ./proj_conf_test3: No such file or directory
checking PROJ.4: conus found and readable... yes
configure: Package CPP flags:  -I/usr/include/gdal
configure: Package LIBS:  -L/usr/lib64 -lgdal -lproj
configure: creating ./config.status
config.status: creating src/Makevars
** libs
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c OGR_write.cpp -o OGR_write.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c gdal-bindings.cpp -o gdal-bindings.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c init.c -o init.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c inverser.c -o inverser.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c local_stubs.c -o local_stubs.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_geom.cpp -o ogr_geom.o
gcc -m64 -std=gnu99 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c ogr_polygons.c -o ogr_polygons.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogr_proj.cpp -o ogr_proj.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrdrivers.cpp -o ogrdrivers.o
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c ogrsource.cpp -o ogrsource.o
ogrsource.cpp: In function 'SEXPREC* ogrReadListColumn(OGRLayer*, SEXP, int, int, int)':
ogrsource.cpp:651:12: warning: unused variable 'DINT_MAX' [-Wunused-variable]
     double DINT_MAX = 2251799813685248.0;
            ^
ogrsource.cpp:652:12: warning: unused variable 'DINT_MIN' [-Wunused-variable]
     double DINT_MIN = -2251799813685248.0;
            ^
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG -I/usr/include/gdal -I"/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/sp/include" -I/usr/local/include   -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -c projectit.cpp -o projectit.o
g++ -m64 -std=gnu++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o rgdal.so OGR_write.o gdal-bindings.o init.o inverser.o local_stubs.o ogr_geom.o ogr_polygons.o ogr_proj.o ogrdrivers.o ogrsource.o projectit.o -L/usr/lib64 -lgdal -lproj -L/usr/lib64/R/lib -lR
installing to /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs
** R
** data
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
  converting help for package 'rgdal'
    finding HTML links ... done
    CRS-class                               html
    GDALDataset-class                       html
    GDALDriver-class                        html
    GDALMajorObject-class                   html
    GDALRasterBand-class                    html
    GDALReadOnlyDataset-class               html
    GDALReadOnlyDataset-methods             html
    GDALTransientDataset-class              html
    GridsDatums                             html
    RGB2PCT                                 html
    SGDF2PCT                                html
    SpatialGDAL-class                       html
    closeDataset-methods                    html
    displayDataset                          html
    llgrid                                  html
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:11: file link 'Spatial' in package 'sp' does not exist and so has been treated as a topic
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:16: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/llgrid.Rd:17: file link 'gridat' in package 'sp' does not exist and so has been treated as a topic
    make_EPSG                               html
    nor2k                                   html
    projInfo                                html
    project                                 html
    readGDAL                                html
Rd warning: /tmp/RtmpCB1M7h/R.INSTALL2c944a1d5bee/rgdal/man/readGDAL.Rd:136: file link 'flipVertical' in package 'sp' does not exist and so has been treated as a topic
    readOGR                                 html
    showWKT                                 html
    spTransform-methods                     html
    wrappers                                html
    writeOGR                                html
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error: package or namespace load failed for 'rgdal' in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so':
  /home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal/libs/rgdal.so: undefined symbol: pj_ctx_fgets
Error: loading failed
Execution halted
ERROR: loading failed
* removing '/home/alfielo/R/x86_64-redhat-linux-gnu-library/3.5/rgdal'

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

I have tried several solutions but without any success.

Have you any idea about the problem?

Thanks in advance
David

        [[alternative HTML version deleted]]

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

Re: Consolidated SRS database/list?

Fri, 09/21/2018 - 02:32
On Thu, 20 Sep 2018, Vijay Lulla wrote:

> Ok, thanks!  While the page provided information about the project and its
> funding status I couldn't find the SQLite database.  Do you happen to know
> when this will be available?

No more than is on that page, plus the time needed to re-write plenty of
sf, lwgeom, rgdal and sp. At that stage, contributions welcome!

Roger

>
> On Thu, Sep 20, 2018 at 1:02 PM Roger Bivand <[hidden email]> wrote:
>
>> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>>
>>> Dear list members,
>>> A few years ago Roger Bivand posted a discussion (
>>> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html ) about
>>> consolidating SRS definitions into a SQLite database and I am wondering
>> if
>>> there has been any development along those lines.
>>
>> Rather than trying this just within R, we're hoping that the GDAL
>> barn-raising effort:
>>
>> https://gdalbarn.com/
>>
>> will take us there and further, and be much better than having a
>> non-standard implementation.
>>
>> When that effort is done, we'll be open for ideas about interfacing it
>> through PROJ and GDAL, which now ship with CSV files that we copy into
>> Windows and MacOS binary packages (rgdal, sf, lwgeom).
>>
>> For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file shipped
>> with PROJ into the R workspace as a data.frame.
>>
>> Roger
>>
>>> Specifically, is there any consolidated collection of SRS definitions in
>>> R (either a data.frame or tibble or SQLite backed) that are being used
>>> by geospatial packages that users can use too?  If so, can you please
>>> point me to it?  If not, would it be worthwhile to have this
>>> consolidated list/dataframe, maybe as part of data for one of the core
>>> geospatial packages? Thanks in advance, Vijay
>>>
>>>       [[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
>>
>
>
>
--
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: Consolidated SRS database/list?

Thu, 09/20/2018 - 15:47
Ok, thanks!  While the page provided information about the project and its
funding status I couldn't find the SQLite database.  Do you happen to know
when this will be available?

On Thu, Sep 20, 2018 at 1:02 PM Roger Bivand <[hidden email]> wrote:

> On Thu, 20 Sep 2018, Vijay Lulla wrote:
>
> > Dear list members,
> > A few years ago Roger Bivand posted a discussion (
> > https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html ) about
> > consolidating SRS definitions into a SQLite database and I am wondering
> if
> > there has been any development along those lines.
>
> Rather than trying this just within R, we're hoping that the GDAL
> barn-raising effort:
>
> https://gdalbarn.com/
>
> will take us there and further, and be much better than having a
> non-standard implementation.
>
> When that effort is done, we'll be open for ideas about interfacing it
> through PROJ and GDAL, which now ship with CSV files that we copy into
> Windows and MacOS binary packages (rgdal, sf, lwgeom).
>
> For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file shipped
> with PROJ into the R workspace as a data.frame.
>
> Roger
>
> > Specifically, is there any consolidated collection of SRS definitions in
> > R (either a data.frame or tibble or SQLite backed) that are being used
> > by geospatial packages that users can use too?  If so, can you please
> > point me to it?  If not, would it be worthwhile to have this
> > consolidated list/dataframe, maybe as part of data for one of the core
> > geospatial packages? Thanks in advance, Vijay
> >
> >       [[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
>

--
Vijay Lulla

Assistant Professor,
Dept. of Geography, IUPUI
425 University Blvd, CA-207C.
Indianapolis, IN-46202
[hidden email]
ORCID: https://orcid.org/0000-0002-0823-2522
Webpage: http://vijaylulla.com

        [[alternative HTML version deleted]]

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

Re: Library version mis-match [FIXED]

Thu, 09/20/2018 - 15:27
On Thu, 20 Sep 2018, Rich Shepard wrote:

> This might well be the issue. geos was upgraded from the summer's 3.6.3 to
> the very recent 3.7.0 and when I run weekly upgrades to installed
> Slackbuilds.org packages that was upgraded. I'll rebuild gdal and check that
> the issue is resolved.

   Fixed. Rebuilt/re-installed gdal-2.4.4 and rgdal re-installed without
problems.

Thanks again,

Rich

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

Re: Library version mis-match

Thu, 09/20/2018 - 13:47
On Thu, 20 Sep 2018, Roger Bivand wrote:

> No, this is the right list, but always include the output of sessionInfo(),
> and the startup messages shown by rgdal and rgeos when they are attached.

Roger,

   I'll include more information the next time I have an issue.

> How many other versions of gdal and/or geos do you have? It looks as though
> libgdal was built against libgeos-3.6.3, but you upgraded libgeos later,

   This might well be the issue. geos was upgraded from the summer's 3.6.3 to
the very recent 3.7.0 and when I run weekly upgrades to installed
Slackbuilds.org packages that was upgraded. I'll rebuild gdal and check that
the issue is resolved.

   Not long ago I did rebuild the sequence proj -> geos -> gdal -> grass and
the R upgrade might have missed that.

Many thanks,

Rich

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

Re: Library version mis-match

Thu, 09/20/2018 - 13:37
On Thu, 20 Sep 2018, Rich Shepard wrote:

>  If the r-help list is better suited for this question let me know and I'll
> move the thread there.

No, this is the right list, but always include the output of
sessionInfo(), and the startup messages shown by rgdal and rgeos when they
are attached.

>
>  Installed here are gdal-2.2.4 and geos-3.7.0
>

How many other versions of gdal and/or geos do you have? It looks as
though libgdal was built against libgeos-3.6.3, but you upgraded libgeos
later, removing that version. Easiest is having one version only, and
building everything in lockstep (PROJ and GEOS, then GDAL, then rgdal
and/or GRASS) and having only one version of each. Both rgdal and rgeos
may suffer from being installed with the versions shown by gdal-config and
geos-config, but finding different versions in the dynamic library load
path. I'm assuming you are neither on Windows nor MacOS - all this is
sorted out on CRAN in binary rgdal and rgeos (and sf) packages for those
platforms.

Hope this helps,

Roger

>  When I check installed libraries with library() both rgdal and rgeos are
> shown as being available:
>
> rgdal                   Bindings for the 'Geospatial' Data Abstraction
>                        Library
> rgeos                   Interface to Geometry Engine - Open Source
>                         ('GEOS')
>
>  However, when I try to use them in an operation with the sp() package the
> attempts fail. So I tried re-installing them. rgeos had no problem
> re-installing, but rgdal is not happy:
>
> ** testing if installed package can be loaded
> Error: package or namespace load failed for ?rgdal? in dyn.load(file, DLLpath
> = DLLpath, ...):
>  unable to load shared object '/usr/lib/R/library/rgdal/libs/rgdal.so':
>  libgeos-3.6.3.so: cannot open shared object file: No such file or directory
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing ?/usr/lib/R/library/rgdal?
> * restoring previous ?/usr/lib/R/library/rgdal?
>
> The downloaded source packages are in
> ?/tmp/Rtmp22EDOj/downloaded_packages?
> Updating HTML index of packages in '.Library'
> Making 'packages.html' ... done
> Warning message:
> In install.packages("rgdal") :
>   installation of package ?rgdal? had non-zero exit status
>
>  How can I resolve this by having R recognize, and use, geos-3.7.0? Or, do
> I need to downgrade geos to the earlier 3.6.3?
>
> Rich
>
> _______________________________________________
> 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

Library version mis-match

Thu, 09/20/2018 - 12:38
   If the r-help list is better suited for this question let me know and I'll
move the thread there.

   Installed here are gdal-2.2.4 and geos-3.7.0

   When I check installed libraries with library() both rgdal and rgeos are
shown as being available:

rgdal                   Bindings for the 'Geospatial' Data Abstraction
                         Library
rgeos                   Interface to Geometry Engine - Open Source
                         ('GEOS')

   However, when I try to use them in an operation with the sp() package the
attempts fail. So I tried re-installing them. rgeos had no problem
re-installing, but rgdal is not happy:

** testing if installed package can be loaded
Error: package or namespace load failed for ‘rgdal’ in dyn.load(file, DLLpath = DLLpath, ...):
  unable to load shared object '/usr/lib/R/library/rgdal/libs/rgdal.so':
   libgeos-3.6.3.so: cannot open shared object file: No such file or directory
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/lib/R/library/rgdal’
* restoring previous ‘/usr/lib/R/library/rgdal’

The downloaded source packages are in
  ‘/tmp/Rtmp22EDOj/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("rgdal") :
   installation of package ‘rgdal’ had non-zero exit status

   How can I resolve this by having R recognize, and use, geos-3.7.0? Or, do
I need to downgrade geos to the earlier 3.6.3?

Rich

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

Re: Consolidated SRS database/list?

Thu, 09/20/2018 - 12:01
On Thu, 20 Sep 2018, Vijay Lulla wrote:

> Dear list members,
> A few years ago Roger Bivand posted a discussion (
> https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html ) about
> consolidating SRS definitions into a SQLite database and I am wondering if
> there has been any development along those lines.

Rather than trying this just within R, we're hoping that the GDAL
barn-raising effort:

https://gdalbarn.com/

will take us there and further, and be much better than having a
non-standard implementation.

When that effort is done, we'll be open for ideas about interfacing it
through PROJ and GDAL, which now ship with CSV files that we copy into
Windows and MacOS binary packages (rgdal, sf, lwgeom).

For now, if it helps, rgdal::make_EPSG() reads the EPSG CSV file shipped
with PROJ into the R workspace as a data.frame.

Roger

> Specifically, is there any consolidated collection of SRS definitions in
> R (either a data.frame or tibble or SQLite backed) that are being used
> by geospatial packages that users can use too?  If so, can you please
> point me to it?  If not, would it be worthwhile to have this
> consolidated list/dataframe, maybe as part of data for one of the core
> geospatial packages? Thanks in advance, Vijay
>
> [[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

Consolidated SRS database/list?

Thu, 09/20/2018 - 11:33
Dear list members,
A few years ago Roger Bivand posted a discussion (
https://stat.ethz.ch/pipermail/r-sig-geo/2015-August/023204.html ) about
consolidating SRS definitions into a SQLite database and I am wondering if
there has been any development along those lines.  Specifically, is there
any consolidated collection of SRS definitions in R (either a data.frame or
tibble or SQLite backed) that are being used by geospatial packages that
users can use too?  If so, can you please point me to it?  If not, would it
be worthwhile to have this consolidated list/dataframe, maybe as part of
data for one of the core geospatial packages?
Thanks in advance,
Vijay

        [[alternative HTML version deleted]]

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

Re: Using CRS() method on SpatialPointDataFrame to project coordinates

Thu, 09/20/2018 - 10:31
On Thu, 20 Sep 2018, MacQueen, Don wrote:

> First, it looks like prcp_sites_ll does not have CRS information, because
> @projargs is NA.

Don,

   I used coordinates(prcp_sites_ll) <- c('easting','northing') to transform
the original dataframe to a SpatialPointsDataFrame and thought that because lat-lon
was not projected the @projards=NA was expected. Now I have learned that ...

> You'll need something like
>  proj4string(prcp_sites_ll) <- CRS('+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +towgs84=0,0,0')
or
>   CRS('+init=epsg:4326')

   I missed this step in my readings.

> Otherwise, your spTransform() command looks ok to me.

   Good to know.

> (have you come across spatialreference.org? I find it useful. Example
>   http://spatialreference.org/ref/epsg/wgs-84/)

   Yes. I frequently use that when working in GRASS since multiple agency
sources use different, and frequently undocumented, projectons on their
shapefiles.

Many thanks,

Rich

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

Re: Using CRS() method on SpatialPointDataFrame to project coordinates

Thu, 09/20/2018 - 10:05
First, it looks like prcp_sites_ll does not have CRS information, because @projargs is NA. You'll need something like

  proj4string(prcp_sites_ll) <- CRS('+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +towgs84=0,0,0')

That string may have more than is necessary; you could also try

   CRS('+init=epsg:4326')

Otherwise, your spTransform() command looks ok to me.

(have you come across spatialreference.org? I find it useful. Example
   http://spatialreference.org/ref/epsg/wgs-84/
)

-Don

--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509
 
 

On 9/20/18, 7:29 AM, "R-sig-Geo on behalf of Rich Shepard" <[hidden email] on behalf of [hidden email]> wrote:

       I have a SpatialPointsDataFrame with geographic coordinates:
   
    #> str(prcp_sites_ll)
    Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
       ..@ data       :'data.frame': 58 obs. of  3 variables:
       .. ..$ name     : Factor w/ 58 levels "Blazed Alder",..: 1 2 3 4 5 6 7 8 9 10 ...
       .. ..$ elev     : num [1:58] 1112.5 159.1 162.2 45.4 57.3 ...
       .. ..$ mean_prcp: num [1:58] 0.362 0.155 0.16 0.12 0.128 ...
       ..@ coords.nrs : int [1:2] 2 3
       ..@ coords     : num [1:58, 1:2] -122 -122 -122 -123 -123 ...
       .. ..- attr(*, "dimnames")=List of 2
       .. .. ..$ : NULL
       .. .. ..$ : chr [1:2] "easting" "northing"
       ..@ bbox       : num [1:2, 1:2] -122.8 45 -121.7 45.5
       .. ..- attr(*, "dimnames")=List of 2
       .. .. ..$ : chr [1:2] "easting" "northing"
       .. .. ..$ : chr [1:2] "min" "max"
       ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
       .. .. ..@ projargs: chr NA
   
    and I want to project this using CRS('+init=epsg:2838') to a new SPDF
    called prcp_sites_lcc.
   
       I think the proper syntax would be:
   
    prcp_sites_lcc <- spTransform(prcp_sites_ll,CRS('+init=epsg:2838'))
   
       Is this correct?
   
    Regards,
   
    Rich
   
    _______________________________________________
    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

Using CRS() method on SpatialPointDataFrame to project coordinates

Thu, 09/20/2018 - 09:29
   I have a SpatialPointsDataFrame with geographic coordinates:

#> str(prcp_sites_ll)
Formal class 'SpatialPointsDataFrame' [package "sp"] with 5 slots
   ..@ data       :'data.frame': 58 obs. of  3 variables:
   .. ..$ name     : Factor w/ 58 levels "Blazed Alder",..: 1 2 3 4 5 6 7 8 9 10 ...
   .. ..$ elev     : num [1:58] 1112.5 159.1 162.2 45.4 57.3 ...
   .. ..$ mean_prcp: num [1:58] 0.362 0.155 0.16 0.12 0.128 ...
   ..@ coords.nrs : int [1:2] 2 3
   ..@ coords     : num [1:58, 1:2] -122 -122 -122 -123 -123 ...
   .. ..- attr(*, "dimnames")=List of 2
   .. .. ..$ : NULL
   .. .. ..$ : chr [1:2] "easting" "northing"
   ..@ bbox       : num [1:2, 1:2] -122.8 45 -121.7 45.5
   .. ..- attr(*, "dimnames")=List of 2
   .. .. ..$ : chr [1:2] "easting" "northing"
   .. .. ..$ : chr [1:2] "min" "max"
   ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot
   .. .. ..@ projargs: chr NA

and I want to project this using CRS('+init=epsg:2838') to a new SPDF
called prcp_sites_lcc.

   I think the proper syntax would be:

prcp_sites_lcc <- spTransform(prcp_sites_ll,CRS('+init=epsg:2838'))

   Is this correct?

Regards,

Rich

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

Re: Leaflet map nested in RShiny App - Improving speed & portability

Thu, 09/20/2018 - 07:16
Apologies- looks like that only supports raster tiles, as does the R
package 'tiler'.

Sorry for the multiple messages on this.
Cheers,
Mike

Please pardon any typos, this message was sent from a mobile device.

On Wed, Sep 5, 2018, 2:04 PM Michael Treglia <[hidden email]> wrote:

> I'll just second Barry's idea in particular, to set up as a standalone
> webpage. You could even use QGIS and the QGIS2Web Plugin to create that,
> and host via GitHub pages or similar.
>
> From R, after creating a map via leaflet and similar packages, you can use
> htmlwidgets::saveWidget() to export as a standalone .html file if I recall
> correctly.
>
> The one thing regarding a standalone webpage is that if you have a lot of
> objects (especially complex ones), that can be a lot for a browser to
> handle (given the data are part of the html file).  Might be worth some
> quick experimentation, and simplifying polygons would help. (You could
> always create a quick landing page, even generated via rMarkdown, and
> having a link for maps by different regions or countries - then you could
> have a folder of .html files you could distribute, and users could just
> open the landing page, and navigate from there).
>
> Just some quick thoughts... Hope this helps.
> Mike T
>
> On Wed, Sep 5, 2018 at 1:17 PM Erin Stearns <[hidden email]> wrote:
>
>> Hello all,
>>
>> Thank you all very much for the great insight!
>>
>> *McCrea *- thank you very much, I will test using a geojson first, then
>> test after reducing geometry.
>>
>> *Tim* - thank you for the great breakdown and recommended priority list.
>> Ideally, I would like to be able to share the interactive map with
>> teammates as a file or something akin to it such that they can simply open
>> it and interact with the map. RInno is a great option, however I run a
>> linux machine, so will look into further, but may need to find another
>> option.
>>
>> *Roman* - the app is currently deployed to shinyapps.io. Thank you for
>> sharing about ShinyProxy -- so would this method require 1. Internet and
>> 2.
>> local installation (vs internal server)?
>>
>> *Barry* - wow, thank you for your response! Sounds like this would be the
>> best way to solve both issues. I am not as fluent with HTML and JS, but as
>> you say, there are likely great guides available to take this route.
>>
>> Thank you all again, this has been hugely helpful. I wish you all the best
>> and hope I can be of help to you at some point!
>>
>> Best,
>> Erin
>>
>>
>> On Wed, Sep 5, 2018 at 12:48 AM Barry Rowlingson <
>> [hidden email]> wrote:
>>
>> >
>> >
>> > On Wed, Sep 5, 2018 at 12:56 AM, Erin Stearns <[hidden email]>
>> > wrote:
>> >
>> >> Hello all!
>> >>
>> >> I hope this message finds you all well!
>> >>
>> >> I have 2 questions pertaining to the creation of interactive maps via
>> >> Leaflet nested inside an RShiny app. One question has to do with
>> >> computation while the other has to do with sharing/off-line
>> interactivity.
>> >>
>> >> *Computation question*
>> >> As you see, the RShiny app takes quite a bit of time to render. Does
>> >> anyone
>> >> have any suggestions for improving this? As previously said, this
>> version
>> >> only contains 5 countries, thus I cannot continue with my current
>> method
>> >> to
>> >> reach a global map. I have considered finding centroids of all Admin 2
>> >> polygons and retaining attribute information here, then rasterizing the
>> >> malaria risk shapefile for visualization and using the 2 instead of a
>> >> single shapefile with polygon boundaries and attributes.
>> >>
>> >>
>> > Unless you plan to add any computational functions to this map then I'd
>> > strongly recommend creating it as a standalone web app and not a shiny
>> app.
>> > This will enable you to use lots of useful Leaflet plugins for speeding
>> > things up, such as only showing country outlines at low zoom levels, and
>> > showing subdivisions only at high zoom levels. This *might* be possible
>> > with R's various leaflet packages but I'd go for full javascript
>> control.
>> >
>> > A standalone map would take its data from a JSON file or similar, and
>> you
>> > would then be writing R code that generated that. The mapping app
>> itself is
>> > written in HTML and JS with CSS styling. There are plenty of guides to
>> > web-based interactive mapping, starting with Leaflet.
>> >
>> >
>> >> *Sharing the app/offline interactivity*
>> >> I am planning to share this with people who likely do not have R
>> installed
>> >> on their laptops nor have they ever coded. Does anyone have any
>> >> suggestions
>> >> for the best way to do this while retaining interactivity?
>> >>
>> >>  Here's the big win of creating a standalone web map. You only have to
>> > distribute the HTML/CSS/JS and they can be viewed directly (or you also
>> > supply a tiny server that runs locally and only has to feed the files
>> on a
>> > localhost port). No need to have a shiny server anywhere, or install R.
>> Its
>> > simple and clean. It also needs no network connectivity, but you'll not
>> get
>> > a base map - but you could include a low or medium resolution basemap
>> > raster in your package.
>> >
>> > The only reason to need Shiny here would be if you wanted people to do
>> > something computational, like click on a bunch of polygons and then fit
>> a
>> > linear model to the selection, since that would require a round-trip to
>> the
>> > server for R to compute the fit. (although I suspect there's a JS
>> package
>> > for linear modelling.... you can do ML in JS these days...)
>> >
>> >
>> >
>> >> Thank you all, any insight is greatly appreciated.
>> >>
>> >> Best,
>> >> Erin
>> >>
>> >>         [[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
>>
>
        [[alternative HTML version deleted]]

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

Re: Leaflet map nested in RShiny App - Improving speed & portability

Thu, 09/20/2018 - 07:05
As a quick follow up, I just came across this blog post on serving up map
tiles via a GitHub repository, generating tiles via a QGIS plugin.
https://khufkens.com/2018/09/19/github-tile-server/

Not an R solution, but perhaps something that might help in a case like
this.  As explained, the solution would still require an internet
connection, but would otherwise be a lot l lighter than having a ton of
polygons in a single webpage.

Please pardon any typos, this message was sent from a mobile device.

On Wed, Sep 12, 2018, 2:27 PM <[hidden email]> wrote:

> Hey Erin,
>
> I agree with everybody who answered, but just for completeness and FYI:
>
> Another approach for sharing a Shiny app offline as a (Windows) Desktop
> app might be using Shiny with "R portable".
>
> For further details please check for example:
> https://www.r-bloggers.com/deploying-desktop-apps-with-r/
>
> Cheers!
>
> Harry
>
> Ps. If anybody thinks this is a very bad idea, please let me know,
> because I'm planing to develop something like that ... Thanks!
>
>
> Am 05.09.2018 um 01:56 schrieb Erin Stearns:
> > Hello all!
> >
> > I hope this message finds you all well!
> >
> > I have 2 questions pertaining to the creation of interactive maps via
> > Leaflet nested inside an RShiny app. One question has to do with
> > computation while the other has to do with sharing/off-line
> interactivity.
> >
> > *Project description:*
> > I am creating a global map depicting binary malaria risk (at risk, not at
> > risk) at the Admin 2 level(current state only uses 5 countries and can be
> > found here <https://erstearns.shinyapps.io/malariarisk5/>).  I am using
> an
> > ESRI base map, then a polygons shapefile containing geometry and
> attributes
> > (geographical hierarchy & risk).
> >
> > *Computation question*
> > As you see, the RShiny app takes quite a bit of time to render. Does
> anyone
> > have any suggestions for improving this? As previously said, this version
> > only contains 5 countries, thus I cannot continue with my current method
> to
> > reach a global map. I have considered finding centroids of all Admin 2
> > polygons and retaining attribute information here, then rasterizing the
> > malaria risk shapefile for visualization and using the 2 instead of a
> > single shapefile with polygon boundaries and attributes.
> >
> > *Sharing the app/offline interactivity*
> > I am planning to share this with people who likely do not have R
> installed
> > on their laptops nor have they ever coded. Does anyone have any
> suggestions
> > for the best way to do this while retaining interactivity?
> >
> > Thank you all, any insight is greatly appreciated.
> >
> > Best,
> > Erin
> >
> >       [[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
>
        [[alternative HTML version deleted]]

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

Re: Subsetting dataframe by all factor levels

Sun, 09/16/2018 - 19:30
On Sun, 16 Sep 2018, Gabriel Gaona wrote:

> An other option is the tydiverse way. I assume when you say " My goal is to
> use the monthly mean rainfall at each of the 58 reporting stations..." you
> mean you want for each year and station a average value of monthly prcp .
>> From your input data frame, is like:
>
> library(dplyr)
> library(lubridate)
> rainfall_yearly <- rainfall %>%
>    group_by(name,
>        Month = floor_date(sampdate, "month")) %>% #Monthly round down
> dates for grouping
>    summarise(prcp = sum(prcp, na.rm = TRUE) %>% #calculating monthly prcp
>    group_by(name,
>        Year = floor_date(Month, "year")) %>% #Yearly round down dates for
> grouping
>    summarise(prcp = mean(prcp, na.rm = TRUE) #calculating monthly average
> per year
Gabriel,

   Thank you very much I'm learning a lot from all the responses.

Best regards,

Rich

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

Re: Subsetting dataframe by all factor levels

Sun, 09/16/2018 - 19:15
An other option is the tydiverse way. I assume when you say " My goal is to
use the monthly mean rainfall at each of the 58 reporting stations..." you
mean you want for each year and station a average value of monthly prcp .
From your input data frame, is like:

library(dplyr)
library(lubridate)
rainfall_yearly <- rainfall %>%
    group_by(name,
        Month = floor_date(sampdate, "month")) %>% #Monthly round down
dates for grouping
    summarise(prcp = sum(prcp, na.rm = TRUE) %>% #calculating monthly prcp
    group_by(name,
        Year = floor_date(Month, "year")) %>% #Yearly round down dates for
grouping
    summarise(prcp = mean(prcp, na.rm = TRUE) #calculating monthly average
per year
_________________________
* Gabriel Gaona*
*Teléfono*: +593 9 91665888
*Twitter/Hangouts*: gavg712
Loja - Ecuador
https://www.researchgate.net/profile/Gabriel_Gaona


El vie., 14 sept. 2018 a las 17:54, Rich Shepard (<[hidden email]>)
escribió:

> On Fri, 14 Sep 2018, Justin H. wrote:
>
> > I'm not sure how it handles your date format. It's probably grouping
> > things weirdly. If you can split out that column into two columns, one
> for
> > year and one for month. I'd have to tinker with it later as I can't think
> > of code off the top of my head. It should play nicer then.
>
> Justin,
>
>    The rainfall data.frame structure:
> 'data.frame':   113569 obs. of  6 variables:
>   $ name    : Factor w/ 58 levels "Blazed Alder",..: 20 20 20 20 20 20 20
> 20 ...
>   $ easting : num  2370575 2370575 2370575 2370575 2370575 ...
>   $ northing: num  199338 199338 199338 199338 199338 ...
>   $ elev    : num  228 228 228 228 228 228 228 228 228 228 ...
>   $ sampdate: Date, format: "2005-01-01" "2005-01-02" ...
>   $ prcp    : num  0.59 0.08 0.1 0 0 0.02 0.05 0.1 0 0.02 ...
>
> After splitting by name (only the first one shown):
> str(rainfall_by_site)
> List of 58
>   $ Blazed Alder                 :'data.frame':      4900 obs. of  6
> variables:
>    ..$ name    : Factor w/ 58 levels "Blazed Alder",..: 1 1 1 1 1 1 1 1 1
> 1 ...
>    ..$ easting : num [1:4900] 2393589 2393589 2393589 2393589 2393589 ...
>    ..$ northing: num [1:4900] 196841 196841 196841 196841 196841 ...
>    ..$ elev    : num [1:4900] 1112 1112 1112 1112 1112 ...
>    ..$ sampdate: Date[1:4900], format: "2005-01-01" "2005-01-02" ...
>    ..$ prcp    : num [1:4900] 0.2 0.2 0.4 0 0 0 0.1 0.1 0.1 0.2 ...
>
> Adding a year column to the end:
>      $ year    : num  0 0 0 0 0 0 0 0 0 0 ...
>
> I've not separated the sampdate structure into years and months; I can and
> that might make the difference. Will try to find time this weekend to do
> so.
> Otherwise, it'll be next week.
>
> Regards,
>
> Rich
>
> _______________________________________________
> 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

Pages