Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

And I'm very grateful for Robin's
https://bookdown.org/robinlovelace/geocompr/intro.html, because at this
point my lazy days
of rstudio are broken and his book provides a very helpful and informative
re-introduction to accomplishing what I need from
the command line. Roy, did permissions figure in your difficulties or was
that an ubuntu based herring whose checking bore no
fruit?
Chris

On Sat, May 30, 2020 at 4:02 PM Roy Mendelssohn - NOAA Federal via
R-sig-Geo  wrote:

>
>
> > On May 30, 2020, at 12:40 PM, Robin Lovelace  wrote:
> >
> > I should say huge thanks to Roger and other developers in the community
> for
> > amazing work keeping track of rapidly changing upstream dependencies.
> It's
> > a small miracle that R can be used as a powerful geographic data
> processing
> > tool, with a vast array of statistical functionality a few keystrokes
> away.
> > Hope sharing my experience is useful.
>
> -Ditto.  I am just interested in seeing if I can get it to work.  It is
> not always possible for developers to have every OS right at hand to
> develop and test on. It helped in my case to get version 1.59,  and I since
> things were in non-standard places I had to set those.
>
> -Roy
>
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

Roy,

I'm not OSX but generally I see them as conceptually similar and where I
have stumbled (at what appears to be 'this stage') is in permissions so I
would check the 'geneaology' of permissions and your ownership there upon
the entire path of permissions that allows dynlib to execute
comprehensively. And as you pass the rgdal hurdle so the same for gdal,
geos. As applies to OSX, this may appear as voodoo, but if there is a sudo
analog in OSX, try it. My voodoo (that is possibly disconcerting to those
who view computers as logical systems. I would have advocated base 3 were I
there at the beginning...)

Chris

On Sat, May 30, 2020 at 2:12 PM Roy Mendelssohn - NOAA Federal via
R-sig-Geo  wrote:

> Hi All:
>
> Okay after some fiddling I was able to get it to sort of successfully
> compile,  where I am having problems is in finding the dynamic libraries,
> such as I get this error:
>
> > dyld: Library not loaded: @rpath/libproj.19.dylib
>
> and
>
> > Error: package or namespace load failed for ‘rgdal’ in dyn.load(file,
> DLLpath = DLLpath, ...):
> >  unable to load shared object
> '/Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so':
> >
>  
> dlopen(/Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so,
> 6): Library not loaded: @rpath/libgdal.26.dylib
> >   Referenced from:
> /Users/rmendels/Library/R/4.0/library/00LOCK-rgdal/00new/rgdal/libs/rgdal.so
> >   Reason: image not found
> > Error: loading failed
>
> It has to do with these are defined in terms of @rpath.  I thought
> defining this in $LD_LIBRARY_PATH would do it,  but I have:
>
> > echo $LD_LIBRARY_PATH
> > /Users/rmendels/Library/R/4.0/library:/Users/rmendels/anaconda3/lib
>
> I also tried setting$DYLD_LIBRARY_PATH same problem.  If someone can
> tell me how to set it so @rpath finds the dynamic libraries I might be able
> to get this to work.
>
> Thanks,
>
> -Roy
>
>
>
> > On May 30, 2020, at 8:04 AM, chris english <
> englishchristoph...@gmail.com> wrote:
> >
> > my setup - albeit on 20.04 as reported by sf
> >
> > > library(sf)
> > Linking to GEOS 3.9.0dev, GDAL 3.1.0, PROJ 7.0.1
> >
> > Note I'm using release gdal, that I none the less built from source as I
> had to enable Mr. Sid for some particular
> >  data. Couldn't get GDAL 3.2.*dev working but still toying around with
> it. Roger's discussion of the history of all
> > of this on r-spatial and the path forward is very much worth the read as
> and relates to his following message here.
> >
> >
> >
> > On Sat, May 30, 2020 at 10:33 AM Roy Mendelssohn - NOAA Federal <
> roy.mendelss...@noaa.gov> wrote:
> > Yes thanks.  As I said in reply to Roger I am far from an expert in
> these things,  but if I can get it to build,  then I will try to post
> somewhere for others to use.
> >
> > -Roy
> >
> > > On May 30, 2020, at 7:03 AM, chris english <
> englishchristoph...@gmail.com> wrote:
> > >
> > > Roy,
> > > From a related prior post Roger shared this link to rgdal-1.5-9,
> http://spatial.nhh.no/R/rgdal/ . I followed discussions
> > > from the 'sf' github readme and purged all prior proj/geos/gdal
> iterations that have lingered around over the past five
> > > years and built them from source on ubuntu 20.04. This upgrade to
> 20.04 was perhaps my first mistake in a month
> > > long effort to bring back my full spatial capabilities as it doesn't
> become the official LTS until sometime mid this month.
> > > I don't know how Anaconda packages and may require sym links or
> copying files from down in the depths to visible,
> > > but it worked before and can be made to work again.
> > > HTH-
> > > Chris
> > >
> > > On Sat, May 30, 2020 at 8:08 AM Roger Bivand 
> wrote:
> > > On Fri, 29 May 2020, Thiago V. dos Santos wrote:
> > >
> > > > Dear Roger,
> > > >
> > > > Many thanks for the effort keeping rgdal up-to-date with proj6.
> > > >
> > > > I'd like to report that I am unable to install rgdal 1.5.8 on my
> macOS
> > > > system. I am reporting this error here on the list because I thought
> it
> > > > would be the best channel in terms of reaching future users
> experiencing
> > > > the same error. Please apologize if my rationale is not right, and
> > > > ignore this message.
> > > >
> > > > GDAL was installed via MacPorts and is at its latest version, 3.1.0
> (at
> > > > the time of this writing). Proj6 has also been installed via
> Macports.

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

my setup - albeit on 20.04 as reported by sf

> library(sf)
Linking to GEOS 3.9.0dev, GDAL 3.1.0, PROJ 7.0.1

Note I'm using release gdal, that I none the less built from source as I
had to enable Mr. Sid for some particular
 data. Couldn't get GDAL 3.2.*dev working but still toying around with it.
Roger's discussion of the history of all
of this on r-spatial and the path forward is very much worth the read as
and relates to his following message here.



On Sat, May 30, 2020 at 10:33 AM Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> Yes thanks.  As I said in reply to Roger I am far from an expert in these
> things,  but if I can get it to build,  then I will try to post somewhere
> for others to use.
>
> -Roy
>
> > On May 30, 2020, at 7:03 AM, chris english <
> englishchristoph...@gmail.com> wrote:
> >
> > Roy,
> > From a related prior post Roger shared this link to rgdal-1.5-9,
> http://spatial.nhh.no/R/rgdal/ . I followed discussions
> > from the 'sf' github readme and purged all prior proj/geos/gdal
> iterations that have lingered around over the past five
> > years and built them from source on ubuntu 20.04. This upgrade to 20.04
> was perhaps my first mistake in a month
> > long effort to bring back my full spatial capabilities as it doesn't
> become the official LTS until sometime mid this month.
> > I don't know how Anaconda packages and may require sym links or copying
> files from down in the depths to visible,
> > but it worked before and can be made to work again.
> > HTH-
> > Chris
> >
> > On Sat, May 30, 2020 at 8:08 AM Roger Bivand 
> wrote:
> > On Fri, 29 May 2020, Thiago V. dos Santos wrote:
> >
> > > Dear Roger,
> > >
> > > Many thanks for the effort keeping rgdal up-to-date with proj6.
> > >
> > > I'd like to report that I am unable to install rgdal 1.5.8 on my macOS
> > > system. I am reporting this error here on the list because I thought
> it
> > > would be the best channel in terms of reaching future users
> experiencing
> > > the same error. Please apologize if my rationale is not right, and
> > > ignore this message.
> > >
> > > GDAL was installed via MacPorts and is at its latest version, 3.1.0
> (at
> > > the time of this writing). Proj6 has also been installed via Macports.
> > >
> > > This is how I am trying to install it:
> > >
> > > export PKG_CONFIG_PATH=/opt/local/lib/proj6/lib/pkgconfig
> > > R
> > > install.packages('rgdal', type="source", configure.args=c(
> > >  '--with-proj-include=/opt/local/lib/proj6/include',
> > >  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> > >
> > > and this is the output I get:
> > >
> > > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > > Copyright (C) 2020 The R Foundation for Statistical Computing
> > > Platform: x86_64-apple-darwin17.0 (64-bit)
> > >
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under certain conditions.
> > > Type 'license()' or 'licence()' for distribution details.
> > >
> > >
> > >   Natural language support but running in an English locale
> > >
> > >
> > > R is a collaborative project with many contributors.
> > > Type 'contributors()' for more information and
> > > 'citation()' on how to cite R or R packages in publications.
> > >
> > >
> > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > 'help.start()' for an HTML browser interface to help.
> > > Type 'q()' to quit R.
> > >
> > >
> > >> install.packages('rgdal', type="source", configure.args=c(
> > > +  '--with-proj-include=/opt/local/lib/proj6/include',
> > > +  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> > > Installing package into ‘/Users/thiago/Documents/R-packages’
> > > (as ‘lib’ is unspecified)
> > >
> > >
> > > trying URL '
> https://cran.r-project.org/src/contrib/rgdal_1.5-8.tar.gz'
> > > Content type 'application/x-gzip' length 2299235 bytes (2.2 MB)
> > > ==
> > > downloaded 2.2 MB
> > >
> > >
> > > * installing *source* package ‘rgdal’ ...
> > > ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> > > ** using staged installation
> > > configure: R_HOME: /Library/Frameworks/R.framework/Resources
> > > configure: CC

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

Roy,
>From a related prior post Roger shared this link to rgdal-1.5-9,
http://spatial.nhh.no/R/rgdal/ . I followed discussions
from the 'sf' github readme and purged all prior proj/geos/gdal iterations
that have lingered around over the past five
years and built them from source on ubuntu 20.04. This upgrade to 20.04 was
perhaps my first mistake in a month
long effort to bring back my full spatial capabilities as it doesn't become
the official LTS until sometime mid this month.
I don't know how Anaconda packages and may require sym links or copying
files from down in the depths to visible,
but it worked before and can be made to work again.
HTH-
Chris

On Sat, May 30, 2020 at 8:08 AM Roger Bivand  wrote:

> On Fri, 29 May 2020, Thiago V. dos Santos wrote:
>
> > Dear Roger,
> >
> > Many thanks for the effort keeping rgdal up-to-date with proj6.
> >
> > I'd like to report that I am unable to install rgdal 1.5.8 on my macOS
> > system. I am reporting this error here on the list because I thought it
> > would be the best channel in terms of reaching future users experiencing
> > the same error. Please apologize if my rationale is not right, and
> > ignore this message.
> >
> > GDAL was installed via MacPorts and is at its latest version, 3.1.0 (at
> > the time of this writing). Proj6 has also been installed via Macports.
> >
> > This is how I am trying to install it:
> >
> > export PKG_CONFIG_PATH=/opt/local/lib/proj6/lib/pkgconfig
> > R
> > install.packages('rgdal', type="source", configure.args=c(
> >  '--with-proj-include=/opt/local/lib/proj6/include',
> >  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> >
> > and this is the output I get:
> >
> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-apple-darwin17.0 (64-bit)
> >
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> >
> >   Natural language support but running in an English locale
> >
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> >
> >> install.packages('rgdal', type="source", configure.args=c(
> > +  '--with-proj-include=/opt/local/lib/proj6/include',
> > +  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> > Installing package into ‘/Users/thiago/Documents/R-packages’
> > (as ‘lib’ is unspecified)
> >
> >
> > trying URL '
> https://cran.r-project.org/src/contrib/rgdal_1.5-8.tar.gz'
> > Content type 'application/x-gzip' length 2299235 bytes (2.2 MB)
> > ==
> > downloaded 2.2 MB
> >
> >
> > * installing *source* package ‘rgdal’ ...
> > ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> > ** using staged installation
> > configure: R_HOME: /Library/Frameworks/R.framework/Resources
> > configure: CC: /opt/local/bin/gcc
> > configure: CXX: /opt/local/bin/g++
> > configure: C++11 support available
> > configure: rgdal: 1.5-8
> > checking for /usr/bin/svnversion... yes
> > configure: svn revision: 990
> > checking for gdal-config... /opt/local/bin/gdal-config
> > checking gdal-config usability... yes
> > configure: GDAL: 3.1.0
> > checking GDAL version >= 1.11.4... yes
> > checking GDAL version <= 2.5 or >= 3.0... yes
> > checking gdal: linking with --libs only... yes
> > checking GDAL: gdal-config data directory readable... yes
> > checking GDAL: /opt/local/share/gdal/stateplane.csv readable... yes
> > configure: pkg-config proj exists, will use it
>
> So far so good, but you chose to override pkg-config proj by passing
> configure arguments. You should let pkg-config proj provide those values.
>
> > configure: PROJ version: 6.3.2
> > configure: proj CPP flags: -DPROJ_H_API -I/opt/local/lib/proj6/include
> > configure: PROJ LIBS: -L/opt/local/lib/proj6/lib
> > checking PROJ header API:... proj.h
> > checking for gcc... /opt/local/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 /opt/local/bin/gcc accepts -g... yes
> > checking for /opt/local/bin/gcc option to accept ISO C89... none needed
> > checking how to run the C preprocessor... /opt/local/bin/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... rm: conftest.dSYM: is a directory
> > rm: conftest.dSYM: is a directory
> > 

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

My problems of install of sf and dependencies were fixed by rgdal-1.5-9 and
additionally
upgrading lwgeom and all other dependencies. Thank you all for your efforts
and I am
in ubuntu 20.04.

On Fri, May 29, 2020 at 5:57 PM chris english 
wrote:

> And not desiring to muddy Thiago's clear waters, but when is Proj7*
> transition expected?
>
> Chris
>
> On Fri, May 29, 2020 at 5:46 PM Roy Mendelssohn - NOAA Federal via
> R-sig-Geo  wrote:
>
>> I just tried using the Anaconda setup  Mine dies on not being able to
>> find “projects.h”.
>>
>> > inverser.c:5:10: fatal error: 'projects.h' file not found
>> > #include 
>> >  ^~~~
>>
>>
>> Doing internet searches,  for PROJ6 and beyond,  this was made private,
>> and is not suppose to be for public linking, see:
>>
>> https://github.com/OSGeo/PROJ/issues/835 <
>> https://github.com/OSGeo/PROJ/issues/835>
>> https://code.mpimet.mpg.de/boards/1/topics/1184 <
>> https://code.mpimet.mpg.de/boards/1/topics/1184>
>>
>> The discussion in the second one suggests that it should be linking to
>> the public header proj_api.h rather than the private header projects.h.
>> proj_api.h does exist in the installation I have.  Unless there is an easy
>> fix I can do,  more than I want to mess with.
>>
>> -Roy
>>
>>
>>
>> > On May 29, 2020, at 2:25 PM, Thiago V. dos Santos via R-sig-Geo <
>> r-sig-geo@r-project.org> wrote:
>> >
>> > Dear Roger,
>> >
>> > Many thanks for the effort keeping rgdal up-to-date with proj6.
>> >
>> > I'd like to report that I am unable to install rgdal 1.5.8 on my macOS
>> system. I am reporting this error here on the list because I thought it
>> would be the best channel in terms of reaching future users experiencing
>> the same error. Please apologize if my rationale is not right, and ignore
>> this message.
>> >
>> > GDAL was installed via MacPorts and is at its latest version, 3.1.0 (at
>> the time of this writing). Proj6 has also been installed via Macports.
>> >
>> > This is how I am trying to install it:
>> >
>> > export PKG_CONFIG_PATH=/opt/local/lib/proj6/lib/pkgconfig
>> > R
>> > install.packages('rgdal', type="source", configure.args=c(
>> >  '--with-proj-include=/opt/local/lib/proj6/include',
>> >  '--with-proj-lib=/opt/local/lib/proj6/lib'))
>> >
>> > and this is the output I get:
>> >
>> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
>> > Copyright (C) 2020 The R Foundation for Statistical Computing
>> > Platform: x86_64-apple-darwin17.0 (64-bit)
>> >
>> >
>> > R is free software and comes with ABSOLUTELY NO WARRANTY.
>> > You are welcome to redistribute it under certain conditions.
>> > Type 'license()' or 'licence()' for distribution details.
>> >
>> >
>> >   Natural language support but running in an English locale
>> >
>> >
>> > R is a collaborative project with many contributors.
>> > Type 'contributors()' for more information and
>> > 'citation()' on how to cite R or R packages in publications.
>> >
>> >
>> > Type 'demo()' for some demos, 'help()' for on-line help, or
>> > 'help.start()' for an HTML browser interface to help.
>> > Type 'q()' to quit R.
>> >
>> >
>> >> install.packages('rgdal', type="source", configure.args=c(
>> > +  '--with-proj-include=/opt/local/lib/proj6/include',
>> > +  '--with-proj-lib=/opt/local/lib/proj6/lib'))
>> > Installing package into ‘/Users/thiago/Documents/R-packages’
>> > (as ‘lib’ is unspecified)
>> >
>> >
>> > trying URL '
>> https://cran.r-project.org/src/contrib/rgdal_1.5-8.tar.gz'
>> > Content type 'application/x-gzip' length 2299235 bytes (2.2 MB)
>> > ==
>> > downloaded 2.2 MB
>> >
>> >
>> > * installing *source* package ‘rgdal’ ...
>> > ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>> > ** using staged installation
>> > configure: R_HOME: /Library/Frameworks/R.framework/Resources
>> > configure: CC: /opt/local/bin/gcc
>> > configure: CXX: /opt/local/bin/g++
>> > configure: C++11 support available
>> > configure: rgdal: 1.5-8
>> > checking for /usr/bin/svnversion... yes
>> > configure: svn revision: 990
>> > checking for gdal-confi

Re: [R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition

[chris english]

rgdal-1.5-9 fixed all my install problems on ubuntu 20.04. My mother has a
needle point pillow at her summer home
which declares "Guests of Guests May Not Bring Guests". Analogously,
'dependencies of dependencies will not
check dependencies' is applicable here. rgdal-1.5-9 facilitated:

> library(rgdal)
Loading required package: sp
rgdal: version: 1.5-9, (SVN revision 991M)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.1.0, released 2020/05/03
Path to GDAL shared files: /usr/local/share/gdal
GDAL binary built with GEOS: TRUE
Loaded PROJ runtime: Rel. 7.0.1, May 1st, 2020, [PJ_VERSION: 701]
Path to PROJ shared files:
/root/.local/share/proj:/usr/local/share/proj:/usr/local/share/proj
PROJ CDN enabled:FALSE
Linking to sp version:1.4-1
To mute warnings of possible GDAL/OSR exportToProj4() degradation,
use options("rgdal_show_exportToProj4_warnings"="none") before loading
rgdal.

GEOS version is 3.9.0dev

I still have some work to do on the PostgreSQL end of things, but I am back
to working
spatial. I still received errors unless I started the Install session in
sudo R, which leads me
to think that my /usr/local/(bin,lib,include) are symlinks from
one/some/all installs of GEOS,
PROJ, GDAL, which are not the fault of R developers, but I'd forgotten this
issue and rediscovered
that I pestered Roger and Edzer about it in 2019. So, sudo R.

I'm back to having a working spatial environment. Thank you Roger!

Chris

On Fri, May 29, 2020 at 5:16 PM Roy Mendelssohn - NOAA Federal via
R-sig-Geo  wrote:

> Hi All:
>
> It appears that Anaconda has the requisite versions,  as well as
> gdal-config and the appropriate include files etc etc,  though I haven’t
> tried to compile yet,  as I have to be on a different computer. So I have
> two questions for now:
>
> 1.  Other than the rgdal source and setting everything to point to the
> correct locations,  is there anything else I need to have installed  (I
> have the compilers).  If I can get it to work,  this might be for R4.0
> only,  I don’t keep two versions around,  and I don’t have Catalina.
>
> 2.  I assume there are other packages on the Mac that are in a similar
> situation,  would I be correct in assuming sp and sf?
>
> Thanks,
>
> -Roy
>
>
> > On May 29, 2020, at 1:44 PM, Roger Bivand  wrote:
> >
> > On Fri, 29 May 2020, Patrick Schratz wrote:
> >
> >> The URL returns a 404.
> >
> > Do you mean http://spatial.nhh.no/R/rgdal/? <
> http://spatial.nhh.no/R/rgdal/?> Please do say what you mean. If your
> browser blocks http: rather than https:, that is your choice. I imagine
> that it silently inserts an "s".
> >
> >>
> >> FWIW I’ve tried it locally using the latest svn revision but have no
> clue where I should find `proj_api.h` (I’ve looked in the complete proj
> installation directory).
> >
> > If PROJ 7.0.1 is properly installed, the header will be in
> $prefix/include. If your packager put all the headers somewhere else, use
> the command argument:
> >
> > $ ls /usr/local/include/proj*
> > /usr/local/include/proj_api.h   /usr/local/include/proj.h
> > /usr/local/include/proj_constants.h
> /usr/local/include/proj_symbol_rename.h
> > /usr/local/include/proj_experimental.h
> >
> > /usr/local/include/proj:
> > common.hpp   crs.hppmetadata.hpp
> > coordinateoperation.hpp  datum.hpp  nn.hpp
> > coordinatesystem.hpp io.hpp util.hpp
> >
> > You should not need to know. What does pkg-config proj --cflags say
> (once you've set PKG_CONFIG_PATH, of course.
> >
> >>
> >> I see
> >>
> >> ```
> >> ls /usr/local/Cellar/proj/7.0.1/lib/
> >> libproj.19.dylib  libproj.a libproj.dylib@libproj.la <
> http://libproj.la/>* pkgconfig/
> >> ```
> >>
> >
> > In your earlier post, you negected to say that you used the necessary
> configure argument. The error message says that you did not use it. Please
> report back when you have done so. Futher, I quote from your message: "It
> further causes complete breakage for people relying on the homebrew package
> manager on macOS since current versions are gdal v2.2.4 and proj 7.0.1."
> Please accept that I pay attention to what you write.
> >
> >> Even if this custom installation might work at some point, making such
> adjustments until gdal3 arrives in homebrew will be a major pain, also for
> CI builds.
> >> It would still be highly appreciated if this internal assertion would
> be removed again.
> >>
> >
> > Getting things right may be painful; GDAL 2 with PROJ 7 is wrong,
> because it mixes two incompatible metadata storage systems. Migrating all
> users to
> > GDAL >= 3 & PROJ >= 6 is a matter of urgency to avoid silent positional
> error of about 125m, or about 4 satellite image cells. See the vignette
> here
> http://rgdal.r-forge.r-project.org/articles/CRS_projections_transformations.html
> <
> http://rgdal.r-forge.r-project.org/articles/CRS_projections_transformations.html>
> and this r-spatial blog 

Re: [R-sig-Geo] rgdal 1.5-8 released on CRAN

[chris english]

And not desiring to muddy Thiago's clear waters, but when is Proj7*
transition expected?

Chris

On Fri, May 29, 2020 at 5:46 PM Roy Mendelssohn - NOAA Federal via
R-sig-Geo  wrote:

> I just tried using the Anaconda setup  Mine dies on not being able to find
> “projects.h”.
>
> > inverser.c:5:10: fatal error: 'projects.h' file not found
> > #include 
> >  ^~~~
>
>
> Doing internet searches,  for PROJ6 and beyond,  this was made private,
> and is not suppose to be for public linking, see:
>
> https://github.com/OSGeo/PROJ/issues/835 <
> https://github.com/OSGeo/PROJ/issues/835>
> https://code.mpimet.mpg.de/boards/1/topics/1184 <
> https://code.mpimet.mpg.de/boards/1/topics/1184>
>
> The discussion in the second one suggests that it should be linking to the
> public header proj_api.h rather than the private header projects.h.
> proj_api.h does exist in the installation I have.  Unless there is an easy
> fix I can do,  more than I want to mess with.
>
> -Roy
>
>
>
> > On May 29, 2020, at 2:25 PM, Thiago V. dos Santos via R-sig-Geo <
> r-sig-geo@r-project.org> wrote:
> >
> > Dear Roger,
> >
> > Many thanks for the effort keeping rgdal up-to-date with proj6.
> >
> > I'd like to report that I am unable to install rgdal 1.5.8 on my macOS
> system. I am reporting this error here on the list because I thought it
> would be the best channel in terms of reaching future users experiencing
> the same error. Please apologize if my rationale is not right, and ignore
> this message.
> >
> > GDAL was installed via MacPorts and is at its latest version, 3.1.0 (at
> the time of this writing). Proj6 has also been installed via Macports.
> >
> > This is how I am trying to install it:
> >
> > export PKG_CONFIG_PATH=/opt/local/lib/proj6/lib/pkgconfig
> > R
> > install.packages('rgdal', type="source", configure.args=c(
> >  '--with-proj-include=/opt/local/lib/proj6/include',
> >  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> >
> > and this is the output I get:
> >
> > R version 4.0.0 (2020-04-24) -- "Arbor Day"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-apple-darwin17.0 (64-bit)
> >
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> >
> >   Natural language support but running in an English locale
> >
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> >
> >> install.packages('rgdal', type="source", configure.args=c(
> > +  '--with-proj-include=/opt/local/lib/proj6/include',
> > +  '--with-proj-lib=/opt/local/lib/proj6/lib'))
> > Installing package into ‘/Users/thiago/Documents/R-packages’
> > (as ‘lib’ is unspecified)
> >
> >
> > trying URL '
> https://cran.r-project.org/src/contrib/rgdal_1.5-8.tar.gz'
> > Content type 'application/x-gzip' length 2299235 bytes (2.2 MB)
> > ==
> > downloaded 2.2 MB
> >
> >
> > * installing *source* package ‘rgdal’ ...
> > ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> > ** using staged installation
> > configure: R_HOME: /Library/Frameworks/R.framework/Resources
> > configure: CC: /opt/local/bin/gcc
> > configure: CXX: /opt/local/bin/g++
> > configure: C++11 support available
> > configure: rgdal: 1.5-8
> > checking for /usr/bin/svnversion... yes
> > configure: svn revision: 990
> > checking for gdal-config... /opt/local/bin/gdal-config
> > checking gdal-config usability... yes
> > configure: GDAL: 3.1.0
> > checking GDAL version >= 1.11.4... yes
> > checking GDAL version <= 2.5 or >= 3.0... yes
> > checking gdal: linking with --libs only... yes
> > checking GDAL: gdal-config data directory readable... yes
> > checking GDAL: /opt/local/share/gdal/stateplane.csv readable... yes
> > configure: pkg-config proj exists, will use it
> > configure: PROJ version: 6.3.2
> > configure: proj CPP flags: -DPROJ_H_API -I/opt/local/lib/proj6/include
> > configure: PROJ LIBS: -L/opt/local/lib/proj6/lib
> > checking PROJ header API:... proj.h
> > checking for gcc... /opt/local/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 /opt/local/bin/gcc accepts -g... yes
> > checking for /opt/local/bin/gcc option to accept ISO C89... none needed
> > checking how to run the C preprocessor... /opt/local/bin/gcc -E
> > checking for grep that handles long lines and -e... 

Re: [R-sig-Geo] [FORGED] Re: Introducing new local spatial statistic, ELSA, and Entrogram (a variogram-like graph)

[chris english]

Thank you one and all. Since we fled N Cyprus after the coup we've
been without university library privileges, so more limited to research
areas of neuropsychology and metric development. But I still aim to
predict that flood over Nicosia, 1349 AD.

The vignette is quite useful, and I especially like the capability to assign
dis/similarity zonally and believe this will have many applications that,
while in
theory may be either aesthetic or arbitrary, my sense is the current
subsuming
hierarchies is implausible. But then I'm a painter.

Open source of the article was a conflation of two somewhat overlapping
propositions, but of course an author may share his work. Just happy
to read about and think on the underlying. Thanks again!

Cheers,
Chris

On Tue, Apr 7, 2020 at 7:00 PM Rolf Turner  wrote:

>
> On 8/04/20 10:49 am, Babak Naimi wrote:
>
> > Hi Chris,
> >
> > Thanks for your email. Unfortunately, the article is not open but you can
> > find the PDF from the following link:
> >
> > https://www.dropbox.com/s/mpjra60b5yyzwjg/Naimi_2019_ELSA.pdf?dl=0
>
> If the paper is not open source, are you not violating copyright by
> making it available in this way?
>
> Could get you into trouble.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Introducing new local spatial statistic, ELSA, and Entrogram (a variogram-like graph)

[chris english]

Babak,

Look forward to exploring elsa, any plans to open source the journal
article?

Chris English

On Sun, Mar 29, 2020 at 1:08 AM Babak Naimi  wrote:

> Dear All,
>
> Hope you are safe and well!
>
> I am writing to inform you that the new R package, elsa, is released on
> CRAN. This package is a framework that provides the methods for quantifying
> the new local spatial statictic, named "entropy-based local indicator of
> spatial association" (ELSA), that can be used for both continuous and
> categorical data. In addition, global spatial structure can be measured
> using a new variogram-like diagram, called entrogram.
>
> The package vignette provides a quick demonstration of some main functions
> in the package:
>
> https://cran.r-project.org/web/packages/elsa/vignettes/elsa.html
>
> The paper that introduces ELSA is published in the journal of spatial
> statistics and is available here:
>
> https://www.sciencedirect.com/science/article/abs/pii/S2211675318300228
>
> The package, elsa, is also followed with functions to calculate other LISAs
> and global statistics for different types of spatial datasets (i.e.,
> Raster, SpatialPointsDataFrame, SpatialPolygonsDataFrame).
>
> Best regards,
>
> Babak Naimi
>
>
>
>
>
>
> *University Researcher, Department of Geosciences and Geography,The
> University of Helsinki,Gustaf Hällströmin Katu 2, 00014
> HelsinkiFinlandHomepage I: http://r-gis.net <http://r-gis.net/>  Homepage
> II: http://biogeoinformatics.org <http://biogeoinformatics.org/>  *
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] How to install sf r package in linux mint v 19.1 64 bit

[chris english]

Yuster,

Perhaps you don't have libproj-dev installed, though you probably do, but
if not:

sudo apt-get install libproj-dev

then help your system tell where things are located with:

export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib

these advice from:

https://gis.stackexchange.com/questions/157059/repairing-broken-gdal-and-proj-4-on-ubuntu

HTH,

Chris

ug 2, 2018 at 4:53 AM, Yuster Ronoh  wrote:

> I am not making head way on installing sf package  on R vs 3.4.4
>
> and this is the error I am getting:
>
> configure error: libroj not found in standard or given locations
>
> Error: configuration failed for package ’sf’
>
>   * removing ‘/home/feltp/R/x86_64-pc-linux-library/3.4.sf’
>
> Warning in install.packages :
>
>installation of ’sf’ had non-zero exit status
>
>
> The downloaded source packages are in
>
> ‘/tmp/RtmpSyJk3r/downloaded_packages”
> Regards.
>
> *Yuster Ronoh* | County Epidemiologists | *Nakuru County Health
> Department *| Club
> Road, Regional Commissioner HQs, Block 'B' 2nd Floor
>
> P.O. Box 2060 - 20100 * Nakuru*| Mobile +254724305899/ +254733573770 |
> Skype: yronoh
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Transform hexagonal to raster - a wife's question

[chris english]

Sarah,

I'll try the R-geo approach suggested for a small, sought after kokopeli,
and duck an integrated raster colorizer (five years to proto-type given my
skills.) I've forwarded all this to Dr Massa. I would say though that things
'loom' tend to work both for fabric and bead. Glad you checked the thread.

Happy summer,
Chris

On Mon, Jul 30, 2018 at 12:53 PM, Sarah Goslee 
wrote:

> Hi!
>
> I nearly didn't open this email thread: glad I did!
>
> I have some odd R tools for weaving, but nothing for beading.
>
> I suspect this is the best way to do it, although the actual result
> would depend on the particular pattern.
>
> http://www.bellaonline.com/articles/art61406.asp
>
> Whether it's worth writing R code to perform this task depends a lot
> on how many patterns need to be converted.
>
> A more R-geo approach might be to import the original pattern from an
> image file, turn it into spatial polygons, then rasterize it,
> completely ignoring the hexagonal nature of the original. With some
> playing with the raster grid size, you could probably get a decent
> approximation.
>
> Sarah
>
>
> On Mon, Jul 30, 2018 at 10:40 AM, chris english
>  wrote:
> > Thank you Ben!, I'll actually send her directly
> > to Sarah, http://www.sarahgoslee.com/ .
> > Dr. Massa, meet Dr. Goslee, Professor of indeterminate studies & weaver,
> > and writer,
> > Dr. Goslee, meet Dr. Massa, cognitive neuro research scientist, felter
> and
> > loom beader.
> > Thanks again,
> > Chris
> >
> > On Mon, Jul 30, 2018 at 9:12 AM, Ben Tupper  wrote:
> >
> >> If I were in your shoes I would be doing a hop-skip to ring Sarah
> Goslee's
> >> doorbell.  She's our resident ecology-spatial-textiles guru...
> >>
> >> http://www.stringpage.com/
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Jul 29, 2018, at 12:26 AM, chris english <
> englishchristoph...@gmail.com>
> >> wrote:
> >>
> >> My wife showed me a beading pattern that she was working on that looks
> to
> >> my eye like a hexagonal grid, its called a peyote stitch, and she needs
> to
> >> transform it to a loom stitch, essentially a raster. In the beading
> world
> >> they suggest combining two rows into one. If asked, what have you
> tried, I
> >> would say I tried to duck, but... In practical application, the two rows
> >> equals one doesn't appear to preserve the desired pattern when beading
> the
> >> loom, probably something like netting out the half-steps when you're
> going
> >> from two rows to one = n+1 or n +2 for bead count on the combined row.
> >> 40x40 hex grid, OK, I'll get out my graph paper. Summer.
> >>
> >> Thank you for your forbearance, and any very general thoughts
> appreciated,
> >> ie transforms sans datums & etc.
> >>
> >> Chris
> >>
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Transform hexagonal to raster - a wife's question

[chris english]

Thank you Ben!, I'll actually send her directly
to Sarah, http://www.sarahgoslee.com/ .
Dr. Massa, meet Dr. Goslee, Professor of indeterminate studies & weaver,
and writer,
Dr. Goslee, meet Dr. Massa, cognitive neuro research scientist, felter and
loom beader.
Thanks again,
Chris

On Mon, Jul 30, 2018 at 9:12 AM, Ben Tupper  wrote:

> If I were in your shoes I would be doing a hop-skip to ring Sarah Goslee's
> doorbell.  She's our resident ecology-spatial-textiles guru...
>
> http://www.stringpage.com/
>
>
>
>
>
>
>
> On Jul 29, 2018, at 12:26 AM, chris english 
> wrote:
>
> My wife showed me a beading pattern that she was working on that looks to
> my eye like a hexagonal grid, its called a peyote stitch, and she needs to
> transform it to a loom stitch, essentially a raster. In the beading world
> they suggest combining two rows into one. If asked, what have you tried, I
> would say I tried to duck, but... In practical application, the two rows
> equals one doesn't appear to preserve the desired pattern when beading the
> loom, probably something like netting out the half-steps when you're going
> from two rows to one = n+1 or n +2 for bead count on the combined row.
> 40x40 hex grid, OK, I'll get out my graph paper. Summer.
>
> Thank you for your forbearance, and any very general thoughts appreciated,
> ie transforms sans datums & etc.
>
> Chris
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive
> <https://maps.google.com/?q=60+Bigelow+Drive=gmail=g>, P.O.
> Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
>

[[alternative HTML version deleted]]

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

[R-sig-Geo] Transform hexagonal to raster - a wife's question

[chris english]

My wife showed me a beading pattern that she was working on that looks to
my eye like a hexagonal grid, its called a peyote stitch, and she needs to
transform it to a loom stitch, essentially a raster. In the beading world
they suggest combining two rows into one. If asked, what have you tried, I
would say I tried to duck, but... In practical application, the two rows
equals one doesn't appear to preserve the desired pattern when beading the
loom, probably something like netting out the half-steps when you're going
from two rows to one = n+1 or n +2 for bead count on the combined row.
40x40 hex grid, OK, I'll get out my graph paper. Summer.

Thank you for your forbearance, and any very general thoughts appreciated,
ie transforms sans datums & etc.

Chris

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] spam message when sending a mail to the list

[chris english]

Laura, Andres,

As Roger admonished me, just never respond ( a mistake I made ), as it is
very difficult to both maintain this
valuable communication regards spatial statistics and exclude the clearly
un-statistically minded.

Chris

On Wed, May 30, 2018 at 10:08 AM, Andres Diaz Loaiza 
wrote:

> Hi LAura,
>
> To me also happened the same, even worst because they are now sending
> photos which I am probably sure contains viruses.
>
> Is true that the maillist maintainer should exclude this mail address
>
> The mail of the sender is:  elisarose811...@es.fcebo.com
>
> All the best,
>
> Andres
>
> 2018-05-30 16:03 GMT+02:00 Laura Poggio :
>
> > Dear list,
> > not sure if it is just me, but I sent two messages to the list in the
> past
> > couple of days. In both cases I immediately received a message from an
> > unknown sender with some "particular requests". This is not happening
> when
> > I send mails to other contacts.
> >
> > I can provide more information to the maintainers or please just let me
> > know if/where to report them.
> >
> > Thanks
> >
> > laura
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
>
>
> --
> Andrés D.
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Measuring length of trajectories

[chris english]

Jeri,

Is your data some kind of attached to bird(s) gps data?

Chris

On Thu, May 24, 2018 at 9:12 AM, Jeri Wisman  wrote:

> Hi all -
>
> I am trying to measure the length of time of trajectories taken of seabird
> movements to be able to relate time of flight to distance of flight. Any
> suggestions of a function or package on how to measure the time? Thanks,
>
> *Jeri Wisman* | Masters Candidate
> Old Dominion University
> Department of Biological Sciences
> Mills Godwin Building, Room 312
> Norfolk VA 23529 USA
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Location level analysis of spatio-temporal data

[chris english]

Geez Marilyn, I would have thought, given your proclivity for geospatial
statistics you'd pretty well know where I was,
within a mile and a second or two. I guess you can check with Sai, as you
popped up the moment I replied to him.
Sigh. What will I tell my wife?
Chris

On Sun, Apr 29, 2018 at 10:54 PM, Marilyn Dean <lillynrose...@blackkick.pw>
wrote:

> chris,  I'm not for anything too crazy I am Marilyn Dean and age is not
> too big of a deal {as long as you are handsome and respectful as long as
> you are a good guy . I just want to have a time if you know what I mean ;)
>
>
>  also, whats your location? whats the plan for first meet?|
>
> On Sun, 29 Apr 2018 at 08:51 PM, chris english <
> englishchristoph...@gmail.com> wrote:
>
>>
>>
>>
>>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Location level analysis of spatio-temporal data

[chris english]

Sai,

There is something like take it from the end to the beginning and back, or
beginning to end and back to
the beginning and end and back, and ask yourself what does my data
recommend. The end is how I suppose you
generally anticipate analyzing/modeling the data, and the beginning being
your understanding of how the data
was collected and its vagaries.

If you sampled your data, say .60 in a train set and reduced each variable
to its quantile median
 quantile(your_data[[x]][, 'your_one_of_many_variables'], type =8)[[3]]
# without na.rm = TRUE anticipating running this through caret 'gbm'
and then examine influence of time as against space among your variables.

Space can be characterized in a lot of dimensions, and then you have time
which seems often to be like a sampling rate upon those
potentially many spatial characteristics, But give it a try anyway and find
if time isn't up there in position one or two in variable importance with
spatial variables after you run your data through gbm.

For further reading I would suggest the work of Emmanual Parzen and also
his work in collaboration with Subhadeep (Deep) Mukhopadhyay
on why quantile median might be your special friend.

As ever, I probably shouldn't comment as I know little and there are much
better informed scientists here. The interesting claim to be
wrestled from the Parzen/Mukhopadhyay material is that the data (that you
have) informs the sufficient statistics to be found and that specific
domain knowledge is not necessary to such. This, is the claim, is the power
of the quantile median analysis.

Does this relieve you of answering your question of whether to apply
spatio-temporal upon the whole set, or time series upon a sampling point;
hard to say but Parzen/Mukhopadhyay say, give me your data and I'll give
you your sufficient statistics. It will, I suspect, at the very least
confirm
or disprove the proposition that your data is spatio-temporal (since you
don't say what it is) as a received notion, which is a good starting point
in any case.

My thoughts,
Chris


On Sat, Apr 28, 2018 at 11:16 PM, Sai Kumar Popuri  wrote:

> Hi,
>
> I am new to spatio-temporal analysis and trying to understand some basics.
> Suppose I have a large spatio-temporal data. I can either fit an advanced
> model with a spatio-temporal covariance structure or I could fit a time
> series model at each location separately. When are these two approaches
> similar? When is the second approach justified?
>
> Thank you,
> Sai
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Problems With Cartography 2 - Help

[chris english]

Andres,

I'm thinking you want to 'unsimplify' the topology prior to your poly2nb by
a slight negative gBuffer on the Galapagos polygons,
reduce the Galapagos polygons by the buffer and un-share the boundaries.
I'm trying some code, but looking at a mix of these as
guidance:

https://www.rdocumentation.org/packages/rgeos/versions/0.3-22/topics/gBuffer
https://gist.github.com/mstrimas/1b4a4b93a9d4a158bce4
https://gis.stackexchange.com/questions/93096/how-to-perform-a-true-gis-clip-of-polygons-layer-using-a-polygon-layer-in-r

Saludos,
Chris

On Wed, May 10, 2017 at 4:27 AM, Andrés Peralta  wrote:

> Hi to everyone,
>
> I`m working with the second administrative level cartography from Ecuador
> (available in: http://www.ecuadorencifras.gob.ec//documentos/web-inec/
> Cartografia/2015/Clasificador_Geografico/2012/SHP.zip). The shape file is
> called nxcantones.shp. I`ve been having a lot of problems opening and
> working with this cartography in R; but i can open it in Q-GIS and ARCGIS
> without any problem (I have opened it in both programs and saved it again).
> As the cartography has various objects with the same ID - aparently the
> same areas but repeated; we had to run the following sintax in order to
> have one ID in each area:
>
> *carto2012 <- readOGR("CANTONES2012/2012CLEAN.shp", "2012CLEAN",
> stringsAsFactors=F) *
> *proj4string(carto2012) <- CRS("+proj=utm +zone=17 +south +datum=WGS84
> +units=m +no_defs")*
>
> *carto2012x <- unionSpatialPolygons(carto2012, IDs=carto2012$DPA_CANTON)*
> *proj4string(carto2012x) <- CRS("+proj=utm +zone=17 +south +datum=WGS84
> +units=m +no_defs")*
>
>
> *datos <- data.frame(ID=row.names(carto2012x), stringsAsFactors = F)*
> *row.names(datos) <- row.names(carto2012x)*
> *carto2012x2 <- SpatialPolygonsDataFrame(carto2012x, data=datos)*
>
> *carto2012 <- carto2012x2 *
>
> For our work, we had to make a neighborhood matrix of the cartography.
>
> *x.nb <- poly2nb(carto2012u2) # U2 is the cartography after the recode of
> some areas that had to be joined.*
>
> *summary(x.nb)*
>
> This seems to work fine. The problem is we need to connect the three island
> areas (the Galapagos) but when we try to do so, it connects many areas
> along all the cartography. I've tried to do it manually using *edit.nb* but
> it does not work. I´ve also tried the following sintaxes:
>
> x.nb1 <- x.nb
> which(card(x.nb1)==0) #to discover the id of these areas without
> connections
> id <- function(x){which(carto2012u2$ID==x)}
>
> x.nb1[[id(2001)]] = unique(as.integer(sort(c(x.nb1[[id(2001)]],
> id(2002)
> x.nb1[[id(2002)]] = unique(as.integer(sort(c(x.nb1[[id(2002)]],
> id(2001)
>
> x.nb1[[id(2001)]] = unique(as.integer(sort(c(x.nb1[[id(2001)]],
> id(2003)
> x.nb1[[id(2003)]] = unique(as.integer(sort(c(x.nb1[[id(2003)]],
> id(2001)
>
> x.nb1[[id(2002)]] = unique(as.integer(sort(c(x.nb1[[id(2002)]],
> id(2003)
> x.nb1[[id(2003)]] = unique(as.integer(sort(c(x.nb1[[id(2003)]],
> id(2002)
>
> 
> x.nb1[[id("2001")]] = unique(as.integer(sort(c(x.nb1[[id("2001")]],
> id("2002")
> x.nb1[[id("2002")]] = unique(as.integer(sort( id("2001"
>
> x.nb1[[id("2001")]] = unique(as.integer(sort(c(x.nb1[[id("2001")]],
> id("2003")
> x.nb1[[id("2003")]] = unique(as.integer(sort( id("2001"
>
> x.nb1[[id("2002")]] = unique(as.integer(sort(c(x.nb1[[id("2002")]],
> id("2003")
> x.nb1[[id("2003")]] = unique(as.integer(sort( id("2002"
>
> Any ideas or suggestions? Your help will really be appreciated.
>
>
> --
>
> * Andrés Peralta*
> Pre-doctoral Researcher
>  GREDS/EMCONET / ASPB
>    
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[[alternative HTML version deleted]]

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

[R-sig-Geo] alpha hulls (always complete) and incomplete envelops (confidence intervals)

[chris english]

I have a series of noodles, which is to say line shapes, that I am trying
to come to grips.

If I generalize these lines away to point clouds in time order, then an
alpha hull will contain all points, as would convex hull, but potentially
with less wasted space. The thing about a convex hull or alpha hull is that
all samples are 'within'.  This is to say that it is converged as sample =
infinity, or, more normally, sample = total number of samples available
which is generally less than infinity.

In a very general way, I am wondering if there is an accepted method to
allow, say 30 percent of the 'alpha hulled' samples (which clearly are not
designed to allow such) to reside outside the alpha hull (essentially
creating confidence intervals upon the alpha hull (or perhaps I haven't
read enough)) . Secondarily, is there a way to compare 'confidence
interval' alpha hulls, where 70 percent of the sample points reside within,
and the rest exogenous.

I ask as my noodles may share, to an unknown amount, but perhaps
extensively, commonalities of co-existance to as much as 70 percent (it is
speculated) of an alpha hull space, and the variance that I am trying to
account for is the 30 percent that I would guess and perhaps to define as a
separate alpha hull, or some sort space, outside the alpha hull space.

Having it both ways: *if *100% of points are within the alpha hull, how
might one reduce this to 70% or some such, because hulls are always sample
complete.

I realize that this probably sounds inchoate, or am I fantabulizing, but I
think I am asking about comparing the shapes of constrained (incomplete)
alpha hulls in the context of Parzen windows (whose shape I wonder about,
boxes?).

Another way of looking at this a point process is that given a 1280x1280
grid, there are an enormous number of cells that will always be NA, a
smaller number that will be visited once. So how to proceed to compare the
noodles.

While I sense I will be killed on this question: Any thoughts or suggested
reading appreciated so I might address more intelligently anon.
Chris

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Pycnophylactic Interpolation

[chris english]

Breno,

Just an article comparing pycnophylatic interpolation to area-to-point
kriging
https://www.researchgate.net/publication/227727493_Reconstructing_Population_Density_Surfaces_from_Areal_Data_A_Comparison_of_Tobler's_Pycnophylactic_Interpolation_Method_and_Area-to-Point_Kriging
Chris

On Sun, Apr 23, 2017 at 4:35 PM, Breno Oliveira 
wrote:

> Hi,
>
> I'm a student of Information Systems in Brazil and a junior software
> archtect. To my final work on the undergraduate program I'm implementing a
> software with the Potential model. After calculate the potential values to
> each point of analysis I would like to be able to create a map to represent
> the result. The map should looks like this one:
> https://www.r-bloggers.com/contour-and-density-layers-with-ggmap/. I'm
> new in R so I have no a big knowhow and a lot of doubts. I would like ask
> for community's help. My problem is that I have no to many points like the
> example so the map looks incorrect, actualy I have a few points (x,y and
> z). I think I must Interpolate these points to get a good result, I would
> like to use the Pycnophylactic Interpolation avaliable in pycno package.
>
> Here is a example of data I obtain (no interpolation applied):
>
>
> CityAreaScore   latitudes   longitudes  Potentials
> Belo Horizone   330,95  2513451 -19,91663263-43,93337198164874,1295
> Betim   346 412003  -19,96730327-44,2011972482629,32514
> Contagem195,268 648766  -19,91615326-44,08087722140851,9626
> Sarzedo 61,892  25798   -20,06250329-44,1150472379307,30623
> Rio Acima   50  90  -20,08830329-43,7910471755226,91779
>
>
> Please let me know if you need any extra information.
> Thank you for your patience and cooperation.
> Breno Oliveira
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] R-help - Shiny and Datatable

[chris english]

Joe,

If you look again at the CDC, USA 500 ,(
https://chronicdata.cdc.gov/500-Cities/500-Cities-Local-Data-for-Better-Health/6vp6-wxuq
),
the top 26 rows are USA crude prevalence  then age adjusted prevalence by
disease (for 2014), or the 13 (either crude prevalence, or age adjusted)
that you are looking for.

Judging by what you were describing above, it doesn't sound like you're
doing a 'things got better or things got worse,
year on year', so perhaps filtering the data to a given year (2014) and
given  health outcome (age adjusted) prior to
downloading might simplify things.
HTH
Chris

On Sun, Apr 23, 2017 at 6:19 PM, Joe Larson 
wrote:

> Hello,
>  I am getting wrapped around the axial on a shiny project, being a new R
> learner I am asking for some help. I am trying to combine CDC data, Shiny,
> and leaflet together to produce a map that has the top 500 USA cities with
> adverse medical outcomes.  The goal is to allow the user to select either
> the range of outcome, state or adverse outcome.  Through Shiny examples, I
> am able to get the range function to work, but not the "state" or "health
> outcomes" to function correctly. My issue is in using input type selectable
>  "selectInput("state", "State Abbr", data_c$state, selected = NULL,
> multiple = FALSE, selectize = TRUE, width = NULL, size = NULL), "  The
> challenge I am facing is selecting the correct "Render reactive output"
>  and how to mutate the datatable so the users inputs are correctly
> displayed.  If you want the full code, to let me know.
> I have been reading shiny.rstudios.com as well the shiny-cheatsheet.pdf
> with the solution not coming to mind.
> Thanks for any suggestion you can offer.
>
> The datatable has this format (first 2 cities and allThe isisue is I can
> not find out which type of 13 outcomens):
> X year state cityname crudeprevalence populationcount measureid lat long
> healthoutcome metropop
> 1 2014 AL Birmingham 32.6 212237 ARTHRITIS 33.52756638 -86.79881747
> 0.0153 Birmingham(city),
> 212237(popluation), 0.0153(Arthritis %)
> 2 2013 AL Birmingham 45.9 212237 BPHIGH 33.52756638 -86.79881747
> 0.0216 Birmingham(city),
> 212237(popluation), 0.0216(High blood pressure %)
> 3 2014 AL Birmingham 6.1 212237 CANCER 33.52756638 -86.79881747 0.0028
> Birmingham(city),
> 212237(popluation), 0.0028(Cancer (excluding skin cancer)  %)
> 4 2014 AL Birmingham 11.4 212237 CASTHMA 33.52756638 -86.79881747
> 0.0053 Birmingham(city),
> 212237(popluation), 0.0053(Asthma %)
> 5 2014 AL Birmingham 7.6 212237 CHD 33.52756638 -86.79881747 0.0035
> Birmingham(city),
> 212237(popluation), 0.0035(Coronary heart disease %)
> 6 2014 AL Birmingham 9.4 212237 COPD 33.52756638 -86.79881747 0.0044
> Birmingham(city),
> 212237(popluation), 0.0044(Chronic obstructive pulmonary disease %)
> 7 2014 AL Birmingham 16.1 212237 DIABETES 33.52756638 -86.79881747
> 0.0075 Birmingham(city),
> 212237(popluation), 0.0075(Diabetes %)
> 8 2013 AL Birmingham 35.4 212237 HIGHCHOL 33.52756638 -86.79881747
> 0.0166 Birmingham(city),
> 212237(popluation), 0.0166(High cholesterol %)
> 9 2014 AL Birmingham 3.3 212237 KIDNEY 33.52756638 -86.79881747 0.0015
> Birmingham(city),
> 212237(popluation), 0.0015(Kidney disease %)
> 10 2014 AL Birmingham 17 212237 MHLTH 33.52756638 -86.79881747 0.008
> Birmingham(city),
> 212237(popluation), 0.008(Mental health %)
> 11 2014 AL Birmingham 18.3 212237 PHLTH 33.52756638 -86.79881747
> 0.0086 Birmingham(city),
> 212237(popluation), 0.0086(Physical health %)
> 12 2014 AL Birmingham 5 212237 STROKE 33.52756638 -86.79881747 0.0023
> Birmingham(city),
> 212237(popluation), 0.0023(Stroke %)
> 13 2014 AL Birmingham 25.9 212237 TEETHLOST 33.52756638 -86.79881747
> 0.0122 Birmingham(city),
> 212237(popluation), 0.0122(All teeth lost %)
> 14 2014 AL Hoover 25.3 81619 ARTHRITIS 33.37676027 -86.80519376 0.0309
> Hoover(city),
> 81619(popluation), 0.0309(Arthritis %)
> Thanks for you help and insight in advance
> Joe
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

[chris english]

Edzer,

Installs fine now, though st_make_valid is useful when cleaning messy
inputs. I
just installed new ubuntu binaries for PostGIS last night but will attend
to rebuild
from source.

 The only thing to come up in an otherwise smooth install:
** preparing package for lazy loading
in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition for
class “Spatial”
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (sf)
Reloading installed sf
Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1

I'm guessing this refers to sp::Spatial-class as Spatial is capitalized. I
don't know
whether this will affect swapping in and out of sf <->sp, but include it
for completeness.

Thanks again,

Chris

On Thu, Mar 16, 2017 at 5:06 AM, Edzer Pebesma <
edzer.pebe...@uni-muenster.de> wrote:

> Mike, Chris, the configure step should now pass regardless whether
> liblwgeom is present, or not; the error message was my mistake.
>
> sf will link to liblwgeom when its development version is present (on
> ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
> present, but not its dev version (needed for header files); that case is
> now being caught too.
>
> liblwgeom provides st_make_valid, essentially ST_makeValid in postgis;
> see https://github.com/edzer/sfr/issues/67 . Since liblwgeom is not
> available on the CRAN build farms, it's presence is not required by sf.
>
> Best regards,
>
> On 16/03/17 05:46, chris english wrote:
> > Michael,
> >
> > I have the very same failure,
> >> library(sf)
> > Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
> > (pre upgrade attempt, which still works just fine)
> >
> > checking for geos_c.h... yes
> > checking geos: linking with -lgeos_c... yes
> > checking for lwgeom_version in -llwgeom... no
> > configure: error: in `/tmp/RtmpsCmf6B/devtoolsd68e68107a/edzer-sfr-
> d620f3b':
> > configure: error: lwgeom test failed (--without-readline to disable)
> >
> > I could nearly copy your install output though on 16.04, and the same
> > tangle of it depends on x but it won't be installed & etc.
> > But, if you have PostGIS, you have liblwgeom as it is fairly specific to
> > PostGIS. Perhaps, rather than a devtools::github_install,
> > a clone github lo a local directory and config, make, install might
> > work, but I'm just imagining.
> >
> > then testing:
> > config.log --snip --
> > configure:3993: checking for lwgeom_version in -llwgeom
> > configure:4018: gcc -std=gnu99 -o conftest -g -O2 -fstack-protector
> > --param=ssp-
> > buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g
> >  -I/usr/lo
> > cal/include   -I/usr/local/include -I/usr/local/include
> > -Wl,-Bsymbolic-functions
> >  -Wl,-z,relro conftest.c -llwgeom  -lproj  -L/usr/local/lib -lproj
> > -L/usr/loca
> > l/lib -lgdal -L/usr/local/lib -lgeos_c -lproj >&5
> > /tmp/ccDBUh1h.o: In function `main':
> > /home/chris/sfr/sfr/conftest.c:34: undefined reference to
> `lwgeom_version'
> > collect2: error: ld returned 1 exit status
> > configure:4018: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> > | #define PACKAGE_NAME ""
> > | #define PACKAGE_TARNAME ""
> > | #define PACKAGE_VERSION ""
> > | #define PACKAGE_STRING ""
> > | #define PACKAGE_BUGREPORT ""
> > | #define PACKAGE_URL ""
> > | #define STDC_HEADERS 1
> > | #define HAVE_SYS_TYPES_H 1
> > | #define HAVE_SYS_STAT_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_STRING_H 1
> > | #define HAVE_MEMORY_H 1
> > | #define HAVE_STRINGS_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_STDINT_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define HAVE_GDAL_H 1
> > | #define HAVE_PROJ_API_H 1
> > | #define HAVE_LIBPROJ 1
> > | #define HAVE_GEOS_C_H 1
> > | /* end confdefs.h.  */
> > |
> > | /* Override any GCC internal prototype to avoid an error.
> > |Use char because int might match the return type of a GCC
> > |builtin and then its argument prototype would still apply.  */
> > | #ifdef __cplusplus
> > | extern "C"
> > | #endif
> > | 

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

[chris english]

Michael,

I have the very same failure,
> library(sf)
Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
(pre upgrade attempt, which still works just fine)

checking for geos_c.h... yes
checking geos: linking with -lgeos_c... yes
checking for lwgeom_version in -llwgeom... no
configure: error: in `/tmp/RtmpsCmf6B/devtoolsd68e68107a/edzer-sfr-d620f3b':
configure: error: lwgeom test failed (--without-readline to disable)

I could nearly copy your install output though on 16.04, and the same
tangle of it depends on x but it won't be installed & etc.
But, if you have PostGIS, you have liblwgeom as it is fairly specific to
PostGIS. Perhaps, rather than a devtools::github_install,
a clone github lo a local directory and config, make, install might work,
but I'm just imagining.

then testing:
config.log --snip --
configure:3993: checking for lwgeom_version in -llwgeom
configure:4018: gcc -std=gnu99 -o conftest -g -O2 -fstack-protector
--param=ssp-
buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g
 -I/usr/lo
cal/include   -I/usr/local/include -I/usr/local/include
-Wl,-Bsymbolic-functions
 -Wl,-z,relro conftest.c -llwgeom  -lproj  -L/usr/local/lib -lproj
-L/usr/loca
l/lib -lgdal -L/usr/local/lib -lgeos_c -lproj >&5
/tmp/ccDBUh1h.o: In function `main':
/home/chris/sfr/sfr/conftest.c:34: undefined reference to `lwgeom_version'
collect2: error: ld returned 1 exit status
configure:4018: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GDAL_H 1
| #define HAVE_PROJ_API_H 1
| #define HAVE_LIBPROJ 1
| #define HAVE_GEOS_C_H 1
| /* end confdefs.h.  */
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char lwgeom_version ();
| int
| main ()
| {
| return lwgeom_version ();
|   ;
|   return 0;
| }
configure:4027: result: no
configure:4036: error: in `/home/chris/sfr/sfr':
configure:4038: error: lwgeom test failed (--without-readline to disable)
See `config.log' for more details

so, it may or may not be the presence or absence of liblwgeom but simply
an undefined reference as suggested above:

/home/chris/sfr/sfr/conftest.c:34: undefined reference to `lwgeom_version' ,

but I'm unclear how the version was being requested (well, I can kind of
guess)
but failing on undefined reference suggests it is not the version per se
that may
or may not be present (though is because you are using PostGIS), but how
the version was requested. I intuit.

Ah, and reading  /* confdefs.h */, that it indeed ends with #define
HAVE_GEOS_C_H 1,
and indeed, conftest.c:34: would have an  undefined reference to
`lwgeom_version'.

And I've said as much as I understand.

Chris

On Wed, Mar 15, 2017 at 7:53 PM, Michael Treglia  wrote:

> Sorry - this follow-up isn't entirely an R question, so if best to take
> this off list, let me know:
>
> Installing the dev version from github fails for me (installing on ubuntu
> 14.04.5) - I've included the output from the install process below - seems
> to fail due to failed check for liblwgeom version.
>
> Looks like I don't have liblwgeom installed - and when I try (via sudo
> apt-get install liblwgeom-2.3-0), it indicates it requires libgeos-c1.
> Installing libgeos-c1, however, requires removal of a newer version of
> libgeos (libgeos-c1v5), which other FOSS GIS tools depend on (at least if
> my understanding is correct).  Is there a way around this?  Sorry if I'm
> just missing something, and thanks again for input.
> mike
>
>
>
> #Output of install from github
> > install_github("edzer/sfr")
> Downloading GitHub repo edzer/sfr@master
> from URL https://api.github.com/repos/edzer/sfr/zipball/master
> Installing sf
> '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
> --quiet  \
>   CMD INSTALL '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'  \
>   --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
> --install-tests
>
> * installing *source* package ‘sf’ ...
> configure: CC: gcc -std=gnu99
> configure: CXX: g++
> configure: :
> checking for gdal-config... /usr/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 2.1.0
> checking GDAL version >= 2.0.0... yes
> checking for gcc... 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... no
> 

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

[chris english]

Michael,

this from the sf vignettes on read write to databases:

The dsn and layer arguments to st_read and st_write denote a data source
name and optionally a layer name. Their exact interpretation as well as the
options they support vary per driver, the GDAL driver documentation is best
consulted for this. For instance, a PostGIS table in database postgis might
be read by

meuse <- st_read("PG:dbname=postgis", "meuse")

where the PG: string indicates this concerns the PostGIS driver, followed
by database name, and possibly port and user credentials.

st_read typically reads the coordinate reference system as proj4string, but
not the EPSG (SRID). GDAL cannot retrieve SRID (EPSG code) from proj4string
strings, and, when needed, it has to be set by the user.

I just re-read this this morning for my own understanding, and the
statements regarding st_read would appear to apply as explicitly to
st_write as both or mediated by GDAL, that processes proj4string(s) but not
epsg. So it looks like manually setting or resetting epsg is part of the
workflow. Further down in the crs section is discussion about how within a
layer both proj4string and epsg must be the same, or NA. This may localize
where the 900914 is being applied, i.e. in PostGIS to settle the table
parameters.

HTH,

Chris





On Wed, Mar 15, 2017 at 3:50 PM, Michael Treglia  wrote:

> Hi All,
>
> Been working to import and manipulate a CSV file with point data
> (lat/long), and then export to a PostGIS db.
>
> Overall, successful, but one thing I'd like to fix - when I write out the
> layer to postgis, the SRID is not maintained. The final EPSG/SRID should be
> 2263, but when I check in PostGIS, it comes up as 900914.
>
> Below is my code and sessionInfo, and the data are from here:
> https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-
> Data-Current-YTD/5uac-w243
> (downloaded as plain old CSV)
>
> Anything I might be missing? Thanks in advance for giving a quick look!
> Mike
>
>
> ##Start Code
>
> #load packages
> library(sf)
> library(RPostgreSQL)
>
> #read data
> crime_current <- read.csv("NYPD_Complaint_Data_Current_YTD.csv",
> stringsAsFactors = FALSE)
>
> #format time columns for easier reading in postgres (I think), as keeping
> as date format caused problems in export
> crime_current$CMPLNT_FR_TIME <-
> as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
> crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M", tz=""))
> crime_current$CMPLNT_TO_TIME <-
> as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
> crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M", tz=""))
> crime_current$RPT_DT <- as.character(as.POSIXct(crime_current$RPT_DT,
> format="%m/%d/%Y", tz=""))
>
> #convert to sf object
> crime_current.sf <- st_as_sf(crime_current, coords = c("Longitude",
> "Latitude"), crs = 4326)
> #reproject to EPSG 2263
> crime_current.sf <- st_transform(crime_current.sf, crs=2263)
>
> #write to postgres
> st_write(crime_current.sf, "PG:dbname=mydb user=user host=xx.xx.xx.xx",
> 'health_safety.crime_current')
> ###End Code
>
>
>
> > sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] sp_1.2-3  RPostgreSQL_0.4-1 DBI_0.6   sf_0.3-4
>
> loaded via a namespace (and not attached):
> [1] tools_3.3.1 units_0.4-2 Rcpp_0.12.9 udunits2_0.13
> grid_3.3.1  lattice_0.20-33
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] "invalid" geometries in shape data

[chris english]

Michael,

I'll forward to rgis/toposhop/issues some 'flat' triangles (i.e. co-linear)
that come up in my neuro
data. Even Roualt says that TRIANGLE will be in GDAL 2.2 release in May and
has been
wrestling with it since Nov/Dec last.

PostGIS tests first three points of polygon for co-linearity but doesn't
detail precision,
presumably at level provided. stryk seems generally pragmatic in these
things. Even was
miffed in a Dec tweet about triangle having four points (.."and its called
Simple Features),
but coming where it does in the polygon hierarchy, it is going to be
closed.

geophys::TriangleInfo tests for co-linearity using sign of determinant
through the dt function,
though determinant (proper) would likely be quicker for evaluating lots of
them as it is direct call to
.Internal.

I am still trying to wrap my head around RTriangle. I think it must be
sturdy for triangle(s), but in
some sense its goal of mesh propagation upon/within a polygon system is
seemingly time travel
compared to my 'this thing is a triangle, aren't it?" None of the methods
I've seen so far seem to test
for 'no internal boundary', including CGAL. And none of this addresses
'automatic fixing tool' that
you or Delft suggests.

My data, from the wild, seems amenable to a jitter after a test by either
atan2 or determinant to
establish candidates for jittering. determinant seems like it would work
best with sf approach to
st_geometry(sfc) as they are lists and one can discern, following geophys'
approach building out
(adding 1s to a 3rd col of) a 2x4 triangle/polygon matrix to 3x4 and
evaluating on first 3x3 square.

I've said as much as I know to this point, triangles are coming.

Chris

On Wed, Feb 8, 2017 at 1:47 PM, Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:

> Searching GIS StackExchange for [r] and TopologyException might find you a
> few:
>
> http://gis.stackexchange.com/search?q=%5Br%5D+topologyexception
>
> [answered one of these just today:
> http://gis.stackexchange.com/questions/227569/r-error-
> fortifying-dataframe-from-shapefile]
>
> Barry
>
> On Tue, Feb 7, 2017 at 9:46 PM, Michael Sumner  wrote:
> > Hi,
> >
> > I'm interested in exploring the details of kinds of errors and warnings
> > that are seen from the underlying geometry lib (GEOS) for spatial data in
> > R.
> >
> > I would like to also have a collection of  examples with actual data and
> > reproducible code.
> >
> > (The underlying theory and definitions and source code are all open and
> > available, I'm looking for examples).
> >
> > The kinds of errors I'm talking about come from the GEOS library under
> the
> > hood, and this is more or less the same in the sp/rgdal as well as the
> new
> > sf family.
> >
> > Here's one example, this data set is not valid because of at least one
> > "polygon self intersection", basically the ring winds back on itself:
> >
> > library(maptools)
> > data(wrld_simpl)
> > rgeos::gIsValid(wrld_simpl)
> > [1] FALSE
> > Warning message:
> > In RGEOSUnaryPredFunc(spgeom, byid, "rgeos_isvalid") :
> >   Ring Self-intersection at or near point -95.90249633999
> > 66.94664192005
> >
> > I'd appreciate if you could send me similar examples, preferably
> > reproducible with code but links to existing emails and online posts are
> > welcome too. Feel free to construct examples from scratch that reproduce
> a
> > particular warning/error.
> >
> > If you like, you can use the Github Issues mechanism here, or just email
> > them in reply.
> >
> > https://github.com/r-gris/toposhop/issues
> >
> > Cheers, Mike.
> >
> >
> > --
> > Dr. Michael Sumner
> > Software and Database Engineer
> > Australian Antarctic Division
> > 203 Channel Highway
> > Kingston Tasmania 7050 Australia
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Error-message-when-trying-to-compute-the-least-cost-path-in-gdistance-in-R

[chris english]

Marta,

I don't know what constructed your trCost (1560 x 1560 sparse Matrix of
class "dsCMatrix") which I take to be symmetric of
8 directions.

> r <- raster(nrows = 1560, ncols = 1560)
> r <- setValues(r, runif(ncell(r)))
> trCost <- transition(r, transitionFunction = mean, directions = 8)

All I can find to the moment is a little problem of naming in the
shortestPath function call

i.e. pts1 and pts2 are matrix objects (like coordinates), presumably to be
start and goal.

and if they are written as:

plot(shortestPath(trCost, pts1[1,], pts2[1,], output="SpatialLines"))
you get a plot
# without add=TRUE in my case as
# with add=TRUE it reminds me I haven't called plot yet hence nothing to
add to:
Error in plot.xy(xy.coords(x, y), type = type, ...) :
  plot.new has not been called yet


rather than:

plot(shortestPath(trCost, pts[1,], pts[2,], output="SpatialLines"))
which gives this error:

Error in shortestPath(tr, pts[1, ], pts[2, ], output = "SpatialLines") :
  object 'pts' not found


So I imagine that isn't what you had in your call


the Error, generally otherwise would point to NA(s) in the matrix (trCost).
Well. I'm guessing.

HTH,

Chris


On Mon, Nov 28, 2016 at 1:05 PM, marta azores  wrote:

> http://r-sig-geo.2731867.n2.nabble.com/Error-message-when-
> trying-to-compute-the-least-cost-path-in-gdistance-in-R-tt7590273.html
>
> Hi everyone,
>
> I have a similar problem. I have two points that I want to join in one line
> "SpatialLines"
>
> class(trCost)#"TransitionLayer"+attr gdistance
> summary(trCost)#1560 x 1560 sparse Matrix of class "dsCMatrix", with 8
> entries
>
> pts1<-cbind(x=-27.54572,y=38.30128)
>
> pts2<-cbind(x=-28.59933,y=37.32453)
> #
> class(pts1)#matrix
> class(pts2)#matrix
> #
> is.numeric(pts1)#[1] TRUE
>
> plot(shortestPath(trCost, pts[1,], pts[2,], output="SpatialLines"),
> add=TRUE)
> Error in if (is.numeric(v) && any(v < 0)) { :
>   missing value where TRUE/FALSE needed
>
> Thanks in advance
>
> Marta
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] readOGR() in rgdal and 64-bit integers

[chris english]

Roger,

I concur with Rich, both that most (new) users won't quite follow the
implication of the transforms, clamping, work flow, nor yet have a sense of
what the numbers "should look like". Perhaps no.loss coupled with warning
pointing to readOGR() help to expand on implications.

Chris

On Oct 27, 2016 2:02 PM, "Rich Shepard"  wrote:

> On Thu, 27 Oct 2016, Roger Bivand wrote:
>
> The current default assumes that users actually use ogrInfo() to examine
>> their data before reading it. Is this overly optimistic? Would it be
>> better to change the default to "no.loss" or "warn.loss"? A doodle is
>> here: http://doodle.com/poll/9qaqrkbs6q7k5skz - I'd be grateful for
>> feedback.
>>
>
> Roger,
>
>   Given human nature I think that default assumption is incorrect. While
> 'warn.loss' seems to be a resonable replacement it assumes that users all
> know what to do about the loss of data. I voted for 'no.loss' as
> accommodating everyone without assumptions about reading or adjusting.
>
> Regards,
>
> Rich
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Reproducibility of results from predict() function - raster package

[chris english]

Katie,

set.seed(123) on each run thru will (should) result in reproducibility.

set.seed(1234)
pred <- predict(

Chr

On Oct 27, 2016 7:19 PM, "Katherine Ransom" 
wrote:
>
> Hi All,
> I am having trouble reproducing my results exactly when I make predictions
> with predict() and a saved gbm model object. Each time I run predict()
with
> the same model object and inputs (a raster stack), I get slightly
different
> values (max value within 0.7 for a range of predictions from 0.08 to 12.30
> for example). However, there seems to be a limited amount of outcomes. For
> example, I can get the results to reproduce if I run predict enough times.
>
> The issue seems to be within the predict() function as it doesn't seem to
> be related to R session, loading package libraries, etc.
>
> Are there any random number generators or known bugs within the predict
> function that could be causing this behavior?
>
> Here is my code line that calls predict: pred <- predict(rstack, final,
> n.trees=final$n.trees,na.rm=TRUE,const=data.frame(WaterUse2="H"))  #
> family="gaussian"
>
> Not sure if I need the family = "gaussian" option. It doesn't seem to
> affect the results.
>
> Thank you,
> Katie
>
> --
> --
> Katherine Ransom
> PhD Candidate
> Hydrologic Sciences Graduate Group
> UC Davis
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Access to google drive account using RGoogleDocs

[chris english]

Roger,

Thank you for this input. I am accustomed to high latency. Though I imagine
that this DDOS on DSN services will escalate through the
the end of the present election and beyond. There's probably an R approach,
in addition to Apache, to dealing with this...

As a completely peculiar aside, my wife decided a year ago that when she
has her fugue state, her last name will be Bivand.
She loves the sound. Best to think forties movies here. Hope you look
something like Charles Boyer, as it will round things out nicely.

Chris

On Fri, Oct 21, 2016 at 9:06 PM, Roger Bivand <roger.biv...@nhh.no> wrote:

> It appears that there are ongoing DDOS incidents affecting DNS providers
> and through them the services you mention; see:
>
> https://tech.slashdot.org/story/16/10/21/135241/several-site
> s-including-twitter-spotify-paypal-nytimes-suffering-
> outagedyn-dns-under-ddos-attack-update
>
> so I'd wait until things calm down before drawing conclusions.
>
> Roger
>
>
> On Fri, 21 Oct 2016, chris english wrote:
>
> Paolo,
>>
>> I saw your post and was just anticipating sharing some data with
>> colleagues
>> in New Zealand, and I believe that
>> between two weeks ago and now, github has changed some Apache Server
>> settings so that me, sitting in Cyprus can no longer
>> access, though if I went in through my wife's VPN and appeared to be in
>> NYC, it might work. So, at the moment
>> I can't even get into github using devtools to check, but I believe that
>> your 'error' has to do with your locale 'it' as against where
>> github servers are and a new filter. I could, of course, be wrong on all
>> counts, but when I arrive NYC next week I'll
>> check and report.
>>
>> I realize that this seems somewhat far afield of your question regarding
>> RGoogleDocs, but I've been noticing a segmentation
>> in accessibility in Amazon, Google (at times), and now github which is
>> completely inaccessible. So perhaps it is a matter of contracting
>> a VPN service. As I say, I'll check in NY and report.
>>
>> Chris
>>
>> On Fri, Oct 21, 2016 at 2:32 PM, Paolo Piras <paolo.pi...@uniroma3.it>
>> wrote:
>>
>> Hi folks,
>>>
>>> I'm not sure if this topic could be appropriate here as it is not
>>> properly
>>> geostatistical but maybe someone could help me
>>>
>>> I have a shared space on google drive with some colleagues; I would like
>>> to access there from R and to list files in the folders and eventually to
>>> load some data into R.
>>>
>>> I know that RGoogleDocs package allows it but it seems not working when I
>>> try to login using
>>>
>>> auth = getGoogleAuth("mygm...@gmail.com","mypasword",service="wise")
>>> I have:
>>> "Error: not found"
>>>
>>> I found an old post where other people experienced the same problem but a
>>> solution was not present there.
>>> Maybe there are other packages such as googlesheets but my primary
>>> purpose
>>> is to list files present in the folder.
>>> Anyway...thanks in advance for any hint
>>> All the best
>>> Paolo
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> R-sig-Geo mailing list
>>> R-sig-Geo@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 91 00
> e-mail: roger.biv...@nhh.no
> http://orcid.org/-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0J=en
> http://depsy.org/person/434412
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Access to google drive account using RGoogleDocs

[chris english]

Paolo,

I saw your post and was just anticipating sharing some data with colleagues
in New Zealand, and I believe that
between two weeks ago and now, github has changed some Apache Server
settings so that me, sitting in Cyprus can no longer
access, though if I went in through my wife's VPN and appeared to be in
NYC, it might work. So, at the moment
I can't even get into github using devtools to check, but I believe that
your 'error' has to do with your locale 'it' as against where
github servers are and a new filter. I could, of course, be wrong on all
counts, but when I arrive NYC next week I'll
check and report.

I realize that this seems somewhat far afield of your question regarding
RGoogleDocs, but I've been noticing a segmentation
in accessibility in Amazon, Google (at times), and now github which is
completely inaccessible. So perhaps it is a matter of contracting
a VPN service. As I say, I'll check in NY and report.

Chris

On Fri, Oct 21, 2016 at 2:32 PM, Paolo Piras 
wrote:

> Hi folks,
>
> I'm not sure if this topic could be appropriate here as it is not properly
> geostatistical but maybe someone could help me
>
> I have a shared space on google drive with some colleagues; I would like
> to access there from R and to list files in the folders and eventually to
> load some data into R.
>
> I know that RGoogleDocs package allows it but it seems not working when I
> try to login using
>
> auth = getGoogleAuth("mygm...@gmail.com","mypasword",service="wise")
> I have:
> "Error: not found"
>
> I found an old post where other people experienced the same problem but a
> solution was not present there.
> Maybe there are other packages such as googlesheets but my primary purpose
> is to list files present in the folder.
> Anyway...thanks in advance for any hint
> All the best
> Paolo
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] No neighbours in sample using spatcounts package in R

[chris english]

Nick,

Perhaps a pitch it to the maintainer and report back here? I was just
fooling around and it was the
structure of n.temp that was driving my approach, but each input finds its
way in thru the formula. Still
haven't had time to run this thru debugonce() as i am trying to flee a
non-country, god help me, with dogs.
And, where I know this actually does't help much, I'll try to look at it
later. Have to get off the turkish keyboard and
back to my own machine/

Chris



On Fri, Oct 21, 2016 at 1:46 AM, Nick van Doormaal <
nick.vandoorm...@gmail.com> wrote:

> Hi Chris,
>
> Thank you very much for your time and effort to help me out. Much
> appreciated!
> When I checked the structure of the example dataset, it seems that all the
> variables are numerical. That's why I thought that replacing all the NAs
> with 0s would be an okay way.
>
> library(spatcounts)
> data(sim.nmat)
> str(sim.nmat)
> 'data.frame':   100 obs. of  6 variables:
>  $ V1: num  1 2 3 4 5 6 7 8 9 10 ...
>  $ V2: num  11 12 13 14 15 16 17 18 19 20 ...
>  $ V3: num  2 1 2 3 4 5 6 7 8 9 ...
>  $ V4: num  0 3 4 5 6 7 8 9 10 0 ...
>  $ V5: num  0 0 0 0 0 0 0 0 0 0 ...
>  $ V6: num  2 3 3 3 3 3 3 3 3 2 ...
>
> str(n.temp)
> 'data.frame':   63 obs. of  6 variables:
>  $ V1: num  1 2 7 13 14 16 19 20 21 22 ...
>  $ V2: num  1 1 1 1 1 1 1 1 1 1 ...
>  $ V3: num  2 1 1 23 1 26 1 30 31 32 ...
>  $ V4: num  1 1 1 1 13 1 1 19 22 21 ...
>  $ V5: num  1 1 1 14 1 1 20 1 1 23 ...
>  $ V6: num  1 1 0 2 1 1 1 2 2 3 ...
>
> I think it has something to do with the combination of nmat (ntemp) and
> gmat (gtemp)...but I can't really figure out how or why.
>
> On 20 October 2016 at 12:20, chris english <englishchristoph...@gmail.com>
> wrote:
>
>> Nick,
>>
>> I get the same error running your code.
>>
>> set.seed(987654321)
>>
>> library(spatcounts)
>> data("sim.Yin")
>> data("sim.fm.X")
>> data("sim.gmat")
>> data("sim.nmat")
>> data("sim.region")
>> AllData <- cbind(sim.Yin, sim.region, sim.fm.X)
>> colnames(AllData)[1:2] <- c("Yin", "Region")
>>
>> idx <- sample(1:nrow(AllData), 100, replace=TRUE)
>> newdata.df <- AllData[idx,]
>> newdata.df <- newdata.df[order(newdata.df$Region),]
>> X <- as.data.frame(newdata.df[,3:4])
>> region <- as.data.frame(newdata.df$Region)
>> colnames(region) <- "V1"
>> Yin <- as.data.frame(newdata.df$Yin)
>>
>> temp.idx <- sort(unique(newdata.df$Region))
>> g.temp <- sim.gmat[temp.idx,temp.idx]
>>
>> TotalN <- rowSums(g.temp) ##CHECK IF THERE ARE ZEROS PRESENT
>> > is.element(0, n.temp$V6)
>> [1] TRUE # after a few run thru's of idx to is.element
>>
>> n.temp <- sim.nmat[temp.idx,]
>> n.temp$V2 <- temp.idx[match(n.temp$V2, temp.idx)]
>> n.temp$V3 <- temp.idx[match(n.temp$V3, temp.idx)]
>> n.temp$V4 <- temp.idx[match(n.temp$V4, temp.idx)]
>> n.temp$V5 <- temp.idx[match(n.temp$V5, temp.idx)]
>> n.temp$V6 <- TotalN
>>
>> > class(n.temp$V1)
>> [1] "numeric"
>> > class(n.temp$V2)
>> [1] "integer"
>> > class(n.temp$V3)
>> [1] "integer"
>> > class(n.temp$V4)
>> [1] "integer"
>> > class(n.temp$V5)
>> [1] "integer"
>> > class(n.temp$V6)
>> [1] "numeric"
>>
>> # here, essentially checking what NA might be replaced with by class
>> # and wondering if a small numeric is desirable (0.001), $V1 & $v6
>> # and your 0 for integers ($V2-V5)
>>
>> Well, a bunch of different tries and the error persists.
>>
>> > n.temp[is.na(n.temp)] <- 1
>> > n.temp$V6[7] <- 10
>> > n.temp$V6[24] <- 10
>> > n.temp$V6[28] <- 0.001
>> >
>> > n.temp$V6[28] <- 10
>>
>> > which(n.temp$V6 == 0)
>> integer(0)
>>
>>
>> > Yin.NB <- est.sc(Yin, ~ X[,1] + X[,2] -1,
>> + region, model="NB", g.temp, n.temp, totalit=10) ##ERROR
>> Error: NA/NaN/Inf in foreign function call (arg 1)
>>
>> So, i guess i'd do a debugonce(est.sc) and find out which foreign
>> function is disappointing or
>> disappointed by the inputs, but the culprit does not appear to be TotalN.
>>
>> HTH,
>>
>> Chris
>>
>>
>>
>> On Wed, Oct 19, 2016 at 4:01 PM, Nick van Doormaal <
>> nick.vandoorm...@gmail.com> wrote:
>>
>>> Dear list members,
>>>
>>> I'm trying to do a bootstrap of a spatial count model usin

Re: [R-sig-Geo] Generating Random Planar Graph with 1m Edges

[chris english]

l sub data.frame for faster computation
> #n <- 5
> #nr <- nrow(NN12)
> #NN13 <- split(NN12, rep(1:ceiling(nr/n), each=n, length.out=nr))
>
>
>
> #FIRST LINE
> l1 <- NN13[1, ]
> NN13 <- NN13[-1,]
> l1 <- c(t(l1))
> #read l1 from poisson point set
> Ydata2 <- Ydata[l1, c('x','y')]
> #divide into two point sets
> Z1 <- Ydata2[1,]
> Z2 <- Ydata2[2,]
> #create Line Segment Pattern
> Z <- psp(Z1[1, 1], Z1[1, 2], Z2[1, 1], Z2[1, 2], window=owin(w))
>
> #LOOP START
> repeat {
>   l1 <- NN13[1, ]
>   NN13 <- NN13[-1, ]
>   l1 <- c(t(l1))
>   #read l1 from poisson point set
>   Ydata2 <- Ydata[l1, c('x','y')]
>   #divide into two point sets
>   Z1 <- Ydata2[1,]
>   Z2 <- Ydata2[2,]
>   #create Line Segment Pattern
>   H <- psp(Z1[1, 1], Z1[1, 2], Z2[1, 1], Z2[1, 2], window=owin(w))
>   #intersecting lines check
>   J <- crossing.psp(Z,H,fatal=TRUE,details=FALSE)
>
>   H1 <- as.vector(H$ends, mode="numeric")
>   J$x <- setdiff(J$x, H1)
>   J$y <- setdiff(J$y, H1)
>   J$y1 <- data.frame(J$y)
>   J$x1 <- data.frame(J$x)
>   J$Ally <- count(J$y1)
>   J$Allx <- count(J$x1)
>
>   if ( J$Ally == 0 & J$Allx == 0 ) { Z <- append.psp(Z,H) }
>   else
> if ( nrow(NN13)==0 ) { break }
>   else
>   { }
> }
>
>
> plot(owin(w))
> plot(Z, add=TRUE)
> detach("package:dplyr", unload=TRUE)
>
>
>
> On 06 Oct 2016, at 15:58, chris english <englishchristoph...@gmail.com>
> wrote:
>
> Kimon-Vincent,
>
> I write off list because perhaps my suggestion is just too stupid and I
> don't want to further solidify my reputation for 'stupid' suggestions. But
> it seems to me, taking Roger's RANN suggestion in mind, that the test for
> E, be taken, not just at the end, as in the ABCDE approach the paper
> suggests, but upon selection of each C, prior to adding to a list of
> successful (non-intersecting) edges using (rgeos) gIntersection upon a
> candidate back against an existing list, prior to appending to said list.
> Should it fail, next C. I need to give some more thought to what is meant
> by D (though it seems to suggest a limit of neighbors, I'd have to read the
> paper),do D, and finally E again as non-intersecting confirmatory.
>
> And look back at your repeat{, (which I find quite interesting anyway) and
> figure out how to vectorize using some apply family as this should greatly
> reduce computation time. Flow control is useful, but teasing apart the
> exact vector steps and the order you want them applied, while puzzling,
> should remove your computation time bottlenecks. I'm not expert enough at
> this time to advise.
>
> Sorry if all of this seems silly.
>
> Chris
>
> On Wed, Oct 5, 2016 at 11:43 PM, Krenz, Kimon-Vincent  krenz...@ucl.ac.uk> wrote:
>
>> Dear All,
>>
>> I started a week ago to use R to solve a problem I am currently facing in
>> my PhD.
>> Apologies in advance for the long-winded explanation of my problem.
>>
>> I am trying to generate a random planar graph with approximately 1
>> million edges, where:
>>
>> A) nodes (points) feature spatial coordinates
>> B) the network has a given boundary
>>
>> C) edges (lines) are created if two points fall within a given distance
>> (e.g. 100 - 1000 metres)
>> D) degree (connectivity) ranges between given k max and min (e.g. k ≤ 5)
>> E) edges do not intersect
>>
>> This will result in something one might want to compare to a random
>> street network.
>>
>> I am following a method proposed here: Masucci, A. P., Smith, D., Crooks,
>> A., & Batty, M. (2009). Random planar graphs and the London street network.
>> European Physical Journal B, 71(2), 259–271. http://doi.org/10.
>> 1140/epjb/e2009-00290-4) link to paper: https://goo.gl/6XWW8P
>>
>> Masucci et al.: "We first introduce a random model for a static planar
>> graph. ... To build an ERPG we start with a Poisson distribution of N
>> points in a plane and we choose a distance r. To build the first segment,
>> we randomly pick up two points of the distribution that have a distance
>> less then r and we connect them. Then we continue to randomly pick up pairs
>> of points P and Q in the given points distribution that have a distance
>> less then r. If the segment PQ does not intersect any other line of the
>> graph, we add it to the graph. The process ends when we add the desired
>> number of edges E.”
>>
>> I hence, started with generating random points using the Poisson
>> distribution in a given spatial box (A and A):
>>
&g

Re: [R-sig-Geo] No neighbours in sample using spatcounts package in R

[chris english]

Nick,

I get the same error running your code.

set.seed(987654321)

library(spatcounts)
data("sim.Yin")
data("sim.fm.X")
data("sim.gmat")
data("sim.nmat")
data("sim.region")
AllData <- cbind(sim.Yin, sim.region, sim.fm.X)
colnames(AllData)[1:2] <- c("Yin", "Region")

idx <- sample(1:nrow(AllData), 100, replace=TRUE)
newdata.df <- AllData[idx,]
newdata.df <- newdata.df[order(newdata.df$Region),]
X <- as.data.frame(newdata.df[,3:4])
region <- as.data.frame(newdata.df$Region)
colnames(region) <- "V1"
Yin <- as.data.frame(newdata.df$Yin)

temp.idx <- sort(unique(newdata.df$Region))
g.temp <- sim.gmat[temp.idx,temp.idx]

TotalN <- rowSums(g.temp) ##CHECK IF THERE ARE ZEROS PRESENT
> is.element(0, n.temp$V6)
[1] TRUE # after a few run thru's of idx to is.element

n.temp <- sim.nmat[temp.idx,]
n.temp$V2 <- temp.idx[match(n.temp$V2, temp.idx)]
n.temp$V3 <- temp.idx[match(n.temp$V3, temp.idx)]
n.temp$V4 <- temp.idx[match(n.temp$V4, temp.idx)]
n.temp$V5 <- temp.idx[match(n.temp$V5, temp.idx)]
n.temp$V6 <- TotalN

> class(n.temp$V1)
[1] "numeric"
> class(n.temp$V2)
[1] "integer"
> class(n.temp$V3)
[1] "integer"
> class(n.temp$V4)
[1] "integer"
> class(n.temp$V5)
[1] "integer"
> class(n.temp$V6)
[1] "numeric"

# here, essentially checking what NA might be replaced with by class
# and wondering if a small numeric is desirable (0.001), $V1 & $v6
# and your 0 for integers ($V2-V5)

Well, a bunch of different tries and the error persists.

> n.temp[is.na(n.temp)] <- 1
> n.temp$V6[7] <- 10
> n.temp$V6[24] <- 10
> n.temp$V6[28] <- 0.001
>
> n.temp$V6[28] <- 10

> which(n.temp$V6 == 0)
integer(0)


> Yin.NB <- est.sc(Yin, ~ X[,1] + X[,2] -1,
+ region, model="NB", g.temp, n.temp, totalit=10) ##ERROR
Error: NA/NaN/Inf in foreign function call (arg 1)

So, i guess i'd do a debugonce(est.sc) and find out which foreign function
is disappointing or
disappointed by the inputs, but the culprit does not appear to be TotalN.

HTH,

Chris



On Wed, Oct 19, 2016 at 4:01 PM, Nick van Doormaal <
nick.vandoorm...@gmail.com> wrote:

> Dear list members,
>
> I'm trying to do a bootstrap of a spatial count model using the
> *spatcounts-package* in R. However, resampling with replacement may lead to
> "islands", because sometimes no neighbors will be selected. I believe this
> is causing the error message: Error: NA/NaN/Inf in foreign function call
> (arg 1). Can somebody confirm this if this indeed the case? If so, is there
> a way to get around it, so that I would still be able to carry out a
> bootstrap?
>
> Please find below the code to recreate the problem using the example
> dataset of the spatcounts package.
>
> Thank you for your time and I hope somebody can help me out a bit.
>
> START CODE#
> set.seed(987654321)
>
> library(spatcounts)
>
> AllData <- cbind(sim.Yin, sim.region, sim.fm.X)
> colnames(AllData)[1:2] <- c("Yin", "Region")
>
> idx <- sample(1:nrow(AllData), 100, replace=TRUE)
> newdata.df <- AllData[idx,]
> newdata.df <- newdata.df[order(newdata.df$Region),]
> X <- as.data.frame(newdata.df[,3:4])
> region <- as.data.frame(newdata.df$Region)
> colnames(region) <- "V1"
> Yin <- as.data.frame(newdata.df$Yin)
>
> temp.idx <- sort(unique(newdata.df$Region))
> g.temp <- sim.gmat[temp.idx,temp.idx]
>
> TotalN <- rowSums(g.temp) ##CHECK IF THERE ARE ZEROS PRESENT IN THIS
> VECTOR.##OTHERWISE RUN AGAIN UNTIL AT LEAST ONE ZERO
>
> n.temp <- sim.nmat[temp.idx,]
> n.temp$V2 <- temp.idx[match(n.temp$V2, temp.idx)]
> n.temp$V3 <- temp.idx[match(n.temp$V3, temp.idx)]
> n.temp$V4 <- temp.idx[match(n.temp$V4, temp.idx)]
> n.temp$V5 <- temp.idx[match(n.temp$V5, temp.idx)]
> n.temp$V6 <- TotalN
>
> n.temp[is.na(n.temp)] <- 0
>
> Yin.NB <- est.sc(Yin, ~ X[,1] + X[,2] -1,
> region, model="NB", g.temp, n.temp, totalit=10) ##ERROR
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Extract() fails to return data for boundary admin units

[chris english]

Mel,

Sorry, your pseudo-code:

raster::extract(udel, admin, fun=mean, na.rm=T, small=T, weights = TRUE)

Chris

On Tue, Oct 18, 2016 at 6:10 PM, chris english <
englishchristoph...@gmail.com> wrote:

> Mel,
>
> Looking at detail in cjg.png the northmost missing data island shows
> approx 20-25 in Southern three quarters and 0-5 the small North at tip of
> island. Directly above this 0-5 another coastal 0-5.
> If a substantial east-west scarp bisected the island it might explain. I
> would otherwise expect a very slight mismatch in projection, a thing I
> often have problems with.
>
> Though reading raster::extract it looks like you want to employ the
> weights are if your polys are relatively smaller than your cells.
>
> HTH
> Chris
>
> On Oct 18, 2016 4:35 PM, "Bacou, Melanie" <m...@mbacou.com> wrote:
>
>> Hi,
>> I'm summarizing biophysical rasters (UDEL precipitation and temperature)
>> across administrative units for countries in Africa using (pseudo code):
>>
>> raster::extract(udel, admin, fun=mean, na.rm=T, small=T)
>>
>> Out of the 756 units I need data for, extract() fails to return means for
>> a few coastal units (in red on the maps below) even though the rasters show
>> data at these locations.
>>
>> Is there a particular reason why this might happen? Shall I look for
>> possible geometry errors in my source shapefiles, or could there be another
>> reason?
>>
>> Maps here:
>> https://dl.dropboxusercontent.com/u/30925475/eclgcdmhapfplaml.png
>> https://dl.dropboxusercontent.com/u/30925475/lmkgmdoohpmhdcjg.png
>>
>> Thanks for any tip. --Mel.
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Extract() fails to return data for boundary admin units

[chris english]

Mel,

Looking at detail in cjg.png the northmost missing data island shows approx
20-25 in Southern three quarters and 0-5 the small North at tip of island.
Directly above this 0-5 another coastal 0-5.
If a substantial east-west scarp bisected the island it might explain. I
would otherwise expect a very slight mismatch in projection, a thing I
often have problems with.

Though reading raster::extract it looks like you want to employ the weights
are if your polys are relatively smaller than your cells.

HTH
Chris

On Oct 18, 2016 4:35 PM, "Bacou, Melanie"  wrote:

> Hi,
> I'm summarizing biophysical rasters (UDEL precipitation and temperature)
> across administrative units for countries in Africa using (pseudo code):
>
> raster::extract(udel, admin, fun=mean, na.rm=T, small=T)
>
> Out of the 756 units I need data for, extract() fails to return means for
> a few coastal units (in red on the maps below) even though the rasters show
> data at these locations.
>
> Is there a particular reason why this might happen? Shall I look for
> possible geometry errors in my source shapefiles, or could there be another
> reason?
>
> Maps here:
> https://dl.dropboxusercontent.com/u/30925475/eclgcdmhapfplaml.png
> https://dl.dropboxusercontent.com/u/30925475/lmkgmdoohpmhdcjg.png
>
> Thanks for any tip. --Mel.
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] "Islands" in spatial (area) analysis

[chris english]

Wolfgang,

The lake on the island in the bigger lake is a topological construct, and I
believe was covered by Bivand et al (1st ed.) A search of 'topology island
hole' or 'topology island hole GIS analysis' will get you out of the
Caribbean and into some serious papars. 'Gdal island hole' will direct
toward how things are generally handled in R.

Cheers,

Chris

On Thu, Aug 18, 2016 at 4:47 PM, Ludwig-Mayerhofer, Wolfgang, Prof. Dr. <
ludwig-mayerho...@soziologie.uni-siegen.de> wrote:

> Dear all,
>
> I'm new to this list, and regrettably I have to  introduce myself with a
> question which is not necessarily related to R, even though any R-related
> answer will also help (as I do my spatial analyses mostly with R).
>
> My question is simply: Does anybody know a good (possibly
> systematic/comprehensive/dedicated/exhaustive) text about the
> role/problem of "islands", i.e. areas without neighbors, in (area data)
> spatial analysis? I know that some procedures don't run in the presence of
> islands, but others do (with the appropriate zero policies), but I'm not
> always sure whether this means that the results are really meaningful.
>
> I can only occasionally find reference to the "island" problem in the
> literature (many texts, among which are VERY good texts like those by
> Bivand et al or Banerjee et al, seem to ignore it entirely), and what
> little I have found is very superficial (aside remarks etc.). Regrettably,
> a search on the Internet (such as "islands spatial analysis") is futile, as
> all you will get are tons of references to the Caribbean, Canary, tropic,
> Auckland ... you name it... islands.
>
> So any suggestion as to where a more than casual treatment of the topic
> can be found would be very welcome.
>
> Kind regards
>
> Wolfgang Ludwig-Mayerhofer
>
> 
> Prof. Dr. Wolfgang Ludwig-Mayerhofer
> Universität Siegen/University of Siegen
> Philosophische Fakultät/Faculty of Arts
> Adolf-Reichwein-Str. 2
> 57068 Siegen
> Germany
>
> Wolfgang Ludwig-Mayerhofer (2015): Arbeitsmarktpolitik  aus
> sozialwissenschaft­licher Sicht: Zur Spannung zwischen "Dekommodifizierung"
> und "Rekommodifizierung". In: Masuch, Peter et al.  (Hrsg.): Grundlagen und
> Herausforderungen des Sozialstaats (Band2): Bundessozialgericht und
> Sozialstaatsforschung. Richterliche Wissensgewinnung und Wissenschaft,
> Berlin, S. 377-393.
>
> Wolfgang Ludwig-Mayerhofer, Olaf Behrend (2015): Enforcing Mobility:
> Spatial Mobility Under the Regime of Activation, in: Mobilities, 10 (2), S.
> 326-343. DOI: 10.1080/17450101.2014.898930
>
> Wolfgang Ludwig-Mayerhofer (2014): Bildung zwischen Individualisierung und
> Exklusion. In: Schnei­der, W. und Kraus, W. (Hrsg.): Indivi­du­alisierung
> und die Legitimation sozialer Ungleich­heit in der reflexiven Moderne.
> Opladen: Barbara Budrich, S. 167-192
>
> Wolfgang Ludwig-Mayerhofer, Uta Liebeskind, Ferdinand Geißler  (2014):
> Statistik. Eine Einführung für Sozialwissenschaftler, Weinheim: Beltz
> Juventa, 2014. http://www.beltz.de/produkt_produktdetails/8819-statistik.
> html
>
>
> [[alternative HTML version deleted]]
>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Plotting USA map with each state's shape or size reflective of a metric

[chris english]

Vinh,
Perhaps an interesting crosswalk between hex and equal area maps with
github code linked.
https://www.google.com.cy/url?sa=t=web=j=https://blog.diegovalle.net/2015/06/mexican-2015-election.html=0ahUKEwiNlLutrpvOAhWE7BQKHcCHCfUQFggmMAQ=AFQjCNF7ycTpUYPohPUsOmqLOJeTWFZyag
A somewhat confusing link coming out of a lmgtfy on a phone, but I think
crosswalks like this might be more useful as you have at least two
expressions of what you are trying to represent.
HTH, chris

On Jul 30, 2016 16:57, "Vinh Nguyen" <vinhdi...@gmail.com> wrote:

> I was able to find examples (some from R bloggers) after googling R
> cartograms. Thanks Nick and Chris.
>
> Shapefiles did show up relative to metric, but they look very distorted
> and I'm not sure it conveys information the best way possible.
>
> Anyone run into hexbin examples or something similar to the original post?
> That is, not necessarily shapefiles. Approximate location and shapes are
> fine. Thanks!
>
> On Jul 30, 2016 6:40 AM, "chris english" <englishchristoph...@gmail.com>
> wrote:
>
>> Try r-bloggers cartogram for worked examples in R.
>> Chris
>>
>> On Jul 29, 2016 19:01, "Nick Eubank" <nickeub...@gmail.com> wrote:
>>
>> Not sure how to do in R (can do in arcgis), but you might find the term
>> "Cartogram" useful on google -- that's the "term of art" for those maps.
>>
>> On Fri, Jul 29, 2016 at 8:20 AM Vinh Nguyen <vinhdi...@gmail.com> wrote:
>>
>> > Hi everyone,
>> >
>> > Does anyone know if this is possible with R? An example can be found
>> here:
>> > http://projects.fivethirtyeight.com/2016-election-forecast/ (a few
>> plots
>> > down).
>> >
>> > Appreciate any references you point me to. Thanks!
>> >
>> > Vinh
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > R-sig-Geo mailing list
>> > R-sig-Geo@r-project.org
>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
>>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Plotting USA map with each state's shape or size reflective of a metric

[chris english]

Try r-bloggers cartogram for worked examples in R.
Chris

On Jul 29, 2016 19:01, "Nick Eubank"  wrote:

Not sure how to do in R (can do in arcgis), but you might find the term
"Cartogram" useful on google -- that's the "term of art" for those maps.

On Fri, Jul 29, 2016 at 8:20 AM Vinh Nguyen  wrote:

> Hi everyone,
>
> Does anyone know if this is possible with R? An example can be found here:
> http://projects.fivethirtyeight.com/2016-election-forecast/ (a few plots
> down).
>
> Appreciate any references you point me to. Thanks!
>
> Vinh
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Incorrect month order in zApply function

[chris english]

Thiago,

I understand you're in discussion with Robert about code changes; but,
absent these, why wouldn't Ben's solution be sufficient, assuming the code
change might simply issue a warning that the names output will be
alphanumeric and a second step might be required to conform for
presentation or analytical purposes. Just wondering. Thanks.
Chris

On Jul 29, 2016 22:20, "Thiago V. dos Santos via R-sig-Geo" <
r-sig-geo@r-project.org> wrote:

Thanks everyone for their suggestions.

Reordering the output of zApply would be a WRONG solution, because the
layers are already ordered from Jan to Dec.

It is just the NAMES that are misaligned, which can cause a bit of
confusion.

I already contacted Robert about this issue and we should see a solution
soon.
 Greetings,
 -- Thiago V. dos Santos

PhD student
Land and Atmospheric Science
University of Minnesota



On Friday, July 29, 2016 2:09 PM, Kay Kilpatrick <
kkilpatr...@rsmas.miami.edu> wrote:
Hi

The various Apply functions always return the output in simple
alphabetical order when the factor label is a character, regardless of
the order of the factor in the calling argument.

Ben had a correct solution --- simply reorder the output from Zapply.

Alternatively you could use a numeric representation for the month label
using by = as.numeric(months(x). The output would then be in increasing
numeric order from 1 -12.

I do not believe Vijay's suggestion is proper. It does not reorder the
output --- instead it changes the label of a given monthly mean eg. The
value for Jan. would then be labeled as Apr.

k

On 7/28/16 10:52 PM, Thiago V. dos Santos via R-sig-Geo wrote:
> Dear all,
>
> I am using the raster package to calculate monthly averages of climatic
variables.
>
> Essentially, this is the function I use:
>
> library(raster)
>
> # Create date sequence
> idx <- seq(as.Date("1996/1/1"), as.Date("2010/12/31"), by = "day")
>
> # Create raster stack and assign dates
> r <- raster(ncol=5, nrow=5)
> s <- stack(lapply(1:length(idx), function(x) setValues(r,
runif(ncell(r)
> s <- setZ(s, idx)
>
> # Calculate monthly average
> x <- zApply(s, by=months, mean, name=month.abb[])
>
> names(x)
> [1] "April" "August" "December" "February" "January" "July" "June"
> [8] "March" "May" "November" "October" "September"
> getZ(x)
> [1] "April" "August" "December" "February" "January" "July" "June"
> [8] "March" "May" "November" "October" "September"
>
>
> The problem here is the output of both names(x) and getZ(x). It looks
like a random month order is returned (even though I provide the labels),
which makes me confused about the results.
>
>
> By performing the same calculation in a different software and comparing
the results, I came to realize that the order of months for the results by
raster should, in fact, be Jan-Feb-Mar-Apr-May-Jun-Jul-Aug-Sep-Oct-Nov-Dec
>
> How can I control the way raster delivers the object names after using
zApply, in order to sort the months in the "natural" order?
>
> Greetings, -- Thiago V. dos Santos
>
> PhD student
> Land and Atmospheric Science
> University of Minnesota
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo=CwICAg=y2w-uYmhgFWijp_IQN0DhA=VXzrzLaooo912e5bVVEO_z5cHQXu_22lipAXBkfCXjM=tzdb3kN3Nxjo7NbPkPVqtF269bJen1bf3AzSHEwd7CA=zuokuoKIDT6cOaBD2J6ePy1klmf1J3-f3BynP_G5I-g=


--
Katherine (Kay) Kilpatrick
University of Miami/RSMAS
Ocean Science Department
Satellite Remote Sensing Laboratory
MSC 231
4600 Rickenbacker Cswy
Miami, Fl
ph: 305-962-3069
kkilpatr...@rsmas.miami.edu


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

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

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Problems with rbind(list(), makeUniqueIDs=T)

[chris english]

Mel,

> m <- lapply(c("TZA", "UGA", "GHA"), function(x) getData("GADM",
country=x, level=1))
I get: (after GDAM downloads)
trying URL 'http://biogeo.ucdavis.edu/data/gadm2.8/rds/TZA_adm1.rds'
Content type 'unknown' length 1152781 bytes (1.1 MB)
==
downloaded 1.1 MB

trying URL 'http://biogeo.ucdavis.edu/data/gadm2.8/rds/UGA_adm1.rds'
Content type 'unknown' length 1749955 bytes (1.7 MB)
==
downloaded 1.7 MB

trying URL 'http://biogeo.ucdavis.edu/data/gadm2.8/rds/GHA_adm1.rds'
Content type 'unknown' length 164023 bytes (160 KB)
==
downloaded 160 KB

> m <- rbind(m, makeUniqueIDs=T)
> head(m)
  [,1] [,2] [,3]
m ???
makeUniqueIDs TRUE TRUE TRUE
> m
  [,1] [,2] [,3]
m ???
makeUniqueIDs TRUE TRUE TRUE
> m <- lapply(c("TZA", "UGA", "GHA"), function(x) getData("GADM",
country=x, level=1))

## Now I have this data locally

> m
[[1]]
class   : SpatialPolygonsDataFrame
features: 30
extent  : 29.32717, 40.44514, -11.7457, -0.9857875  (xmin, xmax, ymin,
ymax)
coord. ref. : +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84
+towgs84=0,0,0
variables   : 13
names   : OBJECTID, ID_0, ISO,   NAME_0, ID_1,NAME_1, HASC_1,
CCN_1, CCA_1, TYPE_1, ENGTYPE_1, NL_NAME_1,   VARNAME_1
min values  :1,  227, TZA, Tanzania,1,Arusha,  TZ.AS,
 NA,01,   Mkoa,Region,  ,
max values  :9,  227, TZA, Tanzania,9, Zanzibar West,  TZ.ZW,
 NA,55,   Mkoa,Region,  , Mjini Magharibi

[[2]]
class   : SpatialPolygonsDataFrame
features: 58
extent  : 29.5715, 35.00027, -1.48214, 4.234466  (xmin, xmax, ymin,
ymax)
coord. ref. : +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84
+towgs84=0,0,0
variables   : 13
names   : OBJECTID, ID_0, ISO, NAME_0, ID_1,   NAME_1, HASC_1, CCN_1,
CCA_1, TYPE_1,  ENGTYPE_1, NL_NAME_1, VARNAME_1
min values  :1,  239, UGA, Uganda,1, Adjumani,   ,NA,
   ,   District,   District,  ,
max values  :9,  239, UGA, Uganda,9,Yumbe,  UG.YU,NA,
 41, Water body, Water body,  ,   Luweero

[[3]]
class   : SpatialPolygonsDataFrame
features: 10
extent  : -3.255419, 1.19177, 4.738751, 11.1733  (xmin, xmax, ymin,
ymax)
coord. ref. : +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84
+towgs84=0,0,0
variables   : 13
names   : OBJECTID, ID_0, ISO, NAME_0, ID_1,  NAME_1, HASC_1, CCN_1,
CCA_1, TYPE_1, ENGTYPE_1, NL_NAME_1, VARNAME_1
min values  :1,   87, GHA,  Ghana,1, Ashanti,  GH.AA,NA,
   , Region,Region,  ,
max values  :9,   87, GHA,  Ghana,9, Western,  GH.WP,NA,
   , Region,Region,  ,

>

I'm a little puzzled as well, but "TZA", "UGA" & "GHA" seem to have found
their way to min/max values and presumably this is as it should be.
Chris





On Fri, Jul 22, 2016 at 11:55 PM, Bacou, Melanie  wrote:

> Hi,
> I'm getting weird results trying to rbind a list of
> SpatialPolygonsDataFrames with R 3.2.1 and raster 2.5.8. I believe the code
> below used to merge all 3 country boundaries, but instead I now get a list
> with 6 elements (incl. 3 logical TRUE). Am I doing something wrong?
>
> Thx, --Mel.
>
> > library(raster)
> > m <- lapply(c("TZA", "UGA", "GHA"), function(x) getData("GADM",
> country=x, level=1))
> > m <- rbind(m, makeUniqueIDs=T)
> > sapply(m, class)
> [1] "SpatialPolygonsDataFrame" "logical" "SpatialPolygonsDataFrame"
> [4] "logical"  "SpatialPolygonsDataFrame" "logical"
>
> > sessionInfo()
> R version 3.2.1 (2015-06-18)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
>
> locale:
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
> States.1252
> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods base
>
> other attached packages:
> [1] raster_2.5-8 sp_1.2-3 rj_2.0.5-2
>
> loaded via a namespace (and not attached):
> [1] rj.gd_2.0.0-1   Rcpp_0.12.6 grid_3.2.1 lattice_0.20-33
>
> --
> Melanie BACOU
> International Food Policy Research Institute
> Snr. Program Manager, Spatial Data and Analytics
> Work   +1(202)862-5699
> E-mail m.ba...@cgiar.org
> Visit  www.harvestchoice.org
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Simple features for R, part 2

[chris english]

Edzer,

I especially appreciate it is all S3 and can be heterogeneous under
'geometrycollection'.  Tests, of course, are important and
having fully fledged GEOS (though this may have to, eventually, cede to
something like CGAL if the drive is additionally to 3+d).
As to dimentionality (3d+) in GDAL-land, Frank and now Evan have been
implementing variations for the past 10 years, even as
4dim gets expressed as 3dim, it doesn't error. So perhaps is is a function
of post-processing after GDAL for achieving higher dimensionality for
visualizatioin
and other purposes. So now to become an adept at lists of sets of lists.
Just wish I'd noticed this a little while ago.

Chris English

On Mon, Jul 18, 2016 at 10:10 AM, Edzer Pebesma <
edzer.pebe...@uni-muenster.de> wrote:

> There's a second blog post on the ISC project "Simple features for R",
> describing progress up to date and planned future steps, at:
>
> http://r-spatial.org/r/2016/07/18/sf2.html
>
> Comments are welcome!
> --
> 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/
> Spatial Statistics Society http://www.spatialstatistics.info
>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Announcing the R Shapefile Contest

[chris english]

İ have less brilliant analysis but tend like others to think that the
future may not/should not shape up as shapefiles.

Chris
On Jul 13, 2016 20:44, "Barry Rowlingson" 
wrote:

> On Wed, Jul 13, 2016 at 4:22 PM,   wrote:
> > Hi everyone,
> >
> > I wanted to let people here know that I am sponsoring the "R Shapefile
> > Contest":
> >
> >
> http://www.arilamstein.com/blog/2016/07/12/announcing-r-shapefile-contest/
> >
> > For the last few years I've done a lot of work with creating choropleth
> > maps of government datasets. But I've also felt a bit limited, in that I
> > don't know the full range of analyses that R can do with shapefiles.
> >
> > I'm hoping that this contest can get a lot of submissions which really
> show
> > off the types of analyses that can be done with R and shapefiles.
>
>  I have a brilliant analysis I would have loved to submit to this
> contest but the agency from which I got the data has been enlightened
> enough not to use the clunky, outdated, and limited "shapefile" format
> and has released the data as a modern, OGC-standard GeoPackage. My
> variables have long names, my metadata is stored with my data, and its
> all in one file instead of six. But sadly, because you limit the
> contest with "The analysis must ... do something with a shapefile" I
> can't compete.
>
>  Shapefiles are an awful, awful format which Esri didn't think people
> would actually use. They should not be encouraged. Maybe I'll start a
> GeoPackage contest. Or you could just have a geospatial vector data
> contest and not discriminate against data formats.
>
> Barry
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Minimum bounding circle from cluster of points (Tina Cormier)

[chris english]

Mel,

Not a full implementation, but indicator of how one might do,
https://rforge.net/rcgal/git.html, that Simon Urbanek styles : rcgal - R
interface to a (small) subset of CGAL,
and has inside (function) that takes arbitrary shape files and x/y to say
inside or not.

CGAL is a darn fine library and I guess you'd pick and choose which parts
you'd wrap for your purposes.

Chris

On Sun, Jul 10, 2016 at 3:50 AM, Bacou, Melanie  wrote:

> Interesting problem, it seems the exact approach is given by Fischer, 2003
> and is implemented in a C++ CGAL package (see
> http://stackoverflow.com/questions/9063453/how-to-compute-the-smallest-bounding-sphere-enclosing-other-bounding-spheres
> ).
>
> I haven't found any binding for R, but there's an implementation in
> PostGIS `ST_MinimumBoundingCircle()` (see
> http://postgis.net/docs/ST_MinimumBoundingCircle.html).
>
> Others might be more up to date.
> --Mel.
>
>
>
> On 7/9/2016 6:38 AM, Adrian Baddeley wrote:
>
>> Tina Cormier  wrote:
>>
>> I'd like to create a circle around each cluster that is
>>> the smallest circle that would encompass all 4 points.
>>>
>> The circumcircle.
>>
>> Try the following:
>>
>> <
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo>library(spatstat)
>>
>> circumcircle <- function(x, ...) {   UseMethod("circumcircle") }
>>
>> circumcircle.owin <- function(x, ...) {
>>d2 <- fardist(x, ..., squared=TRUE)
>>z <- where.min(d2)
>>r <- sqrt(min(d2))
>>w <- disc(centre=z, radius=r)
>>return(w)
>> }
>>
>> circumcircle.ppp <- function(x, ...) {
>>circumcircle(convexhull(x))
>> }
>>
>>
>> Adrian Baddeley
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] [off-topic] Raster Distance

[chris english]

Jefferson,

This won't help with ArcGis Euclidean Distance directly, but this link is
to unit test for the gdal proximity algorithm.

https://trac.osgeo.org/gdal/browser/branches/2.1/autotest/alg/proximity.py

Playing around with this and known values, and then with Arc Euclidean
Distance might be a way to ascertain if they're approached the same.

Just a thought.
Chris
On Jun 24, 2016 16:49, "Jefferson Ferreira-Ferreira" 
wrote:

> Dear listers!
>
> Sorry by this off-topic.
> I have an open question on GIS StackExchange: Is there any difference
> between gdal_proximity.py and ArcGIS Euclidean Distance?
> <
> http://gis.stackexchange.com/questions/199735/is-there-any-difference-between-gdal-proximity-py-and-arcgis-euclidean-distance
> >
> If someone can help to answer it, I would be grateful.
>
> Thanks a lot.
>
> *Jefferson Ferreira-Ferreira, **PhD Candidate *
>
> *Geographer*
>
>
>
> *Ecosystem Dynamics Observatory  -
> EcoDyn/UNESP*
> *Department of **Geography *
> *Institute of Geosciences and Exact Sciences** (IGCE)*
> *São Paulo State University (UNESP)*
> *Rio Claro, SP - Brazil*
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Spatio Temporal kriging in Gstat

[chris english]

Daniel,

You get no complaints on creating st:

st=STSDF(sp,time,data,index,endTime=delta(time))

class(st) should show "STSDF".

It remains that x$np is pointing at nothing when you get to
sample.STvariogram.

I'd type:
>sample.STvariogram to try and work out what it is actually doing.

Then try debugonce(sample.STvariogram) to see what values are in my
environment.

It may be that index isn't doing what you hope, ie to indicate non-NA
values.

And as usual I could be wrong on all counts.

Chris
On Jun 21, 2016 4:12 AM, "Dan Turenne"  wrote:

My apologies, I accidentally sent an unfinished email, here is the complete
version of my question


Hello R-Sig-Geo,


As part of my masters thesis I am attempting to use spatio-temporal
regression kriging to make predictions with temperature data, and I was
hoping that someone might be able to give some insight as to how the
algorithms work in gstat.  My data consists of daily temperature
observations from April 1 to July 31, 2000.  There are observations from
164 stations across these 122 days, however not all stations have
observations on all days, making for a total of 19282 records.


I have tried to use an STSDF object but I have not had any success.  I
created an sp object of length 164 with the station locations:


sp = data.frame(long = stations$long, lat = stations$lat)

coordinates(sp) = ~ long+lat


Then I created a vector of length 122 with the times the observations were
recorded and a data vector of length 19282:


beginDate = as.Date(2000/04/01)

endDate = as.Date(2000/07/31)

times = as.POSIXct(seq(beginDate,endDate,by="days"))


data=data.frame(temps$residual)


And I also made an index detailing where observations are available, it
looks like this with the first column representing spatial index and the
second representing the time index


1   1

2   1

3   1

4   1


st=STSDF(sp,time,data,index,endTime=delta(time))


however when I try to calculate the sample variogram I get the following
error:


sample.stVariogram=variogramST(residual~1,data=st, tunit="days",
tlags=1:7, progress=TRUE)



   Error in apply(do.call(cbind, lapply(ret, function(x) x$np)), 1, sum,  :
   dim(X) must have a positive length
   In addition: There were 50 or more warnings (use warnings() to see the
first 50)


All 50 of the errors are :


  In is.na(data[[as.character(as.list(formula)[[2]])]]) :
   is.na() applied to non-(list or vector) of type 'NULL'


Can anyone see what I am doing wrong or give me any pointers?  This error
is rather cryptic and I'm not quite sure what I'm doing wrong.  Any help
would be appreciated.


Many Thanks,

Daniel Turenne

University of Manitoba


[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Building a prediction raster when the statistical model was built from sampling units of different sizes

[chris english]

I have requested another environmental data scientist  to look at this
thread of conversation as he is better versed in your area of science and
my comments may have been ill-informed or confused /confusing or worse,
both.

But now I understand your research interest, likelihood of disease vector
instances (among striped skunks) given land cover. Is the disease rabies or
some other ailment of concern? I just ask because if rabies, there could be
a large, healthy population given proper resources to sustain them, without
necessarily indicating an areal propensity to rabies. Keeping with rabies
though, you might find you are exploring extremes (here meaning very, very
few are disease vectors) as against general additive models, hence lots of
skunks and relatively very few vectors. Combined in some way that I have
yet to think through, GAM and extreme might lead to the environment more
likely to produce vectors.

So, lets throw land cover under the bus for the moment as it is probably
immaterial, same for area, and ask what environmental conditions are more
likely to generate the vectors of interest, whatever the particular disease
condition is. This indeed would be an interesting study.

Chris
On Jun 9, 2016 18:38, "Nelly Reduan" <nell.r...@hotmail.fr> wrote:

> Hi Chris,
>
>
>
> Thank you very much for your answer. My objective is to build a predictive
> map of capture success of striped skunks at large scale in order to
> delineate areas of high abundance of striped skunks that are susceptible to
> promote disease transmission. My GAM was used to assess the relationship
> between proportions of land cover types and capture success within trapping
> sites. Then, I estimated a capture success value within homogeneous grid
> cells of 2km x 2km from my GAM that was built from capture success data
> associated with trapping sites of different sizes. I also think that the
> approach is quite problematic. So, I am trying to view whether or not there
> are solutions to minimize bias in the predictions.
>
>
>
> Thank you very much for your time.
>
> Have a nice day.
>
> Nell
>
> --
> *De :* chris english <englishchristoph...@gmail.com>
> *Envoyé :* mardi 7 juin 2016 23:41:09
> *À :* Nelly Reduan
> *Cc :* Help R-Sig_Geo
> *Objet :* Re: [R-sig-Geo] Building a prediction raster when the
> statistical model was built from sampling units of different sizes
>
> Nell,
>
> I'm still trying to understand what sounds to me like an embedded data
> reduction. Please understand, I don't trap skunks (striped or otherwise). I
> have, on many occasions, observed them in the wild but I am cautious not to
> make them scared due to the known, smelly results.
>
> Understand as well that I am not versed in capture success, per se, I just
> examine data and wonder if it contains generalizable or perhaps surprising
> properties.
>
> So if it were me, contrary to my nature and practice of observation,
> trapping striped skunks in a 24 km^2 study area of a given land use/land
> cover, and I trapped 15 skunks over a period of 2 months, I would deem that
> 15 observations for that study area/time period.If, in my 32 km^2 study
> area of slightly different land cover and different resource availability I
> got 70 in two months, I'd have 70 observations. This is how I would view
> it, and quite probably within the accepted science I would be going about
> it all wrong.
>
> As you present the matter, at least as I understand it, the number of my
> hypothetical captures always reduces to one dimension (the study area),
> irrespective of the above variance between study areas. This approach
> puzzles me as it seems that information about desirable resource
> distribution (from the point of view of the skunk) gets lost, and 'capture
> success' becomes murky, at least for me.
>
> As my wife always says, "It depends on what the research question is."
>
> What is the research question in this case?
>
> My apologies to you and capture science if I have completely misunderstood
> as I all too often do.
>
> Chris
>
> On Tue, Jun 7, 2016 at 5:53 PM, Nelly Reduan <nell.r...@hotmail.fr> wrote:
>
>> Hi Chris,
>>
>> Thank you very much for your answer.
>>
>>
>> They are striped skunks that have been captured. In my data, all striped
>> skunks that have been captured within a same trapping site have the same
>> capture success. Thus, each of 50 trapping sites was assigned to one
>> capture success. If, I group trapping sites together, I reduce the sampling
>> size. As the actuel sampling size (50 trapping sites) is rather small, can
>> this cause problem for predicted data estimates?
>>
>> Thanks very much for you

Re: [R-sig-Geo] Building a prediction raster when the statistical model was built from sampling units of different sizes

[chris english]

Nell,

I'm still trying to understand what sounds to me like an embedded data
reduction. Please understand, I don't trap skunks (striped or otherwise). I
have, on many occasions, observed them in the wild but I am cautious not to
make them scared due to the known, smelly results.

Understand as well that I am not versed in capture success, per se, I just
examine data and wonder if it contains generalizable or perhaps surprising
properties.

So if it were me, contrary to my nature and practice of observation,
trapping striped skunks in a 24 km^2 study area of a given land use/land
cover, and I trapped 15 skunks over a period of 2 months, I would deem that
15 observations for that study area/time period.If, in my 32 km^2 study
area of slightly different land cover and different resource availability I
got 70 in two months, I'd have 70 observations. This is how I would view
it, and quite probably within the accepted science I would be going about
it all wrong.

As you present the matter, at least as I understand it, the number of my
hypothetical captures always reduces to one dimension (the study area),
irrespective of the above variance between study areas. This approach
puzzles me as it seems that information about desirable resource
distribution (from the point of view of the skunk) gets lost, and 'capture
success' becomes murky, at least for me.

As my wife always says, "It depends on what the research question is."

What is the research question in this case?

My apologies to you and capture science if I have completely misunderstood
as I all too often do.

Chris

On Tue, Jun 7, 2016 at 5:53 PM, Nelly Reduan <nell.r...@hotmail.fr> wrote:

> Hi Chris,
>
> Thank you very much for your answer.
>
>
> They are striped skunks that have been captured. In my data, all striped
> skunks that have been captured within a same trapping site have the same
> capture success. Thus, each of 50 trapping sites was assigned to one
> capture success. If, I group trapping sites together, I reduce the sampling
> size. As the actuel sampling size (50 trapping sites) is rather small, can
> this cause problem for predicted data estimates?
>
> Thanks very much for your time.
>
> Have a nice day.
>
> Nell
>
>
> --
> *De :* chris english <englishchristoph...@gmail.com>
> *Envoyé :* jeudi 2 juin 2016 06:10:32
> *À :* Nelly Reduan
> *Cc :* Help R-Sig_Geo
> *Objet :* Re: [R-sig-Geo] Building a prediction raster when the
> statistical model was built from sampling units of different sizes
>
>
> Hi Nell,
>
> Just a couple of questions. Trapping sites range from 24km^2 - 236km^2,
> and there are 50 such sites, looking at the 50 sites might there be a way
> to bin them reasonably into trap area groups?
>
> Your 50 observations suggests one thing was trapped and thereafter
> trapping was discontinued. Is this correct?
>
> And just for general information, what was being trapped?
>
> Sticking closer to your data, you might consider GAM(ing) the bins and
> summing the resultant GAMs. Need to think some more on the predictive
> raster aspect. Sorry for an essentially inconclusive answer.
>
> Chris
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] gdistance transition objects: dealing with NAs in source cost raster

[chris english]

Toby,

I've only just installed Jacob's gdistance package and don't know as yet
the underlying assumptions nor the, what I will term 'services', his
package offers. Were I in your position, having my DEM, and knowing what
you already know about using gdistance, I would swap out my sea NA(s) for
0.0(s), in my case probably using GDAL, and see how things went thereafter.

Jacob will have a much better suggestion, but basically it seems like
'package x doesn't like my data, so I'll make my data more consumable for
package x'. Wish I could be of more help but I'm playing in a different
distance space than Hausdorf and probably shouldn't comment further, except
as to what I'd try to finagle as to my DEM.

Chris

On Thu, Jun 2, 2016 at 7:28 PM, T C Wilkinson <o...@tobywilkinson.co.uk>
wrote:

> Dear Chris, dear Jacob,
>
> Many thanks indeed for suggestions and help.
>
> 1. The input raster (dem) definitely shows NA in the areas of sea using
> click().
>
> 2. Tried the 0.0 in the ifelse: no luck, same result.
>
> I tried plotting and clicking for the values of the initial `slope`
> TransitionLayer: here the area of the sea reports as a value of NaN, so
> perhaps the problem is not in the transition function, but in the later
> conversion of slope to cost (in sw_conductance).
>
> I tried changing adjacent() to adjacencyFromTransition(), which does
> indeed result in the sea being plotted as NA (or presumably NaN), but the
> values of the conductance on land now don’t seem correct (i.e. some areas
> that I know are flat are shown as relatively lower conductance than areas
> which are sloping).
>
> Any ideas?
>
> Thank you again,
> Toby
>
>
>
> sw_slope <- function(dem, dirs=16, symm=FALSE){
>   # calculate the altitudinal differences between cells:
>   #altDiffFunction <- function(x){x[2] - x[1]}
>   # with a little help from Jacob van Etten and Chris English:
>   altDiffFunction <- function(x){ifelse(((!is.na(x[2])) & (!is.na(x[1]))),
> (x[2] - x[1]), 0.0)}
>
>   heightDiff <- transition(dem, altDiffFunction, directions=dirs,
> symm=symm)
>   #divide by the distance between cells
>   slope <- geoCorrection(heightDiff)
>   return(slope)
> }
>
> slope <- sw_slope(dem)
> plot(raster(slope))
> click(raster(slope))
>
> sw_conductance <- function(dem, dirs=16, symm=FALSE){
>   #first find slope
>   slope <- sw_slope(dem, dirs, symm)
>
>   #create an index for adjacent cells (adj) with the function adjacent
>   #adj <- adjacent(dem, cells=1:ncell(dem), pairs=TRUE, directions=16)
>   adj <- adjacencyFromTransition(slope)
>   cost <- slope
>
>   #extract and replace adjacent cells
>   #note the 1/ to convert from resistivity (as cited in publication above)
> to conductivity
>   cost[adj] <- 1 / 1337.8 * cost[adj]^6) + (278.19 * cost[adj]^5) -
> (517.39 * cost[adj]^4) - (78.199 * cost[adj]^3) + (93.419 * cost[adj]^2) +
> (19.825 * cost[adj]) + 1.64)))
>
>   #correction to take account of distance between cell centres
>   gc <- geoCorrection(cost)
>
>   return(gc)
> }
>
> plot(raster(sw_conductance(dem))
>
>
>
> On 2 June 2016 at 14:29:42, chris english (englishchristoph...@gmail.com)
> wrote:
> > Toby,
> >
> > This may seem silly, and a thousandth of something is not zero, but
> perhaps
> > this is a kind of preallocation issue and using Jacob's if else with 0.0
> > as else might do the trick.
> >
> > Fingers crossed?
> > Chris
> > On Jun 2, 2016 16:07, "T C Wilkinson" wrote:
> >
> > > Dear Jacob,
> > >
> > > Many thanks for fast reply. [Apologies for the typo and potential
> > > confusion on gdistance, I am still relative new to R — and thus
> borrowing
> > > camelCase habit from previous coding.]
> > >
> > > I’ve tried your suggested re-worked function to avoid NA in the
> > > transition, but I still get the same result.
> > >
> > > When plotted, the `plot(raster(conductance))` still colours the sea
> (i.e.
> > > doesn’t show it in the colNA colour) and the resultant accCosts etc
> include
> > > the sea as part of the result surface.
> > >
> > > An interactive `click(raster(conductance))` reveals the sea to be a
> > > uniform value of 0.001436461.
> > >
> > > Thanks again,
> > > Toby
> > >
> > >
> > >
> > > On 2 June 2016 at 12:30:43, Jacob van Etten (jacobvanet...@yahoo.com)
> > > wrote:
> > > > Dear Toby,
> > > > TransitionLayers should normally not hold NA values. If you want to
> set
> > > cell connections
> > > > to z

Re: [R-sig-Geo] gdistance transition objects: dealing with NAs in source cost raster

[chris english]

Toby,

This may seem silly, and a thousandth of something is not zero, but perhaps
this is  a kind of preallocation issue and using Jacob's if else with 0.0
as else might do the trick.

Fingers crossed?
Chris
On Jun 2, 2016 16:07, "T C Wilkinson"  wrote:

> Dear Jacob,
>
> Many thanks for fast reply. [Apologies for the typo and potential
> confusion on gdistance, I am still relative new to R — and thus borrowing
> camelCase habit from previous coding.]
>
> I’ve tried your suggested re-worked function to avoid NA in the
> transition, but I still get the same result.
>
> When plotted, the `plot(raster(conductance))` still colours the sea (i.e.
> doesn’t show it in the colNA colour) and the resultant accCosts etc include
> the sea as part of the result surface.
>
> An interactive `click(raster(conductance))` reveals the sea to be a
> uniform value of 0.001436461.
>
> Thanks again,
> Toby
>
>
>
> On 2 June 2016 at 12:30:43, Jacob van Etten (jacobvanet...@yahoo.com)
> wrote:
> > Dear Toby,
> > TransitionLayers should normally not hold NA values. If you want to set
> cell connections
> > to zero conductance, the transitionFunction should give a value zero if
> it finds an NA.
> > Your function gives an NA as result, which is not what you want:
> > ifelse(((!is.na(x[2])) & (!is.na(x[1]))),(x[2] - x[1]),NA)
> >
> > You probably want to do:
> > ifelse(((!is.na(x[2])) & (!is.na(x[1]))), (x[2] - x[1]), 0)
> >
> > Also, note that gDistance is not the name of the package.
> > Best,
> > Jacob
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Building a prediction raster when the statistical model was built from sampling units of different sizes

[chris english]

Hi Nell,

Just a couple of questions. Trapping sites range from 24km^2 - 236km^2, and
there are 50 such sites, looking at the 50 sites might there be a way to
bin them reasonably into trap area groups?

Your 50 observations suggests one thing was trapped and thereafter trapping
was discontinued. Is this correct?

And just for general information, what was being trapped?

Sticking closer to your data, you might consider GAM(ing) the bins and
summing the resultant GAMs. Need to think some more on the predictive
raster aspect. Sorry for an essentially inconclusive answer.

Chris

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] gDistance transition objects: dealing with NAs in source cost raster

[chris english]

Toby,

Jacob van Etten's package is "gdistance", as distinct from
rgeos:::gDistance that also gets discussed here.
Just for clarity.

Chris

On Thu, Jun 2, 2016 at 2:30 PM, Jacob van Etten via R-sig-Geo <
r-sig-geo@r-project.org> wrote:

> Dear Toby,
> TransitionLayers should normally not hold NA values. If you want to set
> cell connections to zero conductance, the transitionFunction should give a
> value zero if it finds an NA.
> Your function gives an NA as result, which is not what you want:
> ifelse(((!is.na(x[2])) & (!is.na(x[1]))),(x[2] - x[1]),NA)
>
> You probably want to do:
> ifelse(((!is.na(x[2])) & (!is.na(x[1]))), (x[2] - x[1]), 0)
>
> Also, note that gDistance is not the name of the package.
> Best,
> Jacob
>
> On Thursday, 2 June 2016, 4:24, T C Wilkinson <
> o...@tobywilkinson.co.uk> wrote:
>
>
>  Dear all,
>
> I’m using two functions (copied below, based on Jacob van Etten’s own
> documentation for distance) in order to construct the required transition
> objects for use in gDistance functions such as shortestPath and accCost,
> using an input DEM (digital elevation model).
>
> The particular DEM I am using includes an area of sea which is marked as
> NA and, for my particular analyses, should be ignored (i.e. should be
> modelled as 0 conductance) in the distance calculations.  My assumption was
> that these functions would ignore the area of NA-marked sea by default (in
> part because the equivalent Arc- models exclude NoData areas).
>
> However, a plot of the transition as raster `plot(raster(conductance))`
> suggests the sea is included as a low-level conductance (it appears as pink
> from the col.palette and not black as specified in colNA field).
> Similarly, subsequently-created accCost rasters include the sea as part of
> the accumulate cost surface and not, as I hoped, as NA.
>
> I tried a different altDiffFunction, in an attempt to exclude the NA
> values, but I suspect this is merely a less elegant method of producing the
> same result.
>
> Whilst I wondered if some kind of transitionStack might solve the problem,
> my (albeit limited) understanding of the way gDistance transition layers
> work suggest that this is overkill for what is essentially a
> single-variable (slope) function.
>
> Does the resolution of the DEM play any role here?
>
> Any suggestions for how to solve this (i.e. how to exclude the NA area
> from the transition model) would be very gratefully received!
>
> Many thanks,
> Toby
>
>
>
>
> **CODE EXTRACT**:
>
> sw_slope <- function(dem, dirs=16, symm=FALSE){
>   #calculate the altitudinal differences between cells
>   #altDiffFunction <- function(x){x[2] - x[1]}
>   altDiffFunction <- function(x){
> return(ifelse(((!is.na(x[2])) & (!is.na(x[1]))),(x[2] - x[1]),NA))
>   }
>
>   heightDiff <- transition(dem, altDiffFunction, directions=dirs,
> symm=symm)
>   #divide by the distance between cells
>   slope <- geoCorrection(heightDiff)
>   return(slope)
> }
>
>
>
> sw_conductance <- function(dem, dirs=16, symm=FALSE){
>   #first find slope
>   slope <- sw_slope(dem, dirs, symm)
>
>   #create an index for adjacent cells (adj) with the function adjacent
>   adj <- adjacent(dem, cells=1:ncell(dem), pairs=TRUE, directions=16)
>   cost <- slope
>
>   #extract and replace adjacent cells
>   #note the 1/ to convert from resistivity (as cited in publication above)
> to conductivity
>   cost[adj] <- 1 / 1337.8 * cost[adj]^6) + (278.19 * cost[adj]^5) -
> (517.39 * cost[adj]^4) - (78.199 * cost[adj]^3) + (93.419 * cost[adj]^2) +
> (19.825 * cost[adj]) + 1.64)))
>
>   #correction to take account of distance between cell centres
>   gc <- geoCorrection(cost)
>
>   return(gc)
> }
>
>
> dem <- raster() # the dem, based on an reprojected aster gdem tile, is
> loaded from file
>
> conductance <- sw_conductance(dem)
>
> plot(raster(conductance),
>col = col.palette,
>colNA = "black",
>   )
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

Progress has certainly been made regards MODIS.

 > sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C

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

other attached packages:
[1] MODIS_0.10-34  raster_2.5-2   sp_1.2-3   devtools_1.9.1

loaded via a namespace (and not attached):
[1] rsconnect_0.4.1.11 tools_3.2.2Rcpp_0.12.5
memoise_0.2.1  grid_3.2.2
[6] digest_0.6.8   lattice_0.20-33

Thomas Nauss, University of Marburg, examined the problem and proposed
a fix (https://github.com/MatMatt/MODIS/issues/5). It has not actually
been applied to the 'develop' branch currently the MODIS_0.10-34. But
cloning the develop branch and editing minorFuns.R with his suggested
fix and doing a local install from source gives me:

> install.packages("/home/chris/MODIS_tst/MODIS", repos = NULL, type = "source")
> require(MODIS)
Loading required package: MODIS
Loading required package: raster
Loading required package: sp
MODIS_manual: 
https://ivfl-rio.boku.ac.at/owncloud/public.php?service=files=660dc830afb091237cc40b3dea2fdf6b


Attaching package: ‘MODIS’

The following object is masked from ‘package:base’:

file.size

> MODISoptions()
All suggested packages are installed
Detecting available write drivers!
Found: 64 candidate drivers, detecting file extensions...
44 usable drivers detected!

This is a darn sight better than zero drivers.

STORAGE:
___
localArcPath : /home/chris/MODIS_ARC
outDirPath   : /home/chris/MODIS_ARC/PROCESSED


DOWNLOAD:
___
MODISserverOrder : LPDAAC, LAADS
dlmethod : auto
stubbornness : high


PROCESSING:
___
GDAL   : GDAL 2.1.0dev, released 2015/99/99
MRT: Version 4.1 (March 2011)
pixelSize  : asIn
outProj: asIn
resamplingType : NN
dataFormat : GTiff

Returning to Hakim's initial post:

> dates <- as.POSIXct( as.Date(c("01/01/2010","01/05/2016"),format ="%d/%m/%Y") 
> )
> dates <- transDate(dates[1],dates[2])
> product <- "MOD13Q1"
> bands <- "010"
> h = c("21","22")
> v = c("07","08")
> runGdal(product=product,begin=dates$beginDOY,end = dates$endDOY,tileH =
+ h,tileV = v, SDSstring = bands, outProj="4326")
Loading required package: rgdal
rgdal: version: 1.1-3, (SVN revision 594)
 Geospatial Data Abstraction Library extensions to R successfully loaded
 Loaded GDAL runtime: GDAL 2.1.0dev, released 2015/99/99
 Path to GDAL shared files: /usr/local/share/gdal
 Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491]
 Path to PROJ.4 shared files: (autodetected)
WARNING: no proj_defs.dat in PROJ.4 shared files
 Linking to sp version: 1.2-1
Loading required package: rgeos
rgeos version: 0.3-15, (SVN revision 515)
 GEOS runtime version: 3.4.2-CAPI-1.8.2 r3921
 Linking to sp version: 1.2-1
 Polygon checking: TRUE


NOTE: rgdal::checkCRSArgs: no proj_defs.dat in PROJ.4 shared files
outProj  =  +init=epsg:4326 +proj=longlat +datum=WGS84
+no_defs +ellps=WGS84 +towgs84=0,0,0
pixelSize=  asIn
resamplingType   =  near
Output directory =
/home/chris/MODIS_ARC/PROCESSED/MOD13Q1.005_20160525005632  (no 'job'
name specified, generated (date/time based))

Loading required package: RCurl
Loading required package: bitops
Downloading structure on 'LPDAAC' for: MOD13Q1.005
Try: 1
Error in if (FtpDayDirs[1] == FALSE) { :
  missing value where TRUE/FALSE needed

Hummph.  Well, I'm very happy to have drivers. Uncertain if my 64
candidates vs 44 represents additional name changes as Thomas
suggested and the 44 apply to his fix and an additional 20 are
differences between Frank's and Evan's naming conventions as to those
other 20. And uncertain as to how to ask MODIS which 44 are viable vs
20 that were not viable, though this would probably be useful.

It appears, given Hakim's request code, that he won't be getting MODIS
data as Error after Try: 1 suggests a certain lack of stubbornness or
further problem. Nor will I of course.  I tried a debugonce(runGdal),
but the implications of the runGdal() are substantially above and
beyond my pay grade and current level in R.

So back to eyetracking data and Bagidis semi distances. I'm sure MODIS
will be sorted out by those more familiar with expected results.

Chris

On Thu, May 19, 2016 at 1:31 PM, chris english
<englishchristoph...@gmail.com> wrote:
> Playing with MODISoptions.R lines 155-162:
>
>> gdalPath = '/usr/local/bin

Re: [R-sig-Geo] How the "gSymdifference" of rgoes package calculating the symmetric distance between two polygon

[chris english]

Hi Kaushik,

Strictly speaking that is the R code that is calling another library GEOS,
originally implemented in Java, and ported to c++. Poking around in your
GEOS library may lead to area gSimdifference. If there were developer
issues or discussions regarding implementation of area and Simdifference,
googling Sandro Santilli and the term of interest might prove useful.
HTH,
Chris

On Mon, May 2, 2016 at 11:03 AM, Kaushik Jana 
wrote:

> Dear all,
>
> I want to calculate the symmetric distance between two polygon. I learned
> that "gSymdifference" and "gArea" of "rgoes" can be used for that purpose.
> But I am not getting how this difference is calculated (what are R-codes).
>
> The code I am getting by straight forward typing the "gSymdifference" is
> giving me:
> function (spgeom1, spgeom2, byid = FALSE, id = NULL, drop_lower_td = FALSE,
> unaryUnion_if_byid_false = TRUE, checkValidity = FALSE)
> {
> if (checkValidity) {
> val1 <- gIsValid(spgeom1)
> val2 <- gIsValid(spgeom2)
> if (!val1)
> message(deparse(substitute(spgeom1)), " is invalid")
> if (!val2)
> message(deparse(substitute(spgeom2)), " is invalid")
> if (!all(c(val1, val2)))
> stop("Invalid objects found")
> }
> return(RGEOSBinTopoFunc(spgeom1, spgeom2, byid, id, drop_lower_td,
> unaryUnion_if_byid_false, "rgeos_symdifference"))
> }
> 
>
> The above is not helping for this purpose. Where from I can get the codes
> of the functions and get to know how the "gSymdifference" and "gArea" is
> calculating the difference?
>
> Thanks a lot for your time.
>
> Sincerely,
>
> Kaushik
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

Playing with MODISoptions.R lines 155-162:

> gdalPath = '/usr/local/bin' # take out correctPath as can't find where
defined at present ln 157
> if(length(grep(dir(gdalPath),pattern="gdalinfo"))==0)
+ {
+ stop(paste0("The 'gdalPath' you have provided
'",normalizePath(gdalPath,"/",FALSE) ,
+ "' does not contain any gdal utilities, make sure to address the
+ folder with GDAL executables (ie: gdalinfo)!"))
+ }
>

The preceding executes without complaint or stop as gdalinfo was found in
/usr/local/bin to have length >0.


>gdalDrivers()

47 GTiff  GeoTIFF   TRUE  TRUEFALSE

51  HDF4Image HDF4 Dataset   TRUE FALSEFALSE

We have the necessary drivers. Hard coding MODIS_Opts.R gdalPath doesn't
work. Ah well.


On Thu, May 19, 2016 at 7:10 AM, chris english <
englishchristoph...@gmail.com> wrote:

> Logging out (Log out?!?, do people still do that?), which is mentioned in
> the manual, though actually means more than closing and opening a new
> terminal, actually restarting the kernel, results in system update where
> after MRT is recognized but still, in my case, drivers are not:
>
> >library(MODIS)
> > MODISoptions()
> All suggested packages are installed
> Detecting available write drivers!
> Found: 64 candidate drivers, detecting file extensions...
> ERROR 1: --format option given with format 'VRT-raster-', but that format
> not
> recognised.  Use the --formats option to get a list of available formats,
> and use the short code (ie. GTiff or HFA) as the format identifier.
>
> ERROR 1: --format option given with format 'GTiff-raster-', but that
> format not
> recognised.  Use the --formats option to get a list of available formats,
> and use the short code (ie. GTiff or HFA) as the format identifier.
>
> 0 usable drivers detected!
>
> STORAGE:
> ___
> localArcPath : /home/chris/MODIS_ARC
> outDirPath   : /home/chris/MODIS_ARC/PROCESSED
>
>
> DOWNLOAD:
> ___
> MODISserverOrder : LPDAAC, LAADS
> dlmethod : auto
> stubbornness : high
>
>
> PROCESSING:
> ___
> GDAL   : GDAL 2.1.0dev, released 2015/99/99
> MRT: Version 4.1 (March 2011)
> pixelSize  : asIn
> outProj    : asIn
> resamplingType : NN
> dataFormat : GTiff
>
>
> DEPENDENCIES:
> ___
>
>
> >
> So, a little more digging.
> Chris
>
>
> On Wed, May 18, 2016 at 2:13 PM, chris english <
> englishchristoph...@gmail.com> wrote:
>
>> Hakim,
>> Your installation and mine share the same defect:
>>
>> > MODIS:::checkGdalDriver()
>> [1] TRUE
>> > MODIS:::checkGdalDriver(GTiff)
>> Error in correctPath(path) : object 'GTiff' not found
>> > MODIS:::checkGdalDriver
>> function (path = NULL)
>> {
>> inW <- getOption("warn")
>> on.exit(options(warn = inW))
>> options(warn = -1)
>> path <- correctPath(path)
>> cmd <- paste0(path, "gdalinfo --formats")
>> if (.Platform$OS == "windows") {
>> driver <- try(shell(cmd, intern = TRUE), silent = TRUE)
>> }
>> else {
>> driver <- try(system(cmd, intern = TRUE), silent = TRUE)
>> }
>> if (class(driver) == "try-error") {
>> options(warn = inW)
>> warning("No gdal installation found please install 'gdal' on your
>> system first!")
>> return(FALSE)
>> }
>> if (length(grep(driver, pattern = "HDF4")) == 0) {
>> return(FALSE)
>> }
>> else {
>> return(TRUE)
>> }
>> }
>> 
>> 
>> >
>>
>> If we hard code:
>>
>> > cmd <- "/usr/local/bin/gdalinfo --formats"
>> > driver <- try(system(cmd, intern = TRUE), silent = TRUE)
>> > driver
>>   [1] "Supported Formats:"
>>
>>   [2] "  VRT -raster- (rw+v): Virtual Raster"
>>
>>   [3] "  GTiff -raster- (rw+vs): GeoTIFF"
>>
>>   [4] "  NITF -raster- (rw+vs): National Imagery Transmission Format"
>>
>>   [5] "  RPFTOC -raster- (rovs): Raster Product Format TOC format"
>>
>>   [6] "  ECRGTOC -raster- (rovs): ECRG TOC format"
>>
>>   [7] "  HFA -raster- (rw+v): Erdas Imagine Images (.img)"
>>
>>   [8] "  SAR_CEOS -raster- (rov): CEOS SAR Image"
>>
>>   [9] "  CEOS -raster- (rov): CEOS Image"
>>
>>  [10] "  JAXAPALSAR -raster- (rov): JAXA PALSAR Product Reader (Level
>> 1.1/1.5)&

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

Logging out (Log out?!?, do people still do that?), which is mentioned in
the manual, though actually means more than closing and opening a new
terminal, actually restarting the kernel, results in system update where
after MRT is recognized but still, in my case, drivers are not:

>library(MODIS)
> MODISoptions()
All suggested packages are installed
Detecting available write drivers!
Found: 64 candidate drivers, detecting file extensions...
ERROR 1: --format option given with format 'VRT-raster-', but that format
not
recognised.  Use the --formats option to get a list of available formats,
and use the short code (ie. GTiff or HFA) as the format identifier.

ERROR 1: --format option given with format 'GTiff-raster-', but that format
not
recognised.  Use the --formats option to get a list of available formats,
and use the short code (ie. GTiff or HFA) as the format identifier.

0 usable drivers detected!

STORAGE:
___
localArcPath : /home/chris/MODIS_ARC
outDirPath   : /home/chris/MODIS_ARC/PROCESSED


DOWNLOAD:
___
MODISserverOrder : LPDAAC, LAADS
dlmethod : auto
stubbornness : high


PROCESSING:
___
GDAL   : GDAL 2.1.0dev, released 2015/99/99
MRT: Version 4.1 (March 2011)
pixelSize  : asIn
outProj: asIn
resamplingType : NN
dataFormat : GTiff


DEPENDENCIES:
___


>
So, a little more digging.
Chris


On Wed, May 18, 2016 at 2:13 PM, chris english <
englishchristoph...@gmail.com> wrote:

> Hakim,
> Your installation and mine share the same defect:
>
> > MODIS:::checkGdalDriver()
> [1] TRUE
> > MODIS:::checkGdalDriver(GTiff)
> Error in correctPath(path) : object 'GTiff' not found
> > MODIS:::checkGdalDriver
> function (path = NULL)
> {
> inW <- getOption("warn")
> on.exit(options(warn = inW))
> options(warn = -1)
> path <- correctPath(path)
> cmd <- paste0(path, "gdalinfo --formats")
> if (.Platform$OS == "windows") {
> driver <- try(shell(cmd, intern = TRUE), silent = TRUE)
> }
> else {
> driver <- try(system(cmd, intern = TRUE), silent = TRUE)
> }
> if (class(driver) == "try-error") {
> options(warn = inW)
> warning("No gdal installation found please install 'gdal' on your
> system first!")
> return(FALSE)
> }
> if (length(grep(driver, pattern = "HDF4")) == 0) {
> return(FALSE)
> }
> else {
> return(TRUE)
> }
> }
> 
> 
> >
>
> If we hard code:
>
> > cmd <- "/usr/local/bin/gdalinfo --formats"
> > driver <- try(system(cmd, intern = TRUE), silent = TRUE)
> > driver
>   [1] "Supported Formats:"
>
>   [2] "  VRT -raster- (rw+v): Virtual Raster"
>
>   [3] "  GTiff -raster- (rw+vs): GeoTIFF"
>
>   [4] "  NITF -raster- (rw+vs): National Imagery Transmission Format"
>
>   [5] "  RPFTOC -raster- (rovs): Raster Product Format TOC format"
>
>   [6] "  ECRGTOC -raster- (rovs): ECRG TOC format"
>
>   [7] "  HFA -raster- (rw+v): Erdas Imagine Images (.img)"
>
>   [8] "  SAR_CEOS -raster- (rov): CEOS SAR Image"
>
>   [9] "  CEOS -raster- (rov): CEOS Image"
>
>  [10] "  JAXAPALSAR -raster- (rov): JAXA PALSAR Product Reader (Level
> 1.1/1.5)"
>
> I am still looking for where correctPath() comes from as well as trying to
> get my MRT recognized, but slowly slowly.
> Seems we're looking at environment variables (MRT, and likely gdal_config)
> and some other special sause that we've overlooked in installation of MODIS.
> Chris
>
> On Wed, May 18, 2016 at 8:53 AM, chris english <
> englishchristoph...@gmail.com> wrote:
>
>> > ?MODISoptions
>> > MODIS:::checkTools("GDAL")
>> Checking availabillity of GDAL:
>>OK, GDAL 2.1.0dev, released 2015/99/99 found!
>> > getOption("MODIS_gdalOutDriver")
>> [1] namedescription extension
>> <0 rows> (or 0-length row.names)
>> >
>> Interestingly not finding even GTiff default. Well, more digging,  but
>> these outputs explain runGdal error output.
>>
>> On Tue, May 17, 2016 at 10:07 AM, Hakim Abdi <hakim.a...@nateko.lu.se>
>> wrote:
>>
>>> Same here. Loading rgdal didn't make a difference.
>>>
>>> On Tue, May 17, 2016 at 9:05 AM, chris english <
>>> englishchristoph...@gmail.com> wrote:
>>>
>>>> I suspect it is an incomplete Modis build even though library(Modis)
>>>> loads without complaint, but will have to check into this l

[R-sig-Geo] Cran R Bagidis (semi-metric) and functional curve data

[chris english]

Hi,

Has anyone applied the CRAN R Bagidis package to animal movement data or
other functional curve data (EEG, Ecog, bird flight, econometrics)?

>From the documentation:
This semi-distance allows for comparing curves with sharp local patterns
that might not be well aligned from one curve to another. It is data-driven
and highly adaptive to the curves being studied. Its main originality is
its ability to consider simultaneously horizontal and vertical variations
of patterns, which proovess highly useful when used together with
clustering algorithms or visualization method.

I've found it reliably finds the same inflection or change points I'm
finding through primarily L2 euclidian triangulation.  I especially like
that it doesn't care if time courses differ. It is marvelously well
documented as to theory, though seems it would greatly benefit from a
vignette.

My current data is eyetracking but it shares many characteristics of animal
movement sensor data.  Thanks for your attention and consideration. I would
appreciate the opportunity to discuss.

Chris

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

Hakim,
Your installation and mine share the same defect:

> MODIS:::checkGdalDriver()
[1] TRUE
> MODIS:::checkGdalDriver(GTiff)
Error in correctPath(path) : object 'GTiff' not found
> MODIS:::checkGdalDriver
function (path = NULL)
{
inW <- getOption("warn")
on.exit(options(warn = inW))
options(warn = -1)
path <- correctPath(path)
cmd <- paste0(path, "gdalinfo --formats")
if (.Platform$OS == "windows") {
driver <- try(shell(cmd, intern = TRUE), silent = TRUE)
}
else {
driver <- try(system(cmd, intern = TRUE), silent = TRUE)
}
if (class(driver) == "try-error") {
options(warn = inW)
warning("No gdal installation found please install 'gdal' on your
system first!")
return(FALSE)
}
if (length(grep(driver, pattern = "HDF4")) == 0) {
return(FALSE)
}
else {
return(TRUE)
}
}


>

If we hard code:

> cmd <- "/usr/local/bin/gdalinfo --formats"
> driver <- try(system(cmd, intern = TRUE), silent = TRUE)
> driver
  [1] "Supported Formats:"

  [2] "  VRT -raster- (rw+v): Virtual Raster"

  [3] "  GTiff -raster- (rw+vs): GeoTIFF"

  [4] "  NITF -raster- (rw+vs): National Imagery Transmission Format"

  [5] "  RPFTOC -raster- (rovs): Raster Product Format TOC format"

  [6] "  ECRGTOC -raster- (rovs): ECRG TOC format"

  [7] "  HFA -raster- (rw+v): Erdas Imagine Images (.img)"

  [8] "  SAR_CEOS -raster- (rov): CEOS SAR Image"

  [9] "  CEOS -raster- (rov): CEOS Image"

 [10] "  JAXAPALSAR -raster- (rov): JAXA PALSAR Product Reader (Level
1.1/1.5)"

I am still looking for where correctPath() comes from as well as trying to
get my MRT recognized, but slowly slowly.
Seems we're looking at environment variables (MRT, and likely gdal_config)
and some other special sause that we've overlooked in installation of MODIS.
Chris

On Wed, May 18, 2016 at 8:53 AM, chris english <
englishchristoph...@gmail.com> wrote:

> > ?MODISoptions
> > MODIS:::checkTools("GDAL")
> Checking availabillity of GDAL:
>OK, GDAL 2.1.0dev, released 2015/99/99 found!
> > getOption("MODIS_gdalOutDriver")
> [1] namedescription extension
> <0 rows> (or 0-length row.names)
> >
> Interestingly not finding even GTiff default. Well, more digging,  but
> these outputs explain runGdal error output.
>
> On Tue, May 17, 2016 at 10:07 AM, Hakim Abdi <hakim.a...@nateko.lu.se>
> wrote:
>
>> Same here. Loading rgdal didn't make a difference.
>>
>> On Tue, May 17, 2016 at 9:05 AM, chris english <
>> englishchristoph...@gmail.com> wrote:
>>
>>> I suspect it is an incomplete Modis build even though library(Modis)
>>> loads without complaint, but will have to check into this later. I recall
>>> not seeing MRT complete...which I think is inscribing a folder though is
>>> probably much more.
>>> Having rgdal loaded as against your sessionInfo() didn't make a
>>> difference.
>>> Chris
>>>
>>> On Tue, May 17, 2016 at 9:52 AM, chris english <
>>> englishchristoph...@gmail.com> wrote:
>>>
>>>> Hi Hakim,
>>>>
>>>> Interesting and unexpected as I am on a linux box but I have the same
>>>> problem, or I can reproduce your's:
>>>> > sessionInfo()
>>>> R version 3.2.2 (2015-08-14)
>>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>>> Running under: Ubuntu 14.04.4 LTS
>>>>
>>>> locale:
>>>>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>>> LC_TIME=en_US.UTF-8
>>>>  [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
>>>>  LC_MESSAGES=en_US.UTF-8
>>>>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C
>>>>
>>>> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
>>>> LC_IDENTIFICATION=C
>>>>
>>>> attached base packages:
>>>> [1] stats graphics  grDevices utils datasets  methods   base
>>>>
>>>>
>>>> other attached packages:
>>>> [1] rgdal_1.1-3   MODIS_0.10-34 raster_2.5-2  sp_1.2-1
>>>>
>>>> loaded via a namespace (and not attached):
>>>> [1] rsconnect_0.4.1.11 tools_3.2.2Rcpp_0.12.4grid_3.2.2
>>>> lattice_0.20-33
>>>> > dates <- as.POSIXct( as.Date(c("01/01/2010","01/05/2016"),format
>>>> ="%d/%m/%Y") )
>>>> > dates <- transDate(dates

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

> ?MODISoptions
> MODIS:::checkTools("GDAL")
Checking availabillity of GDAL:
   OK, GDAL 2.1.0dev, released 2015/99/99 found!
> getOption("MODIS_gdalOutDriver")
[1] namedescription extension
<0 rows> (or 0-length row.names)
>
Interestingly not finding even GTiff default. Well, more digging,  but
these outputs explain runGdal error output.

On Tue, May 17, 2016 at 10:07 AM, Hakim Abdi <hakim.a...@nateko.lu.se>
wrote:

> Same here. Loading rgdal didn't make a difference.
>
> On Tue, May 17, 2016 at 9:05 AM, chris english <
> englishchristoph...@gmail.com> wrote:
>
>> I suspect it is an incomplete Modis build even though library(Modis)
>> loads without complaint, but will have to check into this later. I recall
>> not seeing MRT complete...which I think is inscribing a folder though is
>> probably much more.
>> Having rgdal loaded as against your sessionInfo() didn't make a
>> difference.
>> Chris
>>
>> On Tue, May 17, 2016 at 9:52 AM, chris english <
>> englishchristoph...@gmail.com> wrote:
>>
>>> Hi Hakim,
>>>
>>> Interesting and unexpected as I am on a linux box but I have the same
>>> problem, or I can reproduce your's:
>>> > sessionInfo()
>>> R version 3.2.2 (2015-08-14)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 14.04.4 LTS
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>>> LC_TIME=en_US.UTF-8
>>>  [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
>>>  LC_MESSAGES=en_US.UTF-8
>>>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C
>>>
>>> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
>>> LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>>>
>>> other attached packages:
>>> [1] rgdal_1.1-3   MODIS_0.10-34 raster_2.5-2  sp_1.2-1
>>>
>>> loaded via a namespace (and not attached):
>>> [1] rsconnect_0.4.1.11 tools_3.2.2Rcpp_0.12.4grid_3.2.2
>>> lattice_0.20-33
>>> > dates <- as.POSIXct( as.Date(c("01/01/2010","01/05/2016"),format
>>> ="%d/%m/%Y") )
>>> > dates <- transDate(dates[1],dates[2])
>>> > product <- "MOD13Q1"
>>> > bands <- "010"
>>> > h = c("21","22")
>>> > v = c("07","08")
>>> > runGdal(product=product,begin=dates$beginDOY,end = dates$endDOY,tileH =
>>> + h,tileV = v, SDSstring = bands, outProj="4326")
>>> Error in runGdal(product = product, begin = dates$beginDOY, end =
>>> dates$endDOY,  :
>>>   in argument dataFormat='GTiff', format not supported by GDAL type:
>>> 'gdalWriteDriver()' (column 'name') to list available inputs
>>>
>>> debugonce(runGdal)
>>> #output
>>> Browse[2]> n
>>> debug: stop("in argument dataFormat='", opts$dataFormat, "', format not
>>> supported by GDAL type: 'gdalWriteDriver()' (column 'name') to list
>>> available inputs")
>>> Browse[2]> n
>>> Error in runGdal(product = product, begin = dates$beginDOY, end =
>>> dates$endDOY,  :
>>>   in argument dataFormat='GTiff', format not supported by GDAL type:
>>> 'gdalWriteDriver()' (column 'name') to list available inputs
>>> >
>>> H. More digging. Sorry to not be helpful to this point.
>>> Chris
>>>
>>> On Mon, May 16, 2016 at 11:47 AM, Hakim Abdi <hakim.a...@nateko.lu.se>
>>> wrote:
>>>
>>>> Hi Alex,
>>>>
>>>> The OS is a 64 bit Windows 7 as specified in the sessionInfo() output I
>>>> posted. When I upgraded QGIS, I did so by uninstalling the previous one and
>>>> reinstalling the new version. I'm not quite sure what it means to upgrade
>>>> GDAL since I installed it fresh with OSGeo4W. In R, I reinstall all the
>>>> packages I need fresh off the repository using the install.views command.
>>>>
>>>> gdalDrivers() produces the output that's attached.
>>>>
>>>> Cheers,
>>>>
>>>> Hakim
>>>>
>>>>
>>>> On Wed, May 11, 2016 at 5:09 PM, Alex Mandel <
>>>> tech_...@wildintellect.com> wrote:
>>>>
>>>>> What operating system?
>>>>> When you upgraded QGIS did you also

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

I suspect it is an incomplete Modis build even though library(Modis) loads
without complaint, but will have to check into this later. I recall not
seeing MRT complete...which I think is inscribing a folder though is
probably much more.
Having rgdal loaded as against your sessionInfo() didn't make a difference.
Chris

On Tue, May 17, 2016 at 9:52 AM, chris english <
englishchristoph...@gmail.com> wrote:

> Hi Hakim,
>
> Interesting and unexpected as I am on a linux box but I have the same
> problem, or I can reproduce your's:
> > sessionInfo()
> R version 3.2.2 (2015-08-14)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.4 LTS
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8
>  [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
>  LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C
>
> [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
> LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] rgdal_1.1-3   MODIS_0.10-34 raster_2.5-2  sp_1.2-1
>
> loaded via a namespace (and not attached):
> [1] rsconnect_0.4.1.11 tools_3.2.2Rcpp_0.12.4grid_3.2.2
>   lattice_0.20-33
> > dates <- as.POSIXct( as.Date(c("01/01/2010","01/05/2016"),format
> ="%d/%m/%Y") )
> > dates <- transDate(dates[1],dates[2])
> > product <- "MOD13Q1"
> > bands <- "010"
> > h = c("21","22")
> > v = c("07","08")
> > runGdal(product=product,begin=dates$beginDOY,end = dates$endDOY,tileH =
> + h,tileV = v, SDSstring = bands, outProj="4326")
> Error in runGdal(product = product, begin = dates$beginDOY, end =
> dates$endDOY,  :
>   in argument dataFormat='GTiff', format not supported by GDAL type:
> 'gdalWriteDriver()' (column 'name') to list available inputs
>
> debugonce(runGdal)
> #output
> Browse[2]> n
> debug: stop("in argument dataFormat='", opts$dataFormat, "', format not
> supported by GDAL type: 'gdalWriteDriver()' (column 'name') to list
> available inputs")
> Browse[2]> n
> Error in runGdal(product = product, begin = dates$beginDOY, end =
> dates$endDOY,  :
>   in argument dataFormat='GTiff', format not supported by GDAL type:
> 'gdalWriteDriver()' (column 'name') to list available inputs
> >
> H. More digging. Sorry to not be helpful to this point.
> Chris
>
> On Mon, May 16, 2016 at 11:47 AM, Hakim Abdi <hakim.a...@nateko.lu.se>
> wrote:
>
>> Hi Alex,
>>
>> The OS is a 64 bit Windows 7 as specified in the sessionInfo() output I
>> posted. When I upgraded QGIS, I did so by uninstalling the previous one and
>> reinstalling the new version. I'm not quite sure what it means to upgrade
>> GDAL since I installed it fresh with OSGeo4W. In R, I reinstall all the
>> packages I need fresh off the repository using the install.views command.
>>
>> gdalDrivers() produces the output that's attached.
>>
>> Cheers,
>>
>> Hakim
>>
>>
>> On Wed, May 11, 2016 at 5:09 PM, Alex Mandel <tech_...@wildintellect.com>
>> wrote:
>>
>>> What operating system?
>>> When you upgraded QGIS did you also upgrade GDAL?
>>> When you upgraded R, did you update your packages (or rebuild any
>>> packages)?
>>>
>>> What do you get from the following command?
>>> gdalDrivers()
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 05/02/2016 02:11 PM, Hakim Abdi wrote:
>>> > Hello everyone,
>>> >
>>> > I'm having problems with the MODIS package, specifically, the runGdal()
>>> > command after the recent update to R 3.2.5. The error I get is this:
>>> >
>>> > Error in runGdal(product = product, begin = dates$beginDOY, end =
>>> > dates$endDOY, : in argument dataFormat='GTiff', format not supported by
>>> > GDAL type: 'gdalWriteDriver()' (column 'name') to list available inputs
>>> >
>>> > I'm not quite sure why this is happening, and I haven't found a
>>> solution
>>> > online. Does anyone have an idea? The package was working fine before I
>>> > upgraded R from 3.1.1. to 3.2.5, QGIS from 2.12.3 to 2.14.1 and
>>> RStudio to
>>> > version 0.99.467.
>>> >
>>> > My details are below, thanks for the assistance:
>>> >
>>> > R version 3.2.5 (2016-04-14) -- "Very, Very Secure Dis

Re: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported

[chris english]

Hi Hakim,

Interesting and unexpected as I am on a linux box but I have the same
problem, or I can reproduce your's:
> sessionInfo()
R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
 LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C  LC_ADDRESS=C

[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C

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

other attached packages:
[1] rgdal_1.1-3   MODIS_0.10-34 raster_2.5-2  sp_1.2-1

loaded via a namespace (and not attached):
[1] rsconnect_0.4.1.11 tools_3.2.2Rcpp_0.12.4grid_3.2.2
lattice_0.20-33
> dates <- as.POSIXct( as.Date(c("01/01/2010","01/05/2016"),format
="%d/%m/%Y") )
> dates <- transDate(dates[1],dates[2])
> product <- "MOD13Q1"
> bands <- "010"
> h = c("21","22")
> v = c("07","08")
> runGdal(product=product,begin=dates$beginDOY,end = dates$endDOY,tileH =
+ h,tileV = v, SDSstring = bands, outProj="4326")
Error in runGdal(product = product, begin = dates$beginDOY, end =
dates$endDOY,  :
  in argument dataFormat='GTiff', format not supported by GDAL type:
'gdalWriteDriver()' (column 'name') to list available inputs

debugonce(runGdal)
#output
Browse[2]> n
debug: stop("in argument dataFormat='", opts$dataFormat, "', format not
supported by GDAL type: 'gdalWriteDriver()' (column 'name') to list
available inputs")
Browse[2]> n
Error in runGdal(product = product, begin = dates$beginDOY, end =
dates$endDOY,  :
  in argument dataFormat='GTiff', format not supported by GDAL type:
'gdalWriteDriver()' (column 'name') to list available inputs
>
H. More digging. Sorry to not be helpful to this point.
Chris

On Mon, May 16, 2016 at 11:47 AM, Hakim Abdi 
wrote:

> Hi Alex,
>
> The OS is a 64 bit Windows 7 as specified in the sessionInfo() output I
> posted. When I upgraded QGIS, I did so by uninstalling the previous one and
> reinstalling the new version. I'm not quite sure what it means to upgrade
> GDAL since I installed it fresh with OSGeo4W. In R, I reinstall all the
> packages I need fresh off the repository using the install.views command.
>
> gdalDrivers() produces the output that's attached.
>
> Cheers,
>
> Hakim
>
>
> On Wed, May 11, 2016 at 5:09 PM, Alex Mandel 
> wrote:
>
>> What operating system?
>> When you upgraded QGIS did you also upgrade GDAL?
>> When you upgraded R, did you update your packages (or rebuild any
>> packages)?
>>
>> What do you get from the following command?
>> gdalDrivers()
>>
>> Thanks,
>> Alex
>>
>> On 05/02/2016 02:11 PM, Hakim Abdi wrote:
>> > Hello everyone,
>> >
>> > I'm having problems with the MODIS package, specifically, the runGdal()
>> > command after the recent update to R 3.2.5. The error I get is this:
>> >
>> > Error in runGdal(product = product, begin = dates$beginDOY, end =
>> > dates$endDOY, : in argument dataFormat='GTiff', format not supported by
>> > GDAL type: 'gdalWriteDriver()' (column 'name') to list available inputs
>> >
>> > I'm not quite sure why this is happening, and I haven't found a solution
>> > online. Does anyone have an idea? The package was working fine before I
>> > upgraded R from 3.1.1. to 3.2.5, QGIS from 2.12.3 to 2.14.1 and RStudio
>> to
>> > version 0.99.467.
>> >
>> > My details are below, thanks for the assistance:
>> >
>> > R version 3.2.5 (2016-04-14) -- "Very, Very Secure Dishes"
>> > Copyright (C) 2016 The R Foundation for Statistical Computing
>> > Platform: x86_64-w64-mingw32/x64 (64-bit)
>> >
>> > R is free software and comes with ABSOLUTELY NO WARRANTY.
>> > You are welcome to redistribute it under certain conditions.
>> > Type 'license()' or 'licence()' for distribution details.
>> >
>> > R is a collaborative project with many contributors.
>> > Type 'contributors()' for more information and
>> > 'citation()' on how to cite R or R packages in publications.
>> >
>> > Type 'demo()' for some demos, 'help()' for on-line help, or
>> > 'help.start()' for an HTML browser interface to help.
>> > Type 'q()' to quit R.
>> >
>> >> require(MODIS)
>> > Loading required package: MODIS
>> > Loading required package: raster
>> > Loading required package: sp
>> > MODIS_manual:
>> >
>> https://ivfl-rio.boku.ac.at/owncloud/public.php?service=files=660dc830afb091237cc40b3dea2fdf6b
>> >
>> > Attaching package: ‘MODIS’
>> >
>> > The following object is masked from ‘package:base’:
>> >
>> > file.size
>> >
>> >> MODISoptions()
>> > All suggested packages are installed
>> > Detecting available write drivers!
>> > Found: 64 candidate drivers, detecting file extensions...
>> > 0 usable drivers detected!
>> >
>> > STORAGE:
>> > ___
>> > localArcPath : C:/Users/Hakim/Documents/MODIS_ARC/
>> > outDirPath   : 

[R-sig-Geo] Bagidis semi-distance for tracking data

[chris english]

Hi,

Has anyone applied the CRAN R Bagidis package to animal movement data?

>From the documentation:
This semi-distance allows for comparing curves with sharp local patterns
that might not be well aligned from one curve to another. It is data-driven
and highly adaptive to the curves being studied. Its main originality is
its ability to consider simultaneously horizontal and vertical variations
of patterns, which proofs highly useful when used together with clustering
algorithms or visualization method.

I've found it reliably finds the same inflection or change points I'm
finding through primarily euclidian triangulation and I especially like
that it doesn't care if time courses differ. It is marvelously well
documented as to theory, though seems it would greatly benefit from a
vignette.

My current data is eyetracking but it shares many characteristics of animal
movement sensor data.  Thanks for your consideration.

Chris English

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] something potentially fun/useful

[chris english]

Hi Erin,
Edzer added an Events section to r-spatial where you'd also want to
announce your event (though I send you to the start of the discussion):

https://mail.google.com/mail/u/0/?tab=wm#inbox/15399316b48ef012

and it will be fun, useful, and highly interesting.
Chris

On Fri, Apr 15, 2016 at 3:41 PM, Hodgess, Erin  wrote:

> Hello!
>
> I hope this is ok to post this here.  There will be a special session on
> High Performance Computing in Geostatistics at the INASE conference in
> Riga, Latvia in May 28 - 30.  It will appear later today on the website.
> www.inase.org
>
> Thanks,
> Erin
> PS  I am the organizer; please do feel free to contact me at
> hodge...@uhd.edu
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Extending sp's SpatialPoints with altitude information

[chris english]

Eonfusion sounds interestingly reminiscent of Ted Nelson's Project Xanadu,
though finding a nearly working version is a very rare bird in the wild.

Chris

On Sat, Apr 16, 2016 at 1:15 AM, Michael Sumner <mdsum...@gmail.com> wrote:

>
>
> On Sat, 16 Apr 2016 at 07:04 chris english <englishchristoph...@gmail.com>
> wrote:
>
>> Mike,
>>
>> Reading this discussion lead me to finally visiting your github and
>> reading gris read.md. And of course installing it. I understand mostly
>> where you are going in the Needs section and were I to recommend a new,
>> fast friend, it would be Sandro Santilli, s...@keybit.net (
>> http://strk.keybit.net), who agonized over (I presume) and implemented
>> topology in PostGIS. While this is not R, the decisions and rigor are
>> informative. Perhaps you are fast friends already.
>>
>>
> Thanks for the link, I know that PostGIS has some of this but I haven't
> explored it. I've mostly gone on what is in "PostGIS in Action" - I need to
> get familiar with that db - I just don't see it as "the solution" for R -
> we can have a light-weight toolkit in R itself, and leverage heavy external
> libraries only when desired.
>
>
>> I really appreciate allowing mixed objects in gris that seems informed by
>> spatstat rather more than sp and friends where one feels shackled to a
>> given representation of line or point or polygon & etc..  In an analysis of
>> eyetracking data which was initially informed by a mapping perspective (sp,
>> trajectories, trips), I have essentially had to rewrite sp to to dispense
>> with sp and many constraints imposed. Those constraints were theoretically
>> valid but constraining none the less when trying to implement some system
>> of proposed algorithms that took no heed of sp's object constraints.
>>
>>
> Mostly I'm informed by the use of www.Manifold.net and the now-defunct
> Eonfusion.  MapInfo .tab and .mif formats also allow mixed topology, but I
> never used MapInfo. Eonfusion was so radical it's very hard to describe
> briefly, but essentially all storage is via relational tables - vertices,
> primitives, and objects. All tables can have any attributes (or none) and
> all operations have default choices of which attributes are used (i.e. x,
> y, z, time or lon, lat, z, time - or whatever you want to call them). It's
> very natural once you are familiar with it. Attribute flexibility on
> vertices means  you can manually set whatever you want. I.e. calculate then
> triangulate in theta/phi, then process which triangles are "on top", and
> voila you have a viewshed analysis. Manifold is stuck in 2D for now but the
> editing tools, use of selections, natural use of layers not tied to files,
> constrained triangulations, and general slickness and price put it way
> ahead of other options IMO even before the new Radian engine is released.
>
>
>> When the eyetracking thing is finally put to bed and I get an rgl
>> compatible laptop that is not my wife's laptop (as things currently stand),
>> and when I'm a tad better at r, I'd be happy to help with the evolution of
>> this 3d.
>>
>>
> That sounds great, I'm keen to find out what you are doing. That is
> another very good point in the "spatial is not special" spectrum. "Spatial"
> is really everything, maps are just one kind of "projection", long-lat,
> x-y-z, and time are inherent to many things but not everything. Topology
> exists in all kinds of  applications. Date time metadata on numeric is a
> "projection" for example.
>
> I'd like to see a really general framework where geometry and topology are
> the basis and things like sp (and now sfr) can be built on it. I see it as
> inevitable that dplyr or its successor is where that's going to happen -
> seamless back-ending with a data base is just one reason -  and with ggvis
> to replace ggplot2 it will be the go-to tool for visualization and
> user-interaction with spatial data. Hopefully the ongoing modernization of
> PROJ.4 will also assist in that being just a choice in a
> "projection-engine" family.
>
> At the moment I'm concentrating on  https://github.com/mdsumner/spbabel
>  which shows some of the ways to nest spatial data in data frames  (via
> tidyr) , in a two-level way analogous to sp objects and an "inside-out"
> way that's a better match for gris (nested data frames and the
> ggplot2::fortify approach can't do this but it's a requirement for
> topological structures including triangulation).  It's all in-dev and
> unstable for now.
>
> Finally, all of my work in this area relies on the tools in dplyr - for
> t

Re: [R-sig-Geo] Extending sp's SpatialPoints with altitude information

[chris english]

Mike,

Reading this discussion lead me to finally visiting your github and reading
gris read.md. And of course installing it. I understand mostly where you
are going in the Needs section and were I to recommend a new, fast friend,
it would be Sandro Santilli, s...@keybit.net (http://strk.keybit.net), who
agonized over (I presume) and implemented topology in PostGIS. While this
is not R, the decisions and rigor are informative. Perhaps you are fast
friends already.

I really appreciate allowing mixed objects in gris that seems informed by
spatstat rather more than sp and friends where one feels shackled to a
given representation of line or point or polygon & etc..  In an analysis of
eyetracking data which was initially informed by a mapping perspective (sp,
trajectories, trips), I have essentially had to rewrite sp to to dispense
with sp and many constraints imposed. Those constraints were theoretically
valid but constraining none the less when trying to implement some system
of proposed algorithms that took no heed of sp's object constraints.

When the eyetracking thing is finally put to bed and I get an rgl
compatible laptop that is not my wife's laptop (as things currently stand),
and when I'm a tad better at r, I'd be happy to help with the evolution of
this 3d.

Chris

On Fri, Apr 15, 2016 at 10:06 PM, Eamon Caddigan 
wrote:

> On Thu, Apr 14, 2016 at 9:30 PM, Michael Sumner 
> wrote:
> >
> > On Fri, 15 Apr 2016 at 10:36 Eamon Caddigan 
> > wrote:
> >
> >> Hi all,
> >>
> >> I am looking to extend the SpatialPoints and SpatialPointsDataFrame
> >> classes
> >> to include altitude information. Somebody recommended I check in with
> this
> >> group for pointers before getting too far along on this.
> >>
> >>
> > It's possible for Points in sp, but not for polygons or lines.
> >
> > library(sp)
> > x <- matrix(rnorm(27), ncol = 3)
> > SpatialPoints(x)
> >
> > But, the general support outside this in sp is very limited once you
> break
> > out of the plane.
> >
>
> Thanks Mike!
>
> I had no idea that coordinates() handled three-dimensional matrices
> already. In that case, it looks like I don't have to do anything at all
> (for now).
>
>
>
> > I'm working on tools to make this much easier, and to translate from sp
> to
> > other forms and back.
> >
>
> I look forward to seeing what comes out of this!
>
> -Eamon
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] default hole-status of sp::Polygon

[chris english]

Thanks Micheal for the clear explication and Edzer for fixing. Triangles
specifically were not being created or assessed properly (anti or not). İ
couldn't figure out why and assumed it was me or my approach. But it did
cause me to drop sp and friends from parts of my tool chain relating to
triangles as differential in saccade inflection detection, so I'm happy
this is sorted out. Now to github.
Cheers,
Chris
On Mar 30, 2016 15:00, "Edzer Pebesma" 
wrote:

> Thanks Mike, this is now fixed on github.
>
> On 30/03/16 06:50, Michael Sumner wrote:
> > Hello,
> >
> > help(Polygon) (sp version 1.2-2) says that if `hole` is unspecified
> > then anti-clockwise ring direction means hole = TRUE. The
> > ring-direction detection can be over-ridden by explicitly setting
> > `hole` to TRUE or FALSE, and if necessary this reorders the
> > coordinates to align to the rule,
> >
> > Polygon() will accept a n-row or (n+1)-row matrix as input, and simply
> > appends the first coordinate if it's not there.
> >
> > The anti-clockwise=hole rule holds true if we leave out the final
> > closing coordinate for a 4-vertex shape (square), but not a 3-vertex
> > shape (triangle).
> >
> > (For the purpose of this email, "is a hole" and "is not a hole" refers to
> > the
> > logical attribute actually set on the object.)
> >
> > Is this expected? Is it discussed somewhere?
> >
> > Cheers, Mike.
> >
> > library(sp)
> > ## 1) the rule is followed for a square no matter if the closing
> coordinate
> > included
> >
> > ## square with repeated first coord
> > xs <- c(0, 1, 1, 0, 0)
> > ys <- c(0, 0, 1, 1, 0)
> > ## this is a hole
> > Polygon(cbind(xs, ys))
> > ## this is not a hole
> > Polygon(cbind(xs, ys)[rev(seq_along(xs)), ])
> >
> > ## square with 4 unique coords
> > xs0 <- c(0, 1, 1, 0)
> > ys0 <- c(0, 0, 1, 1)
> > ## this is a hole
> > Polygon(cbind(xs0, ys0))
> > ## this is not a hole
> > Polygon(cbind(xs0, ys0)[rev(seq_along(xs0)), ])
> >
> > ## 2) rule is followed for a triangle with fourth closing coordinate
> >
> > ## triangle with repeated first coord
> > x <- c(0, 1, 1, 0)
> > y <- c(0, 0, 1, 0)
> >
> > ## this is a hole
> > Polygon(cbind(x, y))
> > ## this is not a hole
> > Polygon(cbind(x, y)[rev(seq_along(x)), ])
> >
> > ## triangle with 3 unique coords
> > x0 <- c(0, 1, 1)
> > y0 <- c(0, 0, 1)
> > ## this is a NOT a hole ## <- expected a hole -> ##
> > Polygon(cbind(x0, y0))
> > ## this is not a hole
> > Polygon(cbind(x0, y0)[rev(seq_along(x0)), ])
> >
> >
>
> --
> 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/
> Spatial Statistics Society http://www.spatialstatistics.info
>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Fill NoData cells in a raster

[chris english]

Marine,

Is one of the land cover types "impervious"? or are they all some
classification of vegetation type? If impervious is included in the ten
types then ignore this comment. If it isn't in the classifications then you
might want to check your region at 30m against impervious (roads, parking
lots, buildings & etc) and then add 11 to the types. That way the parking
lot won't be like it's nearest neighbor, the park. And assign noData to 11
in the cases where they match up.

Cheers,
Chris

On Fri, Mar 18, 2016 at 8:10 PM, Marine Regis 
wrote:

> Hello,
>
>
>
> Thank you very much for your answers. To fill the noData cells, I have
> calculated the frequency of values of land cover types around a given
> noData cell and I have assigned the value of land cover type with maximum
> frequency to the noData cell. When there was more than one value of maximum
> frequency, I have used the function "sample". Here is my code with a
> reproducible example:
>
>
>
> r2 <- raster(ncol=10, nrow=10) ## To check r2 <- raster(ncol=3, nrow=3)
>
> values(r2) <- sample(1:8,ncell(r2),replace=T)
>
> r2[c(5)] <- NA
>
> plot(r2)
>
> f2 <- focal(r2, w=matrix(1,nrow=3,ncol=3), fun=fillNoData, NAonly=T, pad=T)
>
> plot(f2)
>
>
>
> fillNoData <- function(x) {
>
> feq_class <- as.data.frame(table(x))
>
> colnames(feq_class) <- c("Class","Freq")
>
> value_noData <-
> as.numeric(as.character(feq_class$Class[feq_class$Freq==max(feq_class$Freq)]))
>
> value_noData <- sample(value_noData,1,replace=F)
>
> return(value_noData)
>
> }
>
>
>
> Is the use of maximum frequency appropriate for filling the noData cells?
> In this case, when there is more than one value of maximum frequency, is it
> more correct to increase the moving window or to create a buffer around a
> given noData cell than to use the 8 neighbour cells?
>
>
>
> Thank you very much for your time.
>
> Marine
>
>
>
> 
> De : Jefferson Ferreira-Ferreira 
> Envoyé : vendredi 18 mars 2016 15:51
> À : Zack Holden
> Cc : Marine Regis; r-sig-geo@r-project.org
> Objet : Re: [R-sig-Geo] Fill NoData cells in a raster
>
> A bunch of options is given here too:
> http://rstudio-pubs-static.s3.amazonaws.com/1057_1f7e9ac569644689b7e4de78c1fece90.html
>
> Map Algebra in R - Amazon Web Services<
> http://rstudio-pubs-static.s3.amazonaws.com/1057_1f7e9ac569644689b7e4de78c1fece90.html
> >
> rstudio-pubs-static.s3.amazonaws.com
> Map Algebra in R. Map Algebra is a framework used to manipulate field data
> that are stored as grid values. Though the gridded data can be stored in a
> vector form, map ...
>
>
>
> 2016-03-18 10:45 GMT-04:00 Zack Holden >:
> Marine,
> The focal() function in the raster library should work. You should be able
> to apply a custom function to only NA cells by setting NAonly=T.
>
> require(raster)
> ?focal
>
> Zack
>
>
> On Thu, Mar 17, 2016 at 5:27 PM, Marine Regis  >
> wrote:
>
> > Hello,
> >
> > I am beginner in spatial statistics and I would need some advice. I have
> a
> > raster that is based on a grid of 30 m resolution and in which each cell
> is
> > assigned to one of ten land cover types (coded as 1, 2, 3, 4, ..., 10 in
> > the raster). However, there are some NoData cells in the raster. Is there
> > an efficient way to fill NoData cells with reasonable values of land
> cover
> > types? Should I use an interpolation method?
> >
> > Thank you very much for your time.
> >
> > Marine
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
>
> --
>
> Jefferson Ferreira-Ferreira
>
> Geógrafo - GEOPROCESSAMENTO IDSM | Coordenadoria de TI
>
> [https://imageshack.com/a/img924/3023/UGEtug.png]
>
> jefferson.ferre...@mamiraua.org.br jefferson.ferre...@mamiraua.org.br>
>
> Instituto de Desenvolvimento Sustentável Mamirauá
>
> Ministério da Ciência, Tecnologia e Inovação
>
> Telefone: +55 97 3343-9710
>
> [https://imageshack.com/a/img922/761/fPeXJi.png]Google Maps - Mapas deste
> e-mail:
>
> [https://imageshack.com/a/img921/7894/xDTJEU.png]Exibir mapa ampliado<
> https://maps.google.com.br/maps?q=-3.37,-64.731151=-3.355471,-64.731145=0.004632,0.006968=1=h=18
> >
>
> Contatos particulares:
> (55) 9615-0100
>
>
> [[alternative HTML version deleted]]
>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

Re: [R-sig-Geo] calculate "regional" slope

[chris english]

Dominik,
There's mention of grass not working on osx 10.11 and a work around
grassmac.wikidot.com

I was generally using PCRaster when I was doing watershed/flood
re-creations to handle the watershed delineations and the like and don't
have an opinion on Grass.

Yeah, that transect was maybe a silly idea but it generalizes surface to
line, sort of like Mauana volcano is a cake you've cut in half. And the
line is outline.

Chris
On Feb 20, 2016 2:09 AM, "Dominik Schneider" <dominik.schnei...@colorado.edu>
wrote:

> Chris R,
> I'd be happy to use grass7 but I can't get it to run on my mac. osx
> 10.11.3. I have a working qgis from kyngchaos, installed pandoc and cairo
> on top of that, and disabled sip but the grass7.app just hangs when I try
> to open it.
> Chris E,
> I will try to clarify. Rather than thinking about "side of a mountain",
> think about "side of a mountain **range**".  The point of calculating a
> regional slope is that if I am on the west side of a continental divide but
> on the east side of mountain, the function still returns a value indicating
> west-facing.  so maybe it's easier to think in meters.   lets assume my DEM
> is a 500m grid. the slope calculation would give a local value at 500m.
> This local slope might be east facing, but I am interested in the overall
> slope across 10km to indicate which way e.g. the watershed is draining.
> What do you mean with "transect along the z. I.e. roll your dem on it's
> side."?
>
>
> On Fri, Feb 19, 2016 at 2:50 PM, chris english <
> englishchristoph...@gmail.com> wrote:
>
>> Dominik,
>> Sorry, I'm still trying to understand your 0.05 to 1.5 degree part of
>> your problem.
>>
>> Otherwise, I think you are limited to 8 neighbors as this reflects the
>> documentation as I read it.
>>
>> Even Roualt perhaps would be up in arms; but, there's nothing saying you
>> can't do a 16 vs 8 neighbor. You'd have to examine the impacts thereafter,
>> but basically you'd be amending some gdal (probably a line or two of code)
>> for your purposes.
>>
>> There are a bunch of things to consider, theoretical and practical; but,
>> why 16 better than 8. And more importantly as you relax, as a matter of
>> rings (in this case), would your analytical result be better? Or
>> potentially have any remainder meaning at all, I.e. I don't know my
>> neighbor's neighbor's neighbor (does that get us out to 16?).
>> And so generalizing beyond some given point might yield not much on a knn
>> influence/likeness basis.
>>
>> I think we're first better off dialing back in on what you mean by
>> regional or the 0.5 to 1.5 resolution and then neighborhood size (4, 8,16?).
>>
>> Of course another approach to this "what side of the mountain am I on" is
>> to transect along the z. I.e. roll your dem on it's side.
>>
>> Anyway, clarify the 0.5/1.5 so I don't go too far astray.
>> Chris
>> Thanks for the suggestion Chris.  I'm familiar with gdaldem, which
>> raster::terrain is based on, to compute slope from a dem. I now realize
>> that my example isnt a good one because neighbors=8 would achieve what I
>> described. However I actually want some flexibility such that I can
>> specifiy neighbors=16 so that it uses the next "ring" of cells.
>>
>> I played around with focal() with weight argument =
>> matrix(rep(c(1,0,0,0,1),5),byrow=T) but couldn't figure out how to solve
>> for a directional slope.
>>
>> On Fri, Feb 19, 2016 at 4:09 AM, chris english <
>> englishchristoph...@gmail.com> wrote:
>>
>>> Dominik,
>>>
>>> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>>>  vals <- sample.int(1e3,440)
>>> r[ ] <- vals
>>> #raster::terrain
>>> terr_r <- terrain(r, opt='slope', unit='degrees', neighbors=8)
>>> Ah, but it appears you want up sampling to 1.5 degrees rather than 0.5
>>> deg.
>>> so maybe spatial.tools::projectRaster_rigorous then raster:terrain.
>>>
>>> I'm inclined to end that last so maybe with a question mark. Sorry for an
>>> essentially inconclusive response but I was happy to find terrain in any
>>> case.
>>> Chris
>>>
>>> On Fri, Feb 19, 2016 at 2:59 AM, Dominik Schneider <
>>> dominik.schnei...@colorado.edu> wrote:
>>>
>>>> I need to calculate slope at different scales. In the case below, r is a
>>>> 0.5deg resolution raster and I want the slope for 1.5 deg centered on
>>>> each
>>>> of those 0.5 deg pix

Re: [R-sig-Geo] calculate "regional" slope

[chris english]

Dominik,
Sorry, I'm still trying to understand your 0.05 to 1.5 degree part of your
problem.

Otherwise, I think you are limited to 8 neighbors as this reflects the
documentation as I read it.

Even Roualt perhaps would be up in arms; but, there's nothing saying you
can't do a 16 vs 8 neighbor. You'd have to examine the impacts thereafter,
but basically you'd be amending some gdal (probably a line or two of code)
for your purposes.

There are a bunch of things to consider, theoretical and practical; but,
why 16 better than 8. And more importantly as you relax, as a matter of
rings (in this case), would your analytical result be better? Or
potentially have any remainder meaning at all, I.e. I don't know my
neighbor's neighbor's neighbor (does that get us out to 16?).
And so generalizing beyond some given point might yield not much on a knn
influence/likeness basis.

I think we're first better off dialing back in on what you mean by regional
or the 0.5 to 1.5 resolution and then neighborhood size (4, 8,16?).

Of course another approach to this "what side of the mountain am I on" is
to transect along the z. I.e. roll your dem on it's side.

Anyway, clarify the 0.5/1.5 so I don't go too far astray.
Chris
Thanks for the suggestion Chris.  I'm familiar with gdaldem, which
raster::terrain is based on, to compute slope from a dem. I now realize
that my example isnt a good one because neighbors=8 would achieve what I
described. However I actually want some flexibility such that I can
specifiy neighbors=16 so that it uses the next "ring" of cells.

I played around with focal() with weight argument =
matrix(rep(c(1,0,0,0,1),5),byrow=T) but couldn't figure out how to solve
for a directional slope.

On Fri, Feb 19, 2016 at 4:09 AM, chris english <
englishchristoph...@gmail.com> wrote:

> Dominik,
>
> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>  vals <- sample.int(1e3,440)
> r[ ] <- vals
> #raster::terrain
> terr_r <- terrain(r, opt='slope', unit='degrees', neighbors=8)
> Ah, but it appears you want up sampling to 1.5 degrees rather than 0.5 deg.
> so maybe spatial.tools::projectRaster_rigorous then raster:terrain.
>
> I'm inclined to end that last so maybe with a question mark. Sorry for an
> essentially inconclusive response but I was happy to find terrain in any
> case.
> Chris
>
> On Fri, Feb 19, 2016 at 2:59 AM, Dominik Schneider <
> dominik.schnei...@colorado.edu> wrote:
>
>> I need to calculate slope at different scales. In the case below, r is a
>> 0.5deg resolution raster and I want the slope for 1.5 deg centered on each
>> of those 0.5 deg pixels. I'm trying to estimate which side of mountain
>> range each pixel is on. So the resulting raster would have the same number
>> of pixels as r. The edges can be NA.
>> any suggestions would be appreciated. Thanks
>>
>>
>> r <- raster(nrows=22, ncols=20, xmn=-58, xmx=-48, ymn=-33, ymx=-22)
>> setValues(r,rnorm(440))
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Intersect shapefiles

[chris english]

And so for John 's completion we should ask: Union or intersection? I
assume union but of course could be wrong. What i especially like about the
sp and rgeos documentation is that if you take the time to run the examples
in the documentation you just might see your use case. Or, rather likely.
Chris
On Feb 18, 2016 8:11 PM, "Worrall, James -FS" <jworr...@fs.fed.us> wrote:

> Such a clear and simple explanation - thank you.  I wish the function
> documentation was written like that.
>
> -Original Message-
> From: Alex Mandel [mailto:tech_...@wildintellect.com]
> Sent: Thursday, February 18, 2016 9:59 AM
> To: Worrall, James -FS <jworr...@fs.fed.us>; chris english <
> englishchristoph...@gmail.com>; A. Marcia BARBOSA <barb...@uevora.pt>
> Cc: Help R-Sig_Geo <r-sig-geo@r-project.org>
> Subject: Re: [R-sig-Geo] Intersect shapefiles
>
> Union creates a merged shape including all parts of input objects.
>
> Intersection creates a shape of the overlapping portions of input objects.
>
> I'm not clear on the goal from the initial email so I don't know which is
> better in this case.
>
> Enjoy,
> Alex
>
> On 02/18/2016 07:55 AM, Worrall, James -FS wrote:
> >
> > I would have thought gUnaryUnion, but then I can't understand from the
> documentation what the difference is between that and gIntersection.
> >
> > -Original Message-
> > From: R-sig-Geo [mailto:r-sig-geo-boun...@r-project.org] On Behalf Of
> > chris english
> > Sent: Thursday, February 18, 2016 7:24 AM
> >
> > John,
> >
> > As Loic suggests, rgeos::gIntersection will get you there. Look closely
> at his naming of objects and your example code using spTransform. With his
> approach, each object has its own name; whereas your approach overwrites
> Rain_poly_merge the second and third time and the final object (third) is
> the 2008 maize yield. So read your shapefiles into differently named
> objects and use Loic's approach.
> >
> > Chris
> >
> >
> >
> >
> >
> > This electronic message contains information generated by the USDA
> solely for the intended recipients. Any unauthorized interception of this
> message or the use or disclosure of the information it contains may violate
> the law and subject the violator to civil or criminal penalties. If you
> believe you have received this message in error, please notify the sender
> and delete the email immediately.
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Intersect shapefiles

[chris english]

John,

As Loic suggests, rgeos::gIntersection will get you there. Look closely at
his naming of objects and your example code using spTransform. With his
approach, each object has its own name; whereas your approach overwrites
Rain_poly_merge the second and third time and the final object (third) is
the 2008 maize yield. So read your shapefiles into differently named
objects and use Loic's approach.

Chris

On Thu, Feb 18, 2016 at 1:58 PM, A. Marcia BARBOSA 
wrote:

> Check out also function joinPolys in the PBSmapping package
> (http://www.inside-r.org/packages/cran/pbsmapping/docs/joinPolys)
>
>
> - - -
> A. Márcia BARBOSA, post-doctoral fellow
> CIBIO/InBIO - University of Évora (Portugal)
> http://modtools.wordpress.com/barbosa
>
>
>
> 2016-02-18 10:04 GMT+00:00 Loïc Dutrieux :
>
> > Hi,
> >
> > Have you tried gIntersection from the rgeos package.
> >
> > Given 3 SpatialPolygon* objects you can probably do something like:
> >
> > sp12 <- gIntersection(sp1, sp2)
> > sp123 <- gIntersection(sp12, sp3)
> >
> > Cheers,
> > Loïc
> >
> >
> > On 02/18/2016 10:25 AM, John Wasige wrote:
> >
> >> ​Dear all,
> >>
> >> I have three shapefiles that I want to intersect. Any body with an idea
> on
> >> how to do the intersection? Shapefiles below;
> >> library(rgdal)
> >> library(rgeos)
> >> library(maptools)
> >> library(sp)
> >> ###shape1
> >> Rain_poly_merge <- readOGR(dsn="G:/EPIC_CUP/Rain_poly_merge.shp",
> >> layer="Rain_poly_merge")
> >> Rain_poly_merge <- spTransform(Rain_poly_merge, CRS("+init=epsg:4326"))
> >>
> >> ###shape2
> >> Rain_poly_merge <-
> readOGR(dsn="G:/EPIC_CUP/yield_maize_average2002.shp",
> >> layer="Rain_poly_merge")
> >> Rain_poly_merge <- spTransform(Rain_poly_merge, CRS("+init=epsg:4326"))
> >>
> >> ###shape3
> >> Rain_poly_merge <-
> readOGR(dsn="G:/EPIC_CUP/yield_maize_average2008.shp",
> >> layer="Rain_poly_merge")
> >> Rain_poly_merge <- spTransform(Rain_poly_merge, CRS("+init=epsg:4326"))
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ___
> >> R-sig-Geo mailing list
> >> R-sig-Geo@r-project.org
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>
> >>
> > ___
> > R-sig-Geo mailing list
> > R-sig-Geo@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] spdep not available

[chris english]

Abhishek:

chooseCRANmirror() is your best friend here as it allows you to select a
different mirror once you've found a given mirror reports "package is not
available for R version 3.2.x" As Roger points out, staleness happens and
if it isn't up to date at USA/CA1 it might quite likely be up to date at
USA/PA1 or Berlin or somewhere.
HTH,
chris

On Sun, Feb 7, 2016 at 10:16 PM, Roger Bivand  wrote:

> On Sun, 7 Feb 2016, Abhishek Padhi wrote:
>
> Hello Sir,
>>
>> spdep package is not available for R version 3.2.2.
>>
>
> Please check properly, and document your claim. Of course the source is
> available, as are the OSX and Windows binaries:
>
> https://cran.r-project.org/web/packages/spdep/index.html
>
> The mirror you are using may be stale, or there may be other reasons, but
> an undocumented claim like this is of no help in resolving your problem (no
> OS, no mirror, etc.).
>
> Roger
>
>
>> Thanks
>>
>> *Regards*
>> *Abhishek Padhi*
>> *B.E. (Hons.) Civil Engineering*
>> Birla Institute of Technology & Science, *Pilani *
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-sig-Geo mailing list
>> R-sig-Geo@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 91 00
> e-mail: roger.biv...@nhh.no
> http://orcid.org/-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0J=en
> http://depsy.org/person/434412
>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Elevation profiles

[chris english]

Allie,

Perhaps rgoes, gBuffer (which wouldn't necessarily fit your arbitrary width
criteria but otherwise serve, (perhaps selecting your widths from a random
distribution multiplier)) your polyline and lay it over your DEM, something
like a swath transect? Sorry, just kinda thinking out loud. Or reading
again, do you really want to lay something like an arbitrary polygon on
there that contains the 10 pts?

Chris
And you ask, so how would you do that. Indeed.



On Mon, Jan 25, 2016 at 1:58 PM, Alexander Shenkin  wrote:

> Hello All,
>
> I've done this in ArcMAP, but further requirements are making it harder to
> do it there, so was hoping I can do it in R.
>
> I have SRTM DEM rasters, and want to create an elevation profile. This
> profile is drawn along a polyline connecting 10 GPS points.  I was able to
> do all that in arcmap.  Now, however, I want to create the profile from an
> average elevation drawn from a swath of arbitrary width, rather than by
> just a line.  I hope this makes sense.
>
> Apologies for not including reproducible code here - I'm hoping there's
> enough here to point me in a direction in terms of packages and algorithms
> regardless.  Thanks in advance.
>
> Allie
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] mapcircles help

[chris english]

Timothee,
Best to ask as new question, perhaps "When to deprecate a package?", as
that will put you in front of the many many package authors and maintainers
that inform this discussion.
My thoughts.
Chris
On Jan 11, 2016 1:19 PM, "Timothée Giraud" 
wrote:

> Hi,
> As maintainer of the rCarto package, my advice would be to switch to the
> cartography package (of which I am also maintainer) and the
> propSymbolsLayer function in it. Examples and the vignette will help you
> through the mapping process.
>
> My turn to ask for an advice:
> rCarto was my first package and after a while we decide to build an other,
> better, thematic mapping package (i.e. the cartography package).
> cartography is much more R-ish in its use of the graphic device, offers
> more kinds of maps and has more options to customize the maps.
> So my question is: what should I do with rCarto? Remove it from CRAN?
> Deprecate all functions in it? Add a visible comment to incite users to
> switch to cartography?
>
> Any advice is greatly appreciated.
> Thanks,
> Tim
>
>
>
>
>
> Le 11/01/2016 10:56, Mistry, Krishan a écrit :
>
>> Dear Sirs/Madame,
>>
>>
>> I have a spatial polygons data frame and want to map proportional circles
>> on it. I have tried using the map circles function in rCarto as seen below
>> but it doesn't seem to work an continues to show errors. Do I need to
>> convert the spatial polygons data frame to a shapefile if so I would I do
>> this?
>>
>>
>>
>> mapCircles(shpFile, shpId, df, dfId, var,
>>fixedNorm =ALSE, shareOfCircles = 0.02,
>>radiusMax =.5, valueMax = max(df[, var], na.rm = TRUE),
>>lgdRnd =, posLeg = "bottomleft",
>>circleCol =#FD8D3C", baseCol = "#FFEDA0",
>>title =ar, legend = var, author = "author", sources =
>> "sources",
>>scalebar =ALSE, scalebarSize, scalebarText,
>>northArrow =ALSE, northArrowSize,
>>width =ULL, height = NULL, txtCex = NULL)
>>
>>
>>
>> Any advice is greatly appreciated.
>>
>>
>> Many Thanks
>>
>> Krish
>>
>> [[alternative HTML version deleted]]
>>
>>
>>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] R Help

[chris english]

Krishan,

Create functions to compute the area, centroid and perimeter of a polygon
list (as in the format of georgia.polys).
The secret here is the specificity of georgia.polys, which googling leads
us to Cran R "GISTools". Looks like this handles the polygon area calc.
Perimeter can also be referred to as envelope which might lead one to
either "geosphere" or "spatstat". Thence to "rgeos" for centroid, and a
small walking tour of aspects of spatial R.

I'm imagining the idea is to use what has already been validated as correct
code rather than writing the same.
HTH,
Chris

On Thu, Jan 7, 2016 at 10:38 PM, Sarah Goslee 
wrote:

> You'd get better results if you send your information to the list, and
> as plain-text email with data either included or using one of the
> built-in datasets in R. I don't necessarily know the answer even
> though I know the right way to ask the question.
>
> Sarah
>
> On Thu, Jan 7, 2016 at 3:35 PM, Mistry, Krishan 
> wrote:
> > Dear Sarah,
> >
> > This isn't homework, but in fact optional extra work for a R practical
> session. I am new to R and haven't done any programming before.  Would you
> be able to assist me, if i am able to send you the question on a word
> document along the data that is used.
> >
> > Kind Regards
> > Krishan
> >
> > 
> > From: Sarah Goslee 
> > Sent: 07 January 2016 20:31
> > To: Mistry, Krishan
> > Cc: r-sig-geo@r-project.org
> > Subject: Re: [R-sig-Geo] R Help
> >
> > As you will see below, posting in HTML format made your question
> unreadable.
> >
> > However, this looks rather like homework, and if so then you should
> > look for help from the resources associated with your course.
> >
> > If it isn't homework, you will get much more assistance if you provide
> > a reproducible example including data and the code you've tried
> > already.
> >
> > Sarah
> >
> > On Thu, Jan 7, 2016 at 3:24 PM, Mistry, Krishan 
> wrote:
> >> Dear Sir/Madame,
> >>
> >> I am currently a Masters student at the University of Leicester in the
> UK studying MSc Geographical Information Science and am having a bit of
> difficulty with the programme R. I am a new user of the programme and don't
> have any previous experience in programming. Having looked at various web
> sites, I wondered if you are able to help me with some trouble i am having
> in trying to write some code for a mathematical equation.
> >> I have attached the question to this email and it can be seen below.
> The dataset is a list of polygons with each polygon containing another list
> within it, of x and y coordinates.
> >>
> >> I would really appreciate it, if you could help me with this question.
> >>
> >> Question
> >> Create functions to compute the area, centroid and perimeter of a
> polygon list (as in the format of georgia.polys). The formula for the area
> of a polygon is
> >>
> >> A=0.5*?(x? y???) (x??? y?)  for i until n-1
> >>
> >> where A is the polygon area, xi is the ith x-coordinate of the polygon
> boundary (x[i] in R), yi is the ith ycoordinate of the polygon boundary
> (y[i] in R) - and n is the number of points used to specify the polygon
> boundary. The polygon is assumed to be in closed form so that the x1 and y1
> take the same value as xn and yn.
> >>
> >> Hope to hear from you soon.
> >>
> >> Yours sincerely
> >>
> >> Krishan Mistry
> >>
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Help with as.numeric(rownames(over(SpatialPoints(set1, set2, returnList= TRUE)[[1]]))

[chris english]

Hi Alan;
As you say, runs most of the time. I took the liberty of cleaning out the
>'s, removed the call to plyr as it doesn't seem to be used, and the
rm(list=ls()) since I wasn't playing in a sandbox. How frequently does it
misbehave?

I'm sorry I can't offer anything more constructive than the clean up.  I'm
interested in identifying self-avoiding random walks SAW which means I'll
first have to figure out how to implement one, then figure out how to test
for one. And means getting my head around your  "which_next <-
sample(c("bb","dd","ff","hh"),1)" logic.

Chris

## reproducible example code
 #rm(list = ls())
 library(deldir)
 library(sp)
 #library(plyr)
 side_length = 100
 ## Create random SET of XY coordinates (size = 100x100)
 set.seed(11)
 df = data.frame(matrix(sample(1:100,16,replace=TRUE),nrow=8))
 ## Convert df to SPatialPointsDataFrame
 spdf <- SpatialPointsDataFrame(df,df)
 ## deldir() function creates tesselation (voronoi) plot
 z <- deldir(df,plotit=TRUE,wl='te')
 ## tile.list() creates a list of data for tiles
 zz <- tile.list(deldir(df,plotit=TRUE,wl='te'))
 ## Voronoi Polygons Function
 voronoipolygons = function(layer) {
   require(deldir)
   crds = layer@coords
   z = deldir(crds[,1], crds[,2])
   w = tile.list(z)
   polys = vector(mode='list', length=length(w))
   require(sp)
   for (i in seq(along=polys)) {
 pcrds = cbind(w[[i]]$x, w[[i]]$y)
 pcrds = rbind(pcrds, pcrds[1,])
 polys[[i]] = Polygons(list(Polygon(pcrds)), ID=as.character(i))
   }
   SP = SpatialPolygons(polys)
   voronoi = SpatialPolygonsDataFrame(SP, data=data.frame(x=crds[,1],
 y=crds[,2], row.names=sapply(slot(SP, 'polygons'),
 function(x) slot(x, 'ID'
 }
 ## Generate SpatialPolygonsDataFrame to use as input for over() function
 vpl <- voronoipolygons(spdf)
 ## Random Walk Function generates North, South East or West movement
 ## with transit from across screen (like PacMan, going out one side,
 ## coming back on the other side) to prevent getting stuck in corner
 random_walk <- function(step_quantity, step_length, plot = FALSE){
   require(ggplot2)

   walker <- data.frame(matrix(c(0,0), nrow = step_quantity, ncol = 3,
 byrow = T))
   names(walker)[1]<-paste("x")
   names(walker)[2]<-paste("y")
   names(walker)[3]<-paste("which")

   ## Seed random initial starting point
   walker[1,1:2] <- matrix(sample(1:100,2,replace=TRUE),nrow=1)
   walker[1,3] <- as.numeric(rownames(over(SpatialPoints(walker[1,1:2]
),vpl,returnList=TRUE)[[1]]))

  where_to <- as.numeric()

   for(i in 2:step_quantity){
 where_to <- as.numeric()
 where_to <- walker[i-1,1:2]
 which_next <- sample(c("bb","dd","ff","hh"),1)

 if (which_next == "bb") {
   if (walker[i-1,2] == side_length) {where_to[1,2] <- 0
   } else {where_to[1,2] <- walker[i-1,2]+step_length}
 }

 else if (which_next == "dd") {
   if (walker[i-1,1] == 0 ) {where_to[1,1] <- side_length
   } else {where_to[1,1] <- walker[i-1,1]-step_length}
 }

else if (which_next == "ff") {
   if (walker[i-1,1] == side_length) {where_to[1,1] <- 0
   } else {where_to[1,1] <- walker[i-1,1]+step_length}
 }
 else {
   if (walker[i-1,2] == 0) {where_to[1,2] <- side_length
   } else {where_to[1,2] <- walker[i-1,2]-step_length}
 }

 walker[i,1:2] <- where_to
   }

   walker[i,3] <- as.numeric(rownames(over(SpatialPoints(walker[i,1:2]),
   vpl,returnList= TRUE)[[1]]))


   if(plot){
   require(ggplot2)
   p <- ggplot(walker, aes(x = x, y = y))
   p <- p + geom_path()
   print(p)
   }

   return(walker)
 }
 try(transits <- random_walk(5000,1),silent=F)

On Sun, Nov 1, 2015 at 1:35 PM, Alan Briggs  wrote:

> Hello.
>
> Below is a fully repeatable R-Script that I'm having trouble with.
> Generally, here's what I'm trying to do:
>
> 1) Randomly generate a tile.list()
> 2) Randomly generate a new point
> 3) Identify which polygon in the tile.list the new randomly generated point
> is in
>
> This works fine MOST of the time. However, occasionally, I get an error
> returned:
>
> Error in `[<-.data.frame`(`*tmp*`, list, 3, value = numeric(0)) :
> >   replacement has length zero
>
>
> While troubleshooting, I realized I get numeric(0) returned for certain
> sets of new random points when I run the command
> as.numeric(rownames(over(SpatialPoints(walker[i,1:2]),vpl,returnList=
> TRUE)[[1]])). I thought maybe this was a boundary issue, but the points
> don't lie on the edge, nor are they the centroid.
>
> Any help you can provide would be greatly appreciated!
>
> Regards,
>
> Alan
>
> R-Script Below:
>
> ### Help Question for  r-sig-geo ###
> > rm(list = ls())
> > library(deldir)
> > library(sp)
> > library(plyr)
> > side_length = 100
> > ## Create random SET of XY coordinates (size = 100x100)
> > set.seed(11)
> > df = data.frame(matrix(sample(1:100,16,replace=TRUE),nrow=8))
> > ## Convert df to SPatialPointsDataFrame
> > spdf <- 

Re: [R-sig-Geo] Help with as.numeric(rownames(over(SpatialPoints(set1, set2, returnList= TRUE)[[1]]))

[chris english]

Alan,

Possibly a nonsensical way of testing but I ran

rep(try(transits <- random_walk(5000,1),silent=F), 100)

and it completed without issue.

Chris

On Mon, Nov 2, 2015 at 5:33 AM, chris english <englishchristoph...@gmail.com
> wrote:

> Hi Alan;
> As you say, runs most of the time. I took the liberty of cleaning out the
> >'s, removed the call to plyr as it doesn't seem to be used, and the
> rm(list=ls()) since I wasn't playing in a sandbox. How frequently does it
> misbehave?
>
> I'm sorry I can't offer anything more constructive than the clean up.  I'm
> interested in identifying self-avoiding random walks SAW which means I'll
> first have to figure out how to implement one, then figure out how to test
> for one. And means getting my head around your  "which_next <-
> sample(c("bb","dd","ff","hh"),1)" logic.
>
> Chris
>
> ## reproducible example code
>  #rm(list = ls())
>  library(deldir)
>  library(sp)
>  #library(plyr)
>  side_length = 100
>  ## Create random SET of XY coordinates (size = 100x100)
>  set.seed(11)
>  df = data.frame(matrix(sample(1:100,16,replace=TRUE),nrow=8))
>  ## Convert df to SPatialPointsDataFrame
>  spdf <- SpatialPointsDataFrame(df,df)
>  ## deldir() function creates tesselation (voronoi) plot
>  z <- deldir(df,plotit=TRUE,wl='te')
>  ## tile.list() creates a list of data for tiles
>  zz <- tile.list(deldir(df,plotit=TRUE,wl='te'))
>  ## Voronoi Polygons Function
>  voronoipolygons = function(layer) {
>require(deldir)
>crds = layer@coords
>z = deldir(crds[,1], crds[,2])
>w = tile.list(z)
>polys = vector(mode='list', length=length(w))
>require(sp)
>for (i in seq(along=polys)) {
>  pcrds = cbind(w[[i]]$x, w[[i]]$y)
>  pcrds = rbind(pcrds, pcrds[1,])
>  polys[[i]] = Polygons(list(Polygon(pcrds)), ID=as.character(i))
>}
>SP = SpatialPolygons(polys)
>voronoi = SpatialPolygonsDataFrame(SP, data=data.frame(x=crds[,1],
>  y=crds[,2], row.names=sapply(slot(SP, 'polygons'),
>  function(x) slot(x, 'ID'
>  }
>  ## Generate SpatialPolygonsDataFrame to use as input for over() function
>  vpl <- voronoipolygons(spdf)
>  ## Random Walk Function generates North, South East or West movement
>  ## with transit from across screen (like PacMan, going out one side,
>  ## coming back on the other side) to prevent getting stuck in corner
>  random_walk <- function(step_quantity, step_length, plot = FALSE){
>require(ggplot2)
>
>walker <- data.frame(matrix(c(0,0), nrow = step_quantity, ncol = 3,
>  byrow = T))
>names(walker)[1]<-paste("x")
>names(walker)[2]<-paste("y")
>names(walker)[3]<-paste("which")
>
>## Seed random initial starting point
>walker[1,1:2] <- matrix(sample(1:100,2,replace=TRUE),nrow=1)
>walker[1,3] <- as.numeric(rownames(over(SpatialPoints(walker[1,1:2]
> ),vpl,returnList=TRUE)[[1]]))
>
>   where_to <- as.numeric()
>
>for(i in 2:step_quantity){
>  where_to <- as.numeric()
>  where_to <- walker[i-1,1:2]
>  which_next <- sample(c("bb","dd","ff","hh"),1)
>
>  if (which_next == "bb") {
>if (walker[i-1,2] == side_length) {where_to[1,2] <- 0
>} else {where_to[1,2] <- walker[i-1,2]+step_length}
>  }
>
>  else if (which_next == "dd") {
>if (walker[i-1,1] == 0 ) {where_to[1,1] <- side_length
>} else {where_to[1,1] <- walker[i-1,1]-step_length}
>  }
>
> else if (which_next == "ff") {
>if (walker[i-1,1] == side_length) {where_to[1,1] <- 0
>} else {where_to[1,1] <- walker[i-1,1]+step_length}
>  }
>  else {
>if (walker[i-1,2] == 0) {where_to[1,2] <- side_length
>} else {where_to[1,2] <- walker[i-1,2]-step_length}
>  }
>
>  walker[i,1:2] <- where_to
>}
>
>walker[i,3] <- as.numeric(rownames(over(SpatialPoints(walker[i,1:2]),
>vpl,returnList= TRUE)[[1]]))
>
>
>if(plot){
>require(ggplot2)
>p <- ggplot(walker, aes(x = x, y = y))
>p <- p + geom_path()
>print(p)
>}
>
>return(walker)
>  }
>  try(transits <- random_walk(5000,1),silent=F)
>
> On Sun, Nov 1, 2015 at 1:35 PM, Alan Briggs <awbri...@gmail.com> wrote:
>
>> Hello.
>>
>> Below is a fully repeatable R-Script that I'm having trouble with.
>> Generally, here's what I'm trying to do:
>>
>> 1) Randomly generate a tile.list()
>

Re: [R-sig-Geo] How to filter a xyz vector file

[chris english]

Ashraf,
You might consider preprocessing with Lastools.  There are a fair number of
hits for google: cran r lidar inclusive of terrestrial.
HTH,
Chris


On Sun, Oct 11, 2015 at 2:07 PM, Ashraf Afana via R-sig-Geo <
r-sig-geo@r-project.org> wrote:

> Hi friends,
>
> I have a xyz vector file from a terrestrial laser scanner that contains a
> huge amount of points at a high resolution (approximately 15 mm). I need to
> reduce the amount of point in the file by selecting N number of points each
> certain distance (i.e. generate equidistant spacing). I was looking at the
> available libraries in R (sp, rgdal, etc.), but I was unable to find a
> function to do so. Any suggestions?
>
> Ashraf,
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] densify geometries

[chris english]

Mike,

I use rgeos::gBuffer for polygons akin to what you're seeking. Looking at
the implementation of the
quadsegs argument might aid you.  Don't know what to suggest for lines
though I'm thinking the
aggregation process in Trajectories might be of use.  I realize that
aggregation suggests reducing
rather than densifying but there many be an opportunity to inject arbitrary
'between' points to densify
to lines.
HTH. Chris

On Thu, Aug 6, 2015 at 11:10 PM, Michael Sumner mdsum...@gmail.com wrote:

 Hello, is there any existing function in the Spatial family in R to
 densify geometries?

 I'd like to be able specify the insertion of redundant vertices for all
 individual segments within a Line* or Polygon*. I've done a bit myself but
 wondering if this already exists somewhere.  This is a pretty standard task
 for reprojection in traditional GIS. Ultimately I would implement a
 minimum distance option as well, just wondering if this is already out
 there somewhere.

 I know there are partial pieces of this, for instance in
 raster::rasterToPolygons and rgeos::gDistance - are there others? - but I
 want more control.

 Cheers, Mike.

 [[alternative HTML version deleted]]

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


[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Problem installing rgeos

[chris english]

Scott,

Keeping in mind that I'm not any sort of rgeos maintainer, but looking at
the config dialog, it appears to me that in the event of a failed build,
the config log wouldn't make it to:

ERROR: configuration failed for package 'rgeos'
* removing '/files3/R/R-3.2.1_install/lib64/R/library/rgeos'

as those files weren't written. Fair enough.
But, we do have that:
configure: error: in `/tmp/RtmpUjYUle/R.INSTALL41c15690b9e1/rgeos'

report line in there which is sufficiently specific/unique to suggest that
if one were to name something
as generic as config.log it wouldn't overwrite or get otherwise confused
with another config.log. So I'd clamber down that directory tree and see if
a config.log existed there somewhere. If there isn't some automatic
mechanism to remove from~/tmp, then it might likely be there...

Like yourself, I am at many times a head scratching user whose ah-ha
moments, if and when they come, are defined by having less hair and having
shed tears of frustration. Before I resort of posting to the list under the
do thy homework ethic.

So this is the best I can propose at the instance as mine was a successful
build.  I'll try a build again in a short while to actually just check if,
in the event of a clean build both the ~/tmp and ~/files3 are written as
I've been having some disk space problems and haven't  given much thought
to deleting ~/tmp items.

As to your last point, I was asking if the geos, not rgeos was build from
source as it relates to availability of geos headers rather than rgeos.

Hopefully more qualified rgeos will chime in and set us both right.
Chris




On Mon, Aug 3, 2015 at 10:34 AM, Waichler, Scott R scott.waich...@pnnl.gov
wrote:

 Thanks for the suggestions, but I think what I need is help tracking down
 what the exact error is in the compilation.  Let me try again with the part
 of the output describing the error:

  install.packages(rgeos, dependencies = F, repos = 
 http://cran.fhcrc.org/;)
 . . .
 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/RtmpUjYUle/R.INSTALL41c15690b9e1/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 '/files3/R/R-3.2.1_install/lib64/R/library/rgeos'

 It says I should refer to config.log for more details.  The only
 config.log file I can find in the directory tree is the one for geos, which
 I installed a couple of years ago, and did not give me problems with
 previous installations of rgeos under earlier releases of R.  In case there
 is a clue, here is the output in that config.log around the cross compile
 message:

 configure:3682: result:
 configure:3704: checking whether we are cross compiling
 configure:3712: gcc -o conftestconftest.c  5
 configure:3716: $? = 0
 configure:3723: ./conftest

 Is there a config.log for the attempted rgeos installation?  Where would I
 find it?

  You're build is failing pretty early in the configuration process which
  suggests you are missing some tools in your development
  environment.  The latest geos was found. Was that a binary or built from
  source?  If from source you have the necessary tools in your dev
  environment and it may merely be a function of dropping the depends in
  you install.packages call

 Rgeos was built from source.

 Thanks,
 Scott Waichler
 PNNL


[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Problem installing rgeos

[chris english]

Scott,

You're build is failing pretty early in the configuration process which
suggests you are missing some tools in your development environment.  The
latest geos was found. Was that a binary or built from source?  If from
source you have the necessary tools in your dev environment and it may
merely be a function of dropping the depends in you install.packages
call

This just now on my box:

sessionInfo()
R version 3.2.1 (2015-06-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.2 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_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

other attached packages:
[1] cluster_2.0.3   TraMineR_1.8-10

loaded via a namespace (and not attached):
[1] tools_3.2.1RColorBrewer_1.1-2 boot_1.3-17
 install.packages(rgeos)
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'http://cran.cnr.Berkeley.edu/src/contrib/rgeos_0.3-11.tar.gz'
Content type 'application/x-gzip' length 247152 bytes (241 KB)
==
downloaded 241 KB

* installing *source* package ‘rgeos’ ...
** package ‘rgeos’ successfully unpacked and MD5 sums checked
configure: CC: gcc -std=gnu99
configure: CXX: g++
configure: rgeos: 0.3-8
checking for /usr/bin/svnversion... yes
configure: svn revision: 479
checking for geos-config... /usr/local/bin/geos-config
checking geos-config usability... yes
configure: GEOS version: 3.4.2
checking geos version at least 3.2.0... yes
checking geos-config clibs... yes
checking for gcc... 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... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -std=gnu99 accepts -g... yes
checking for gcc -std=gnu99 option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -std=gnu99 -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 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
** libs

This configuraton built and installed correctly. When my configurations
choke, I try to track down a working configuration like that above, check
my environment to see if I have everything that is going to be asked for.
If I don't have it I find out which package provides it and install the
developer version of the package so I have the headers and eventually I
have a successful build.

HTH,
Chris

On Tue, Jul 28, 2015 at 4:55 PM, Waichler, Scott R scott.waich...@pnnl.gov
wrote:

 Hi,

 I'm trying to install rgeos and I don't know how to respond to the error
 message:  configure: error: cannot run C compiled programs

  install.packages(rgeos, dependencies = Depends, repos = 
 http://cran.fhcrc.org/;)
 trying URL 'http://cran.fhcrc.org/src/contrib/rgeos_0.3-11.tar.gz'
 Content type 'application/x-gzip' length 247152 bytes (241 KB)
 ==
 downloaded 241 KB

 * installing *source* package ÆrgeosÇ ...
 ** package ÆrgeosÇ successfully unpacked and MD5 sums checked
 configure: CC: gcc -std=gnu99
 configure: CXX: g++
 configure: rgeos: 0.3-8
 checking for /usr/bin/svnversion... yes
 configure: svn revision: 479
 checking for geos-config... /usr/local/bin/geos-config
 checking geos-config usability... yes
 configure: GEOS version: 3.4.2
 checking geos version at least 3.2.0... yes
 checking geos-config clibs... yes
 checking for gcc... 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/RtmpFSN1i4/R.INSTALL25f63e6c5cb4/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Ç
 

Re: [R-sig-Geo] library fails to load in linux

[chris english]

http://r.789695.n4.nabble.com/Re-RGtk2-on-linux-quot-stack-smashing-detected-quot-td920903.html

googling the error message suggests pointers to external resources and
since these instances are VM's,
it is likely either the VM or underlying hardware if these are linux guest
on windows/iOS host.

HTH-
chris

On Thu, Jun 25, 2015 at 4:20 AM, Rolf Turner r.tur...@auckland.ac.nz
wrote:


 On 25/06/15 18:49, Harold-Jeffrey Ship wrote:

  Hi Rolf. Thank you for your quick response!

 I had tried using install.packages, and just now tried the method you
 suggested (R CMD INSTALL spatstat_1.42-1.tar.gz) with the same results.

 By the way, we have the same problem when we try on RHEL 6.4 on a
 different machine with R 3.2.0. I should mention that both of these are
 VM's.


 But was this on the same *physical* machine?  There *might* be some
 hardware (???) induced problem.  I'm clutching at straws here.

  I can send you the entire stack trace if it will help.


 Hmm.  Dunno if it will *help* --- I'm puzzled at the moment --- but I
 guess it can't hurt, so yes, please do send the stack trace.

 Is there anyone out there on the R-sig-Geo list running Ubuntu 12.4
 Precise?  If so could you try downloading the spatstat tarball and
 installing from source, and let me know what happens?

 Has anyone ever seen an error message about stack smashing (?!?!?!)
 before?  Anyone have any idea what this *means*?

 cheers,

 Rolf Turner


  Rolf Turner r.tur...@auckland.ac.nz wrote on 06/25/2015 01:23:18 AM:

   From: Rolf Turner r.tur...@auckland.ac.nz
   To: Harold-Jeffrey Ship/Haifa/IBM@IBMIL
   Cc: r-sig-geo@r-project.org, Adrian Baddeley
 adrian.badde...@uwa.edu.au
   Date: 06/25/2015 01:23 AM
   Subject: Re: [R-sig-Geo] library fails to load in linux
  
  
   How did you effect the installation command?  Did you use
  
install.packages(.)
  
   from the R command line?  Or did you use a precompiled Ubuntu binary?
 Or
   ?
  
   When I do
  
install.packages(spatstat, etc.)
  
   from the R command line, under my antiquated Fedora system, it installs
   with no problems.
  
   Have you tried downloading the tarball and installing from source, i.e.
  
R CMD INSTALL spatstat_1.42-1.tar.gz
  
   ???
  
   We need more detail.  If there really is a problem, we need to get to
   the bottom of it.
  
   You might possibly get more help on the R-sig-Debian list; please keep
   us informed of developments.
  
   cheers,
  
   Rolf Turner
  
   On 25/06/15 01:39, Harold-Jeffrey Ship wrote:
I have Ubuntu 12.04 Precise. I just installed R and want to install
spatstat. This is the R information:
   
R version 3.2.1 (2015-06-18) -- World-Famous Astronaut
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
   
When I try to install spatstat things look fine at first until it
 tries to
verify the installation by loading the library. It crashes, with
 the below
error message (snipped).
Any help would be greatly appreciated!
   
installing to
 /home/harold/R/x86_64-pc-linux-gnu-library/3.2/spatstat/libs
** R
** data
*** moving datasets to lazyload DB
** demo
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
*** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f3895976e57]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f3895976e20]
/usr/lib/R/lib/libR.so(+0xc9825)[0x7f3895f11825]
   [[alternative HTML version deleted]]


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


[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Extend spacetime ST

[chris english]

Thanks especially for reminding me of the ST vs STI  as of course I'm going
to want [,
aggregate and over.  I remember reading ST was virtual and then forgot.

Cheers,
Chris

On Sun, Jun 7, 2015 at 6:51 PM, Edzer Pebesma edzer.pebe...@uni-muenster.de
 wrote:



 On 06/07/2015 09:31 AM, chris english wrote:
  Edzer,
 
  Upon implementing your suggested:
 
  setClass(watch_circ, contains = ST, slots = c(ID = character))
  showClass(watch_circ)
  Class watch_circ [in .GlobalEnv]
 
  Slots:
 
  Name: IDsp  time   endTime
  Class: character   Spatial   xts   POSIXct
 
  Extends: ST
 
  I had to do more reading unless all I was going to say was Wow.
 
  setClass(watch_circ, contains = ST, slots = c(ID = character))
  showClass(watch_circ)
  Class watch_circ [in .GlobalEnv]
 
  Slots:
 
  Name: IDsp  time   endTime
  Class: character   Spatial   xts   POSIXct
 
  Extends: ST
 
  extends(watch_circ, fullInfo = TRUE)
  $ST
  An object of class SClassExtension
  Slot subClass:
  [1] watch_circ
 
  Slot superClass:
  [1] ST
 
  Slot package:
  [1] .GlobalEnv
 
  Slot coerce:
  function (from, strict = TRUE)
  {
  class(from) - ST
  from
  }
 
  Slot test:
  function (object)
  TRUE
  bytecode: 0x19516f58
  environment: namespace:methods
 
  Slot replace:
  function (from, to, value)
  {
  for (what in c(sp, time, ID, endTime)) slot(from,
  what) - slot(value, what)
  from
  }
 
  Slot simple:
  [1] TRUE
 
  Slot by:
  character(0)
 
  Slot dataPart:
  [1] FALSE
 
  Slot distance:
  [1] 1
 
 
  $watch_circ
  [1] TRUE
 
 
  Is there a way to control the slots =c(ID, character) order as to
  prepending or postpending.
  ie. (sp, time, endTime, ID) vs (ID, sp, time, endTime), or is the
  behavior of subclassing the
  superclass necessarily going to prepend the subclass slot(s) to the
  superclass slots. It just seems on
  a vernacular level that the order (sp, time, endTime, ID) is more
  ST-like and signals the extending.

 Slot order does not matter, as they're addressed only by name.

 
  contains = does just what I need, or more properly want, is powerful,
  and probably should be used
  with caution by the magician's apprentice.
 
  contains also leads me back to my prior 'wish list' of epochal endTimes.
  Even the constraint language
  of ST construction:
 
  if (any(is.na http://is.na(endTime)))
  stop(NA endTime values not allowed)
 
  suggests toying with the concept of multiple (user defined) endTimes, or
  it would merely say NA endTime value not allowed, singular as to
  value, full stop.  And with contains in mind and Pebesma (2008)
  Customizing spatial data
  classes and methods I start to see a way, ala Michael Sumner to
  potentially using epochal endTimes
  to extract all valid (or invalid for that matter) condition 2 quadrant 3
  paths for normals and subjects to
  evaluate as a TracksCollection.  Well, we'll see.

 You may want to think about subclassing STI instead of ST; ST is meant
 as a virtual class, not something to actually hold data. It has some
 methods, but only those that can be implemented identically for all
 subclasses. STI for instance has a subsetting method, [, as well as
 over  aggregate.

 
  Thanks very much,
 
  Chris
 
 
 
 
  On Sat, Jun 6, 2015 at 9:47 AM, Edzer Pebesma
  edzer.pebe...@uni-muenster.de mailto:edzer.pebe...@uni-muenster.de
  wrote:
 
  Chris, I'd use the following for a class watch_circ that extends ST
  and adds a character ID slot:
 
   setClass(watch_circ, contains = ST, slots = c(ID =
 character))
   showClass(watch_circ)
  Class watch_circ [in .GlobalEnv]
 
  Slots:
 
  Name: IDsp  time   endTime
  Class: character   Spatial   xts   POSIXct
 
  Extends: ST
 
 
 
  
 
  On 06/06/2015 07:58 AM, chris english wrote:
   Hi,
  
   I am attempting to extent spacetime ST to include an ID class for a
   spacetime watch circle object.  I am doing this in order to be
 able to
   relatively easily test that I have unique ID(s) across several
 similar
   objects for plotting purposes.
  
   I can build my watch circle:
  
   setClass(watch_circ,
   + slots = c(sp = Spatial, time = xts, ID = character,
   + endTime = POSIXct),
   + validity = function(object) {
   + stopifnot(length(object@sp) = 1)
   + stopifnot(nrow(object@time) = 1)
   + stopifnot(is.char(object@ID))
   + stopifnot(nrow(object@time) == length(object@endTime))
   + # do the tzones if not set, if set
   + tz1 = attr(object@time, tzone)
   + tz2 = attr(object@emdTime, tzone)
   + tz1.set = (!is.null(tz1)  !nchar(tz1)==0)
   + tz2.set = (!is.null(tz2)  !nchar(tz2)==0)
   + stopifnot(tz1 == tz2)
   + if (tz1.set)
   + stopifnot(tz1 == tz2)
   + if (any(names(object@time) %in% names(object@sp)))
   + stop(name conflict: attribute names in sp and time slot

Re: [R-sig-Geo] Extend spacetime ST

[chris english]

Edzer,

Upon implementing your suggested:

 setClass(watch_circ, contains = ST, slots = c(ID = character))
 showClass(watch_circ)
Class watch_circ [in .GlobalEnv]

Slots:

Name: IDsp  time   endTime
Class: character   Spatial   xts   POSIXct

Extends: ST

I had to do more reading unless all I was going to say was Wow.

 setClass(watch_circ, contains = ST, slots = c(ID = character))
 showClass(watch_circ)
Class watch_circ [in .GlobalEnv]

Slots:

Name: IDsp  time   endTime
Class: character   Spatial   xts   POSIXct

Extends: ST

 extends(watch_circ, fullInfo = TRUE)
$ST
An object of class SClassExtension
Slot subClass:
[1] watch_circ

Slot superClass:
[1] ST

Slot package:
[1] .GlobalEnv

Slot coerce:
function (from, strict = TRUE)
{
class(from) - ST
from
}

Slot test:
function (object)
TRUE
bytecode: 0x19516f58
environment: namespace:methods

Slot replace:
function (from, to, value)
{
for (what in c(sp, time, ID, endTime)) slot(from,
what) - slot(value, what)
from
}

Slot simple:
[1] TRUE

Slot by:
character(0)

Slot dataPart:
[1] FALSE

Slot distance:
[1] 1


$watch_circ
[1] TRUE


Is there a way to control the slots =c(ID, character) order as to
prepending or postpending.
ie. (sp, time, endTime, ID) vs (ID, sp, time, endTime), or is the behavior
of subclassing the
superclass necessarily going to prepend the subclass slot(s) to the
superclass slots. It just seems on
a vernacular level that the order (sp, time, endTime, ID) is more ST-like
and signals the extending.

contains = does just what I need, or more properly want, is powerful, and
probably should be used
with caution by the magician's apprentice.

contains also leads me back to my prior 'wish list' of epochal endTimes.
Even the constraint language
of ST construction:

if (any(is.na(endTime)))
stop(NA endTime values not allowed)

suggests toying with the concept of multiple (user defined) endTimes, or it
would merely say NA endTime value not allowed, singular as to value, full
stop.  And with contains in mind and Pebesma (2008) Customizing spatial
data
classes and methods I start to see a way, ala Michael Sumner to
potentially using epochal endTimes
to extract all valid (or invalid for that matter) condition 2 quadrant 3
paths for normals and subjects to
evaluate as a TracksCollection.  Well, we'll see.

Thanks very much,

Chris




On Sat, Jun 6, 2015 at 9:47 AM, Edzer Pebesma edzer.pebe...@uni-muenster.de
 wrote:

 Chris, I'd use the following for a class watch_circ that extends ST
 and adds a character ID slot:

  setClass(watch_circ, contains = ST, slots = c(ID = character))
  showClass(watch_circ)
 Class watch_circ [in .GlobalEnv]

 Slots:

 Name: IDsp  time   endTime
 Class: character   Spatial   xts   POSIXct

 Extends: ST



 

 On 06/06/2015 07:58 AM, chris english wrote:
  Hi,
 
  I am attempting to extent spacetime ST to include an ID class for a
  spacetime watch circle object.  I am doing this in order to be able to
  relatively easily test that I have unique ID(s) across several similar
  objects for plotting purposes.
 
  I can build my watch circle:
 
  setClass(watch_circ,
  + slots = c(sp = Spatial, time = xts, ID = character,
  + endTime = POSIXct),
  + validity = function(object) {
  + stopifnot(length(object@sp) = 1)
  + stopifnot(nrow(object@time) = 1)
  + stopifnot(is.char(object@ID))
  + stopifnot(nrow(object@time) == length(object@endTime))
  + # do the tzones if not set, if set
  + tz1 = attr(object@time, tzone)
  + tz2 = attr(object@emdTime, tzone)
  + tz1.set = (!is.null(tz1)  !nchar(tz1)==0)
  + tz2.set = (!is.null(tz2)  !nchar(tz2)==0)
  + stopifnot(tz1 == tz2)
  + if (tz1.set)
  + stopifnot(tz1 == tz2)
  + if (any(names(object@time) %in% names(object@sp)))
  + stop(name conflict: attribute names in sp and time slot must differ)
  + return(TRUE)
  + }
  + )
  getClassDef('watch_circ')
  Class watch_circ [in .GlobalEnv]
 
  Slots:
 
  Name: sp  timeID   endTime
  Class:   Spatial   xts character   POSIXct
 
  But not extend ST.
 
  setClass(watch_circ_1, representation = ST)
  getClassDef('watch_circ_1')
  Class watch_circ_1 [in .GlobalEnv]
 
  Slots:
 
  Name:   sptime endTime
  Class: Spatial xts POSIXct
 
  Extends: ST
  ?what am I doing wrong here?
 
  This is probably due to my shallow understanding of the difference
 between
  slots and representation, and possibly this whole operation is
 unnecessary
  if plot checks sp for unique ID(s) among objects.
 
  Thanks in advance,
 
  Cheers,
  Chris
 
[[alternative HTML version deleted]]
 
  ___
  R-sig-Geo mailing list
  R-sig-Geo@r-project.org
  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

Re: [R-sig-Geo] STIDF - endTime, STI - Track

[chris english]

 In looking at head(trackObj@connections) I note an absence of
 row.names() in @connections that one might find useful for tests between
 @connections and the STIDF data using match. Could I suggest this as an
 enhancement to Track?

Sure, but so far I've seen no cases where the points from which these
connections are computed have meaningful row.names. And the match is
essentially by row order, meaning you don't need base::match to match,
right?

History being a good guide, if you say I don't need match I know its
right.  I came to R from
SQL and view (viewed) base::match as something analogous to a where
clause in select, a comfort to myself in my query that I was asking for
what I
thought I was asking for, by name. I'll try and wrap my thinking around row
order relative to my needs and possible tests.  I think I was considering
ID's because
as I understand ST objects they are immutable once created so slap in
everything
you might need before you build it...

I'll concentrate on row order.

Thanks again,

Chris

On Tue, Jun 2, 2015 at 3:02 AM, Edzer Pebesma edzer.pebe...@uni-muenster.de
 wrote:



 On 06/02/2015 08:45 AM, chris english wrote:
  What I actually ended up doing was using spDistsN1 as commented in your
  code for use with sp-1.1-1 for the
  distances, and copied wholesale your directions_ll function and padded
  it with a trailing 0.0 as directions_ll
  returns N-1.
 
  In looking at head(trackObj@connections) I note an absence of
  row.names() in @connections that one might find useful for tests between
  @connections and the STIDF data using match. Could I suggest this as an
  enhancement to Track?

 Sure, but so far I've seen no cases where the points from which these
 connections are computed have meaningful row.names. And the match is
 essentially by row order, meaning you don't need base::match to match,
 right?

 
  Cheers,
 
  Chris
 
  On Mon, Jun 1, 2015 at 12:33 PM, chris english
  englishchristoph...@gmail.com mailto:englishchristoph...@gmail.com
  wrote:
 
  Edzer,
 
  Thank you for your considered reply.  I did in fact do something
  like you suggested and used my duration as my data.  It then
  occurred to me that there were probably knock on consequences to
  relaxing Track to an STI, and
  digging around find that gstat is looking for, or to my reading thus
  far, is looking for ST*DF for variogramsST and krigingST, so ST*DF
  it will be.
 
  Reading the code of Track (https://github.com/edzer/trajectories)
  has also led me to reconsider my data preparation process because
  the @connections contains pertinent information relating to the
  validity of a given trial.  The researcher's challenge was to
  observe the subject in real time and reject trails that moved from a
  central fixation beyond 2 degrees of visual angle.  And I now just
  find that this was done without the benefit of a bounding circle to
  guide the 2 degree assessment.
 
  So, what I think I might end up doing is borrow (and in my case then
  mangle) your elegant connections code to track distance relative to
  the central fixation point.  I assume that @connections$distance is
  the distance from one sampling point/time and the subsequent.  And
  then check whether accepted trials were actually valid as well.
  And that will then be my data for the STIDF.
 
  Thank you again,
 
  Chris
 
  On Fri, May 29, 2015 at 6:56 PM, Edzer Pebesma
  edzer.pebe...@uni-muenster.de
  mailto:edzer.pebe...@uni-muenster.de wrote:
 
 
 
  On 05/28/2015 12:28 PM, Chris English wrote:
   Hi,
  
   I am wondering about the role of endTime in STIDF objects.  I
  am examining eye tracking data (previously cleaned of blinks) in
  relation to
   presented stimuli that is for some subjects an optical
  illusion and for others not.  I want to examine where they were
  looking and when.
  
   My process is to make a STIDF from the eye tracking data case
  and a STSDF of the stimuli that was presented where and for how
  long,
   convert the STIDF to a Track then do some 'over' analysis.
  
   If I build my endTime for the STIDF using the delta() function
  on N samples, I think I get something like N-1 endTimes, or
  every sample
   is an endTime so N = N.
  
   If instead I am thinking of endTime(s) as an interval during
  which there is a cross hair and some tangential stimulus on the
  screen and
   endTime is when a subject responds in some manner I can't
  build an STDIF due to the following test:
  
   eye_5v1_stidf - STIDF(eye_5v1_sp, eye_5v1_time, eye_5v1_data,
   + eye_5v1_endTime)
   Error: nrow(object@time) == length(object@endTime) is not TRUE
   nrow(eye_5v1_time

Re: [R-sig-Geo] Pre-GDAL 2: rgdal changes - from all according to their means

[chris english]

Roger,

I second Michael Sumner's excitement. I built a POSTGist SFCGAL stack based
on GDAL 2.0.0beta, anticipating that I could seamlessly integrate with R
 and was disappointed that I couldn't use  2.0.0.beta  because at the point
only sp-1.1-1 was supported.

I have a couple of future projects that are going to fundamentally depend
on GDAL and I hope to be able to address them from within R.  As an R
beginner I'm happy I have in my notes on how to point to my /opt/gdal(
please excuse if generalizing between an installed /opt/gdal(2.0,0.beta and
 /usr/local/gdal(earlier.build)  build, but many people perhaps have not
been making a diary of R success(es).

In the simplest case it could be a reminder to us beginners how we might
load a library(rgdal(in this case 2.0.0.beta vs our normal
library(rgdal)).  Well we are beginners, but we still want out stuff to
work and we want to contribute to a successful and comprehensive 2.2.0
release. So we'll run our particular research examples through 2.0.0 and
report results, if we know how to load one vs. another library.

If intermediate or expert, different examples would be deployed.

I apologize in advance if these issues  or methods have already been
addressed at SVN and I failed to notice them.  If that is the case I will
dig further, and please ignore me.

I think GDAL and rgdal are intrinsically important tools to this community
and everyone wants them to work; please just tell us, by general example,
how we might be best of service.

I hope the foregoing is comprehensible. My thoughts, and looking forward to
to contributing in a useful fashion to this important package (as a
beginner).

Cheers,

Chris


The second beta of GDAL 2 is now available, and as of revision 535 on
 R-Forge, the legacy rgdal package passes R CMD check with either GDAL
 1.11.2 (or earlier) or GDAL 2.0.0 beta 2.

 One or two issues are known (Integer64 in vector fields and FIDs not
 supported in R; gdalDrivers() reports both raster and vector drivers; the
 MapInfo File TAB driver doesn't work for writing, ...), but others remain
 to be discovered.

 For those who need rgdal in production, and can install the 2.0.0 beta, it
 would be a really good use of time to identify issues now, rather than when
 GDAL 2 starts to become the standard, stable release. Anyone else needing
 an itch to scratch is also, of course, welcome to contribute.

 The rgdal package will continue to condition on GDAL 1 or 2, so hopefully
 those users who do not need to move to GDAL 2 will not be affected.
 However, it is worth noting that GDAL is maintained by very, very, few
 volunteers (even plural is questionable here), and when they feel that
 backporting fixed from GDAL 2 to GDAL 1 is taking time from more important
 things, you will be stranded with EOL software.

 So please consider taking the time to contribute to the idenfication of
 issues in the development version of rgdal built against GDAL 2 and/or 1,
 available for anonymous SVN checkout at:

 svn checkout svn://scm.r-forge.r-project.org/svnroot/rgdal/trunk

 Enjoy!

 Roger

 --
 Roger Bivand
 Department of Economics, Norwegian School of Economics,
 Helleveien 30, N-5045 Bergen, Norway.
 voice: +47 55 95 93 55; fax +47 55 95 91 00
 e-mail: roger.biv...@nhh.no

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


[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] STIDF - endTime, STI - Track

[chris english]

Edzer,

Thank you for your considered reply.  I did in fact do something like you
suggested and used my duration as my data.  It then occurred to me that
there were probably knock on consequences to relaxing Track to an STI, and
digging around find that gstat is looking for, or to my reading thus far,
is looking for ST*DF for variogramsST and krigingST, so ST*DF it will be.

Reading the code of Track (https://github.com/edzer/trajectories) has also
led me to reconsider my data preparation process because the @connections
contains pertinent information relating to the validity of a given trial.
The researcher's challenge was to observe the subject in real time and
reject trails that moved from a central fixation beyond 2 degrees of visual
angle.  And I now just find that this was done without the benefit of a
bounding circle to guide the 2 degree assessment.

So, what I think I might end up doing is borrow (and in my case then
mangle) your elegant connections code to track distance relative to the
central fixation point.  I assume that @connections$distance is the
distance from one sampling point/time and the subsequent.  And then check
whether accepted trials were actually valid as well.
And that will then be my data for the STIDF.

Thank you again,

Chris

On Fri, May 29, 2015 at 6:56 PM, Edzer Pebesma 
edzer.pebe...@uni-muenster.de wrote:



 On 05/28/2015 12:28 PM, Chris English wrote:
  Hi,
 
  I am wondering about the role of endTime in STIDF objects.  I am
 examining eye tracking data (previously cleaned of blinks) in relation to
  presented stimuli that is for some subjects an optical illusion and for
 others not.  I want to examine where they were looking and when.
 
  My process is to make a STIDF from the eye tracking data case and a
 STSDF of the stimuli that was presented where and for how long,
  convert the STIDF to a Track then do some 'over' analysis.
 
  If I build my endTime for the STIDF using the delta() function on N
 samples, I think I get something like N-1 endTimes, or every sample
  is an endTime so N = N.
 
  If instead I am thinking of endTime(s) as an interval during which there
 is a cross hair and some tangential stimulus on the screen and
  endTime is when a subject responds in some manner I can't build an STDIF
 due to the following test:
 
  eye_5v1_stidf - STIDF(eye_5v1_sp, eye_5v1_time, eye_5v1_data,
  + eye_5v1_endTime)
  Error: nrow(object@time) == length(object@endTime) is not TRUE
  nrow(eye_5v1_time)
  [1] 4724
  length(eye_5v1_endTime)
  [1] 63
 

 endTime is meant to give the end time of the time interval an
 observation refers to, and so the number of endTime s has to be
 identical to the number of time instances (number of observations). I
 guess you figure that out.

 
  Indeed, it is not true. But what information do I have in endTime other
 than my sensor sampling rate adjusted for blinks?  What I hoped to
  achieve was to compare the spacetime aspects of the Track data through
 time periods consistent with the time periods in the STSDF.
  Perhaps 'over' takes care of this for me and I don't have to attend if I
 just accept that endTime in the case of the STIDF is the end of each
  sample.
 
  The eye tracking data I am examining is fairly simple: x, y, cumulative
 sum of samples in ms, duration between samples; from which
  an STI can be constructed.  Not much more data than where the eyes were
 when.  It would seem that there would be a lot of simple sensor
  data of this sort so I wonder if Track can relax its requirement of
 STIDF to allow STI.

 Good point - I wonder that too. For now, you could feed it a data.frame
 with zero columns, e.g. data.frame(matrix(nrow=n, ncol=0))

 --
 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/
 Spatial Statistics Society http://www.spatialstatistics.info


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



[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] ground overlays in KML

[Chris English]

I imagine the final image is the last written.  

https://developers.google.com/kml/documentation/time 
explores various methods and additional tags employed for rendering sequences
and controlling overlays.
Hope it is in the right direction.

Chris

From: hodge...@uhd.edu
To: r-sig-geo@r-project.org
Date: Wed, 6 Mar 2013 02:07:11 +
Subject: [R-sig-Geo] ground overlays in KML

Hello again.

I'm not sure if I should ask this here, but I thought it might be a place to 
start:

I'm producing PNG files for ground overlays in Google Earth.  After some help 
from you this afternoon, my png files are ready.  However, the files do not run 
in sequence in Google Earth.  It shows the last file only.

Here is a little bit of the code:

kml xmlns:xsd=http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd; 
xmlns:xmlns=http://www.opengis.net/kml/2.2/; version=1.0
Document
Folder
GroundOverlay
name2001/name
TimeSpanbegin 2001-01-01 /begin
end 2001-12-31 /end/TimeSpan
Iconhrefpreda_01.png/hrefviewBoundScale0.75/viewBoundScale/Icon
LatLonBoxnorth36.48445398908/northsouth25.9875545196567/southeast-93.5186130430667/eastwest-106.704257739431/west/LatLonBox
/GroundOverlayGroundOverlay
name2002/name
TimeSpanbegin 2002-01-01 /begin
end 2002-12-31 /end/TimeSpan
Iconhrefpredb_01.png/hrefviewBoundScale0.75/viewBoundScale/Icon
LatLonBoxnorth36.48445398908/northsouth25.9875545196567/southeast-93.5186130430667/eastwest-106.704257739431/west/LatLonBox
/GroundOverlayGroundOverlay
name2003/name
TimeSpanbegin 2003-01-01 /begin
end 2003-12-31 /end/TimeSpan
Iconhrefpredc_01.png/hrefviewBoundScale0.75/viewBoundScale/Icon
LatLonBoxnorth36.48445398908/northsouth25.9875545196567/southeast-93.5186130430667/eastwest-106.704257739431/west/LatLonBox
/GroundOverlay
/Folder
/Document
kml



I'm also attaching the png files.  

Thanks for any help.



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

Re: [R-sig-Geo] R 3.0.0 and spatial classes

[Chris English]

Well, I hope something is done with Spatial Lines that seem strangely like 
orphans
while Spatial Points, Spatial Polygons, Spatial Grids and Spatial Pixels get 
all the love.
 Date: Sun, 16 Dec 2012 15:13:07 +
 From: b.rowling...@lancaster.ac.uk
 To: r-sig-geo@r-project.org
 Subject: [R-sig-Geo] R 3.0.0 and spatial classes
 
 There's been an announcement that the next version of R will be called
 3.0.0. Although not a massive change (compared to Python 2.x and 3.x,
 or Perl 4 to Perl 5), it might be a good opportunity to revise all the
 spatial classes in order to:
 
  * clear out any cruft
  * remove any inconsistencies
  * add some new functionality
  * unify across spatial packages
 
 The first thing that springs to mind, for example, is getting sp and
 raster to use the same functions for coordinate reference system
 processing. Doubtless there are other opprtunities for synergy...
 
  Yes, this may well break existing code, but if R is going to jump
 from 2 to 3 then that will break existing code too.
 
  Your ponderances, please...
 
 Barry
 
 ___
 R-sig-Geo mailing list
 R-sig-Geo@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo
  
[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] R 3.0.0 and spatial classes

[Chris English]

Edzer:
On Tue, Jul 17, 2012 at 2:34 PM, Agustin Lobo ~ from Barry Rowlingson
wrote:
To convert to SpatialLines, get the coordinates and build in the
usual convoluted manner:

  s=data.frame(x=runif(10),y=1:10,z=rnorm(10))
  coordinates(s)=~x+y
  L = SpatialLines(list(Lines(list(Line(coordinates(s))),X)))
  plot(L)
Convoluted is not the same as orphaned, certainly, but one gets the sense that
'Line' owes its existence to matters of plotting rather than line as line, 
independent of
drawing it, and this may have some import upon line analysis and the 
possibility of
arriving at topology and dispensing with shared lines and the like.

So love would be something like not depending on plotting for existence.  You 
guys
are the experts, mine are just the reflections of a mere mortal.
Chris
 Date: Sun, 16 Dec 2012 19:26:34 +0100
 From: edzer.pebe...@uni-muenster.de
 To: r-sig-geo@r-project.org
 Subject: Re: [R-sig-Geo] R 3.0.0 and spatial classes
 
 Could you please detail in which respect you believe they are orphaned,
 right now, and what kind of love they should receive?
 
 On 12/16/2012 07:16 PM, Chris English wrote:
  
  Well, I hope something is done with Spatial Lines that seem strangely like 
  orphans
  while Spatial Points, Spatial Polygons, Spatial Grids and Spatial Pixels 
  get all the love.
  Date: Sun, 16 Dec 2012 15:13:07 +
  From: b.rowling...@lancaster.ac.uk
  To: r-sig-geo@r-project.org
  Subject: [R-sig-Geo] R 3.0.0 and spatial classes
 
  There's been an announcement that the next version of R will be called
  3.0.0. Although not a massive change (compared to Python 2.x and 3.x,
  or Perl 4 to Perl 5), it might be a good opportunity to revise all the
  spatial classes in order to:
 
   * clear out any cruft
   * remove any inconsistencies
   * add some new functionality
   * unify across spatial packages
 
  The first thing that springs to mind, for example, is getting sp and
  raster to use the same functions for coordinate reference system
  processing. Doubtless there are other opprtunities for synergy...
 
   Yes, this may well break existing code, but if R is going to jump
  from 2 to 3 then that will break existing code too.
 
   Your ponderances, please...
 
  Barry
 
  ___
  R-sig-Geo mailing list
  R-sig-Geo@r-project.org
  https://stat.ethz.ch/mailman/listinfo/r-sig-geo

  [[alternative HTML version deleted]]
  
  ___
  R-sig-Geo mailing list
  R-sig-Geo@r-project.org
  https://stat.ethz.ch/mailman/listinfo/r-sig-geo
  
 
 -- 
 Edzer Pebesma
 Institute for Geoinformatics (ifgi), University of Münster
 Weseler Straße 253, 48151 Münster, Germany. Phone: +49 251
 8333081, Fax: +49 251 8339763  http://ifgi.uni-muenster.de
 http://www.52north.org/geostatistics  e.pebe...@wwu.de
 
 ___
 R-sig-Geo mailing list
 R-sig-Geo@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo
  
[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] conservative continental reprojection for lon-lat input?

[Chris English]

Tom,

Link to advice from Tomislav Hengl
http://grokbase.com/p/r/r-sig-geo/1226xdq5sh/help-to-analisys-spatio-temporal 

expresses preference for gstat but suggests Stem
might do the trick by design

http://cran.r-project.org/web/packages/Stem/ 

Model accepts UTMx, UTMy or LAt/LON coords(Stem.pdf, Stem.Model(...))

Not sure that this will help, but as you can spell
Eulerian you've a better grasp of the problem contemplated.

Hope this is both relevant and helps,
Chris

 From: tom_ro...@pobox.com
 To: r-sig-geo@r-project.org
 Date: Wed, 7 Nov 2012 14:08:32 -0500
 Subject: [R-sig-Geo] conservative continental reprojection for lon-lat  
 input?
 
 
 http://cran.r-project.org/web/packages/gstat/vignettes/gstat.pdf
  Package gstat assumes that data are projected, i.e.
  [data] should not be provided as [latitude]/longitude.
 
 How should a continental-scale reboxing project best cope with this
 restriction? Why I ask:
 
 I'm a student attempting to create 3D N2O initial conditions (ICs) and
 boundary conditions (BCs) for a run of an Eulerian atmospheric model
 over North America, specifically
 
 https://github.com/TomRoche/cornbeltN2O/wiki/AQMEII-North-American-domain#wiki-EPA
  projection: LCC (Lambert Conformal Conic)
  standard parallels: 33°, 45° (N)
  lon/lat projection center: -97° (W), 40° (N)
  domain origin (from projection center, in km): -2556 (W), -1728 (S)
  horizontal grid spacing: 12 km
  horizontal grid count (x,y): 459, 299
  vertical grid count: 34
  max height: 50 mb
 
 I'm attempting to create IC/BCs for my model using, as input, the output
 of a more coarse-scaled 3D global inventory: 2.5° lon x 1.875° lat, with
 vertical layer heights more resembling those of the output domain
 (though the layer positions differ). This global input provides an
 approximate value for the mass concentration of N2O in the air in each
 of its voxels, or boxes.
 
 So I'll need to rebox the global input onto the local domain: i.e.,
 for each box in the North American projected domain (i.e., for the
 local output), estimate its mass concentration based on those provided
 for the global input. I was hoping to do this directly, in the manner
 that raster::projectRaster allows one to regrid from lon-lat to LCC.
 But direct reboxing from lon-lat appear problematic with package=gstat,
 however. Am I missing something?
 
 If not, I'm wondering: what would be the most safe, conservative way to
 impose a projection on the global data in order to input it to gstat?
 E.g., could I
 
 1. reduce the extent of the input from global to a subglobal area
somewhat larger than my target domain (which is -130 - -59.5° lon,
23.5 - 58.5° lat)
 
 2. impose some CRS on the subglobal data such that the areas of the CRS
gridcells equal or closely approximate those of the subglobal grid.
 
 ? If so, which CRS to use?
 
 TIA, Tom Roche tom_ro...@pobox.com
 
 ___
 R-sig-Geo mailing list
 R-sig-Geo@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo
  
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[R-sig-Geo] Geographical CRS given to non-conformant data:

[Chris English]

Hi,

Trying to make a SpatialPoints(obj) and encounter the following:

 out_dest_sp - SpatialPoints(out_dest, proj4string=proj)
   
Error in validityMethod(as(object, superClass)) : 
   Geographical CRS given to non-conformant data: -173.07856

 bbox(out_orig_spdf)
 min   max
coords.x1 -173.07856 -67.51471
coords.x2   19.60124  70.22112

 y - which(out0910$lat_outdest  -173.07856)
 y
integer(0)

 y - which(out0910$lat_outdest  -67.51471)
 y
integer(0)
 y - which(out0910$long_outdest  19.60124)
 y
integer(0)

 y - which(out0910$long_outdest  70.22112)
 y
integer(0)

CRS arguments: +proj=longlat +ellps=GRS80

Is there a way to set a floor on the out0910$ values or
track down those non-conformant by row.name?

Is this a tolerance setting?

Any help appreciated. Thanks

Chris
  
[[alternative HTML version deleted]]

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

[R-sig-Geo] Great Circles US IRS Migration mapping

[Chris English]

Hi,

I am trying to map US migration from IRS files using great circles.  The IRS 
provides two files (either state or county level) 
for origin and destination in and out of the state or county. The code thus far 
gives me a spatialpolygonsdataframe:

 str(county)
Formal class 'SpatialPolygonsDataFrame' [package sp] with 5 slots
  ..@ data   :'data.frame': 3258 obs. of  15 variables:
  .. ..$ area   : num [1:3258] 0.00303 0.13356 0.00267 0.74387 0.93214 
...
  .. ..$ perimeter  : num [1:3258] 0.257 2.05 0.247 5.424 6.036 ...
  .. ..$ co99_d00_  : num [1:3258] 1088 1277 157 158 159 ...
  .. ..$ co99_d00_i : num [1:3258] 1087 1276 156 157 158 ...
  .. ..$ state  : Factor w/ 49 levels 01,04,05,..: 38 37 46 25 46 
26 22 49 46 46 ...
  .. ..$ county : Factor w/ 301 levels 001,003,005,..: 6 52 33 48 
5 65 43 25 41 41 ...
  .. ..$ name   : Factor w/ 1799 levels Abbeville,Acadia,..: 1704 
1094 1486 1387 303 1040 899 1646 1730 1730 ...
  .. ..$ lsad   : Factor w/ 5 levels 06,08,09,..: 1 1 1 1 1 1 1 1 
1 1 ...
  .. ..$ lsad_trans : Factor w/ 3 levels city,County,..: 2 2 2 2 2 2 2 
2 2 2 ...
  .. ..$ fips   : chr [1:3258] 44009 42091 53057 30085 ...
  .. ..$ m_0910_in_dest : int [1:3258] NA NA NA NA NA 58798 NA NA NA NA ...
  .. ..$ m_0910_in_orig : int [1:3258] NA NA NA NA NA 58803 NA NA NA NA ...
  .. ..$ m_0910_out_dest: int [1:3258] 3472 3054 3209 58014 3269 59154 51486 
3505 2117 2117 ...
  .. ..$ m_0910_out_orig: int [1:3258] 84440 83024 106089 58018 104703 59149 
51481 110502 106622 106622 ...
  .. ..$ labpt  : num [1:3258, 1:2] -71.6 -75.4 -122.6 -105 -120.6 ...
  .. ..- attr(*, data_types)= chr [1:9] N N N N ...
  ..@ polygons   :List of 3258

I  used the following to extract the long/lat of the label point @labpt to use 
as startpoints or endpoints for the great circle lines
depending on whether they were dest(ination) or orig(in) and dest or orig was 
not NA.

## reach down to the @labpt level of county using ggplot2 and gpclib to 
## get coordinates of county label points to use as start and endpoints
## for make lines function
require(ggplot2)
require(gpclib)

## in any case, using ggplot2 capabilities
county$labpt = coordinates(county)

county$labpt gives me the centroid of all my polygons and I think these follow 
the order 1:3258 

 county$labpt[1:1,1:2] 
[1] -71.57849  41.17788
 county$fips[1]
[1] 44009

so county$fips[1] 44009 should have its centroid at [1] -71.57849  41.17788

I'm trying to figure out how I am going to make lines between say 
county$in_start[6] as startpoint

 county$in_start - !is.na(county$m_0910_in_orig)
 county$in_start
   [1] FALSE FALSE FALSE FALSE FALSE  TRUE FALSE FALSE FALSE FALSE FALSE FALSE

and county$in_end[6] as endpoint

 county$in_end - !is.na(county$m_0910_in_dest)
 county$in_end
   [1] FALSE FALSE FALSE FALSE FALSE  TRUE FALSE FALSE FALSE FALSE FALSE FALSE

I feel like I have most of the pieces but have lost track somewhere.  Any 
suggestions
greatly appreciated.

Thanks,
Chris  



  
[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Plot spatial time series

[Chris English]

Thiago,

With uncertainty, as this is beyond my pay grade, might I suggest looking at 
spacetime,

http://cran.r-project.org/web/packages/spacetime/index.html ,

using Matt's method to extract the dates from file names to become your xts 
date object.

As all the spacetime objects derive from ST (and xts), spatial pixels data 
frame would be available.

There are additionally overlay and aggregation methods available in spacetime 
for your data,

but I have not explored these as yet.  I hope this is useful rather than a 
distraction.

Chris English
  
[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] neighborly ordering of spdf data/spacetime

[Chris English]

Robert,

Thank you, it performs exactly as desired.  Until you

shared the extraction notation, I could not have conceived how

it might look, but now looks natural:

combine the thing itself 5, with neighbors of 5 and their data.

I take note of Dr. Pebesma's query as to why I would want to do

this, and it may amount to simplifying some report graphics as

against any analytical objectives.  But, to be seen.  I'm going to

continue working with this neighbor approach to see if it helps with

organizing data frames as I move into states and counties where

I have little or no prior knowledge of how counties are placed.

Thanks again,

Chris

Date: Thu, 24 May 2012 14:32:52 -0700
Subject: Re: [R-sig-Geo] neighborly ordering of spdf data/spacetime
From: r.hijm...@gmail.com
To: sgl...@hotmail.com
CC: r-sig-geo@r-project.org

Chris, 
You can get the neighbors of a polygon from the nb object. For example, after 
you do this:
nb - poly2nb(nj_cty_2.spdf)

the neighbors of polygon 5 would be
nb[[5]]
And you can extract them all (and plot them) like this
pol5andngb -  nj_cty_2.spdf [ c(5, nb[[5]]),  ] 

Robert
On Thu, May 24, 2012 at 1:54 PM, Chris English sgl...@hotmail.com wrote:



Hello,

I am exploring some US county level housing data.  I started with New Jersey 
and built a SPDF and subsequently a STFDF.  Data and spatial were in 
alphabetical order that madematching straight forward.

The problem arises that alphabetically named spatial attributes, i.e. atlantic, 
bergen (counties),are not close physically, indeed, often not neighbors.

When trying to plot a variable of interest among some neighboring counties 
instead of the wholestate, hudson, bergen, essex, for example, many other 
counties have to be plotted because the SPDF was created in alphabetical order.


I've spent the afternoon looking at spdep and deriving various neighbor, for 
example:

  nj_cty_hu_nb - poly2nb(nj_cty_2.spdf) summary(nj_cty_hu_nb)Neighbour list 
  object:Number of regions: 21 Number of nonzero links: 82 Percentage nonzero 
  weights: 18.5941 Average number of links: 3.904762 Link number distribution:


2 3 4 5 6 7 3 5 7 4 1 1 3 least connected regions:cape may hudson salem with 2 
links1 most connected region:morris with 7 links

Basically I'm wondering if someone can suggest how I might go back and recreate 
my spatial polygonsobject ordered by a more optimal neighbor approach and 
thence construct a new spdf based upon amore neighborly order than a-z.


Thanks in advance,Chris





[[alternative HTML version deleted]]



___

R-sig-Geo mailing list

R-sig-Geo@r-project.org

https://stat.ethz.ch/mailman/listinfo/r-sig-geo


  
[[alternative HTML version deleted]]

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

[R-sig-Geo] neighborly ordering of spdf data/spacetime

[Chris English]

Hello,
I am exploring some US county level housing data.  I started with New Jersey 
and built a SPDF and subsequently a STFDF.  Data and spatial were in 
alphabetical order that madematching straight forward.  
The problem arises that alphabetically named spatial attributes, i.e. atlantic, 
bergen (counties),are not close physically, indeed, often not neighbors.
When trying to plot a variable of interest among some neighboring counties 
instead of the wholestate, hudson, bergen, essex, for example, many other 
counties have to be plotted because the SPDF was created in alphabetical order.
I've spent the afternoon looking at spdep and deriving various neighbor, for 
example:
  nj_cty_hu_nb - poly2nb(nj_cty_2.spdf) summary(nj_cty_hu_nb)Neighbour list 
  object:Number of regions: 21 Number of nonzero links: 82 Percentage nonzero 
  weights: 18.5941 Average number of links: 3.904762 Link number distribution:
2 3 4 5 6 7 3 5 7 4 1 1 3 least connected regions:cape may hudson salem with 2 
links1 most connected region:morris with 7 links
Basically I'm wondering if someone can suggest how I might go back and recreate 
my spatial polygonsobject ordered by a more optimal neighbor approach and 
thence construct a new spdf based upon amore neighborly order than a-z.  
Thanks in advance,Chris

  
[[alternative HTML version deleted]]

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

[R-sig-Geo] proper syntax for passing MINUSERPIXELVALUE, MAXUSERPIXELVALUE to Terragen driver

[Chris English]

Dear List,
I have a SpatialGridDataFrame that from which I hope to createa Terragen file.
My consistent error in create2GDAL:
GDAL Error 1: Inverted, flat, or unspecified span for Terragen file.
I need to pass the options =c(MINUSERPIXELVALUE = 1, 
MAXUSERPIXELVALUE=2736)to the Terragen driver and don't know how.
Details of writeGDAL suggest:it may also be necessary in some cases to escape 
quotation markes if included in thestring passed to the driver.
As there aren't embedded quotation marks, I don't think this applies.  But, 
ifone doesn't establish the MIN/MAX~USERPIXELVALUE, one will always get the 
aboveerror.
Thank you,
Chris English







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

Re: [R-sig-Geo] Creating SpatialGridDataFrame - unequal number of objects

[Chris English]

Re: [R-sig-Geo] R spatial matrix to SpatialGridDataFrameEdzer Pebesma
Tue, 26 Jan 2010 00:54:21 -0800 suggested the following to Ian McCallum - 
herein adapted
 bike_1- list(x = 1:1824, y = 1:1824, z = matrix(rep(1824:1, each=1824), 
ncol=1824, byrow=TRUE))
 bgrid- GridTopology(cellcentre.offset = c(bike_1$x[1], bike_1$y[1]), 
 cellsize = + c(bike_1$x[1], bike_1$y[1]), cells.dim = dim(bike_1$z))
 bike_1_sgdf- SpatialGridDataFrame(bgrid, data.frame(depth = + 
 as.vector(bike_1$z[,ncol(bike_1$z):1])))
 image(bike_1_sgdf, axes = TRUE)
This produces the highly desired and previously elusive SGDF. I would neverhave 
figured out the data.frame(depth =  etc myself and have plenty of examples 
ofSGDF's that contain none of the values I sought to show for my efforts.
This approach requires x=z and so my prior z=y is untenable. When viewed in 
imagethe values seem rotated clockwise 90 deg, which I guess is just matrix vs 
raster origin. 
I was hoping to attain a grid of x= 1824, y= 1368, and z values descending from 
1368:1 by column.  And thence create a Terragen file through rgdal.
I suppose I can rotate, clip  etc post rgdal but wonder if I can simplify my 
approach.
Thanks,Chris



 From: tgrif...@uaex.edu
 Subject: RE: [R-sig-Geo] Creating SpatialGridDataFrame - unequal number of 
 objects
 Date: Sat, 28 May 2011 18:39:09 -0500
 To: sgl...@hotmail.com; r-sig-geo@r-project.org



 Terry Griffin, PhD
 tgrif...@uaex.edu
 501.249.6360

 -Original Message-
 From: Chris English 
 Sent: Saturday, May 28, 2011 11:20 AM
 To: r-sig-geo@r-project.org
 Subject: [R-sig-Geo] Creating SpatialGridDataFrame - unequal number of objects


 Dear List:
 I have a SpatialGrid for which I am trying to make adata.frame and thence a 
 SpatialGridDataFrame.
 I can't seem to get the size of data.frame and gridto match up.  I assume I'm 
 missing something straight forward.

  summary(grid1)Object of class SpatialGridCoordinates:  minmaxx 0.5 
 1824.5y 0.5 1368.5Is projected: NA proj4string : [NA]Number of points: 2Grid 
 attributes:  cellcentre.offset cellsize cells.dimx 11 
  1824y 11  1368 help(str) bike_mat- 
 matrix(rep(1368:1, each=1824), ncol=1824, byrow=TRUE) bike_df- 
 as.data.frame(bike_mat) bike_sgdf_1- 
 SpatialGridDataFrame(grid1,bike_df)Error in validityMethod(object) :   
 unequal number of objects in full grid and data slot
 Thank you for you assistance.
 Chris
 ___
 R-sig-Geo mailing list
 R-sig-Geo@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo
  
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

[R-sig-Geo] Creating SpatialGridDataFrame - unequal number of objects

[Chris English]

Dear List:
I have a SpatialGrid for which I am trying to make adata.frame and thence a 
SpatialGridDataFrame.
I can't seem to get the size of data.frame and gridto match up.  I assume I'm 
missing something straight forward.

 summary(grid1)Object of class SpatialGridCoordinates:  min    maxx 0.5 1824.5y 
0.5 1368.5Is projected: NA proj4string : [NA]Number of points: 2Grid 
attributes:  cellcentre.offset cellsize cells.dimx                 1        1   
   1824y                 1        1      1368 help(str) bike_mat- 
matrix(rep(1368:1, each=1824), ncol=1824, byrow=TRUE) bike_df- 
as.data.frame(bike_mat) bike_sgdf_1- SpatialGridDataFrame(grid1,bike_df)Error 
in validityMethod(object) :   unequal number of objects in full grid and data 
slot
Thank you for you assistance.
Chris 
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo