Re: [R-sig-Geo] STIDF - endTime, STI - Track
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] OSX, rgdal, GDAL drivers and HDF4
Have you tried with the homebrew project? HDF4 isn¹t a default supported driver, but it¹s easy enough to add: brew install hdf4 # prefer hdf4 links over NetCDF brew link --overwrite hdf4 brew install gdal --complete --enable-unsupported --with-hdf4 # check what drivers are installed, list should include Œhdf4¹: gdal-config --formats I¹d use that as a starting point. Cheers, Shaun On 6/2/15, 12:11 PM, Ben Tupper btup...@bigelow.org wrote: Hello, This is my attempt to look before I leap into installing GDAL on OSX. (You can probably hear my pitiful groaning and knee-knocking in the background.) I want to read many HDF4 files for which I do not have the GDAL HDF4 driver installed. I used William Kyngesburye's nice framework (http://www.kyngchaos.com/software:frameworks) to install GDAL but it came without the HDF4 driver. Reading this somewhat dated exchange... http://r-sig-geo.2731867.n2.nabble.com/Read-HDF-files-td6750856.html ... I think I understand that if I want the HDF4 driver I must build GDAL on my system manually. Is my understanding correct, or is there another (easier) way to read HDF4 files directly in R? Thanks! Ben library(rgdal) Loading required package: sp rgdal: version: 0.9-3, (SVN revision 530) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 1.11.2, released 2015/02/10 Path to GDAL shared files: /Library/Frameworks/R.framework/Versions/3.2/Resources/library/rgdal/gdal Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491] Path to PROJ.4 shared files: /Library/Frameworks/R.framework/Versions/3.2/Resources/library/rgdal/proj Linking to sp version: 1.1-0 x - gdalDrivers() any(x$name %in% c(HDF4, HDF)) [1] FALSE sessionInfo() R version 3.2.0 (2015-04-16) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.9.5 (Mavericks) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] rgdal_0.9-3 sp_1.1-0 loaded via a namespace (and not attached): [1] grid_3.2.0 lattice_0.20-31 Ben Tupper Bigelow Laboratory for Ocean Sciences 60 Bigelow Drive, P.O. Box 380 East Boothbay, Maine 04544 http://www.bigelow.org ___ 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] Quickest way to tell if an arbitrary file is a raster/vector?
Tricky, because OGR (at least) doesn't have a 1-1 mapping of file to data source * I think any component of a shapefile can be used as a data source of a single-layer. Command-line ogrinfo on my machine thinks so: $ ogrinfo DSMW.dbf INFO: Open of `DSMW.dbf' using driver `ESRI Shapefile' successful. 1: DSMW (Polygon) As does rgdal::functions: ogrListLayers(DSMW.shx) [1] DSMW attr(,driver) [1] ESRI Shapefile attr(,nlayers) [1] 1 * Then a folder containing shapefiles can be used as a data source where each shapefile is a layer... I'd think about wrapping ogrInfo and GDALinfo in try clauses, and then clearing up the duplicates... Barry On Tue, Jun 2, 2015 at 6:09 PM, Jonathan Greenberg j...@illinois.edu wrote: r-sig-geo'ers: I'm working on a GIS cataloging function to add-in to spatial.tools, and one thing I'm struggling with is the quickest way to tell if a given file is a GDAL/OGR readable raster/vector. Any ideas? --j [[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
Re: [R-sig-Geo] Pre-GDAL 2: rgdal changes - from all according to their means
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] Scales in bubble {sp}
Good suggestion; I added this, on r-forge. On 06/02/2015 06:10 PM, Steinbuch, Luc wrote: Hi, I would like to have nice scales with '�N' etc. in a bubble plot. Example: ### library(sp) ### example dataset sp_yield = new(SpatialPointsDataFrame , data = structure(list(Yw = c(6.6, 6, 7.7, 4.4, 7.4)), .Names = Yw, row.names = c(NA, 5L), class = data.frame) , coords.nrs = numeric(0) , coords = structure(c(9.817, 6.017, -4.317, -0.137, -0.867, 10.283, 9.1, 11.167, 12.974, 10.8), .Dim = c(5L, 2L), .Dimnames = list(NULL, c(Longitude_dd, Latitude_dd))) , bbox = structure(c(-4.317, 9.1, 9.817, 12.974), .Dim = c(2L, 2L), .Dimnames = list( c(Longitude_dd, Latitude_dd), c(min, max))) , proj4string = new(CRS , projargs = +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 ) ) ### with spplot (and this datum, and this area in sp_yield) automatically nice scales are generated, # with degrees North and degrees East: spplot(sp_yield, zcol = Yw, scales = list(draw = TRUE) ) ### .. with bubble however not: bubble(sp_yield, zcol = Yw, scales = list(draw = TRUE) ) ### Any ideas..? Luc [[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://www.jstatsoft.org/ Computers Geosciences: http://elsevier.com/locate/cageo/ Spatial Statistics Society http://www.spatialstatistics.info signature.asc Description: OpenPGP digital signature ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] How to multiply my raster by factors depending on each polygon
Hello, I want to correct my raster with correction factors for each polygon. each polygon I have to correct it with its own correction factor. Is it possible to make the manipulation at once: import my raster and my polygons, then I will multiply my raster with a factor of each polygon. or I must to cut my raster according to all polygons and then I multiply each raster by its factor, one by one (it is too long) Best regards -- View this message in context: http://r-sig-geo.2731867.n2.nabble.com/How-to-multiply-my-raster-by-factors-depending-on-each-polygon-tp7588395.html Sent from the R-sig-geo mailing list archive at Nabble.com. ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] Bug in raster projectRaster?
Hi, I'm sorry I cant post a reproducible example, but the data sets involve are too large. I'm currently trying to create a mosaic from 2 different Landsat 7 scenes. One of them is in UTM 18 and the other in UTM 17. Before using the mosaic command, I'm doing LandsatTransform=projectRaster(from=LandsatUTM17, to=LandsatUTM18) but i get a raster that is full of NAs and the following warning message Warning message: In .rasterFromRasterFile(grdfile, band = band, objecttype, ...) : size of values file does not match the number of cells (given the data type) Not sure what to do. Any help is really appreciated. Thanks, Mauricio [[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] Bug in raster projectRaster?
Check first if there's any intersection between their extents: library(rgdal);library(raster) ## ... whatever you did to create these objects . . . ## what follows is untested ext18 - extent(LandsatUTM18) ext17_in_18 - projectExtent(LandsatUTM17, crs = projection(LandsatUTM18)) plot(union(ext18, ext17_in_18)) plot(ext18, add = TRUE) plot(ext17_in_18, add = TRUE) You might need to reproject to the union of their extents? But this is bad, generally if you need to align data from two incompatible projections there's probably a better path. Are you forced to use UTM? Why? Cheers, Mike On Wed, 3 Jun 2015 at 01:29 Mauricio Romero mauricioromerolond...@gmail.com wrote: Hi, I'm sorry I cant post a reproducible example, but the data sets involve are too large. I'm currently trying to create a mosaic from 2 different Landsat 7 scenes. One of them is in UTM 18 and the other in UTM 17. Before using the mosaic command, I'm doing LandsatTransform=projectRaster(from=LandsatUTM17, to=LandsatUTM18) but i get a raster that is full of NAs and the following warning message Warning message: In .rasterFromRasterFile(grdfile, band = band, objecttype, ...) : size of values file does not match the number of cells (given the data type) Not sure what to do. Any help is really appreciated. Thanks, Mauricio [[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] Scales in bubble {sp}
Hi, I would like to have nice scales with '�N' etc. in a bubble plot. Example: ### library(sp) ### example dataset sp_yield = new(SpatialPointsDataFrame , data = structure(list(Yw = c(6.6, 6, 7.7, 4.4, 7.4)), .Names = Yw, row.names = c(NA, 5L), class = data.frame) , coords.nrs = numeric(0) , coords = structure(c(9.817, 6.017, -4.317, -0.137, -0.867, 10.283, 9.1, 11.167, 12.974, 10.8), .Dim = c(5L, 2L), .Dimnames = list(NULL, c(Longitude_dd, Latitude_dd))) , bbox = structure(c(-4.317, 9.1, 9.817, 12.974), .Dim = c(2L, 2L), .Dimnames = list( c(Longitude_dd, Latitude_dd), c(min, max))) , proj4string = new(CRS , projargs = +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 ) ) ### with spplot (and this datum, and this area in sp_yield) automatically nice scales are generated, # with degrees North and degrees East: spplot(sp_yield, zcol = Yw, scales = list(draw = TRUE) ) ### .. with bubble however not: bubble(sp_yield, zcol = Yw, scales = list(draw = TRUE) ) ### Any ideas..? Luc [[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] OSX, rgdal, GDAL drivers and HDF4
Hello, This is my attempt to look before I leap into installing GDAL on OSX. (You can probably hear my pitiful groaning and knee-knocking in the background.) I want to read many HDF4 files for which I do not have the GDAL HDF4 driver installed. I used William Kyngesburye's nice framework (http://www.kyngchaos.com/software:frameworks) to install GDAL but it came without the HDF4 driver. Reading this somewhat dated exchange... http://r-sig-geo.2731867.n2.nabble.com/Read-HDF-files-td6750856.html ... I think I understand that if I want the HDF4 driver I must build GDAL on my system manually. Is my understanding correct, or is there another (easier) way to read HDF4 files directly in R? Thanks! Ben library(rgdal) Loading required package: sp rgdal: version: 0.9-3, (SVN revision 530) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 1.11.2, released 2015/02/10 Path to GDAL shared files: /Library/Frameworks/R.framework/Versions/3.2/Resources/library/rgdal/gdal Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491] Path to PROJ.4 shared files: /Library/Frameworks/R.framework/Versions/3.2/Resources/library/rgdal/proj Linking to sp version: 1.1-0 x - gdalDrivers() any(x$name %in% c(HDF4, HDF)) [1] FALSE sessionInfo() R version 3.2.0 (2015-04-16) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.9.5 (Mavericks) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] rgdal_0.9-3 sp_1.1-0 loaded via a namespace (and not attached): [1] grid_3.2.0 lattice_0.20-31 Ben Tupper Bigelow Laboratory for Ocean Sciences 60 Bigelow Drive, P.O. Box 380 East Boothbay, Maine 04544 http://www.bigelow.org ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] Quickest way to tell if an arbitrary file is a raster/vector?
r-sig-geo'ers: I'm working on a GIS cataloging function to add-in to spatial.tools, and one thing I'm struggling with is the quickest way to tell if a given file is a GDAL/OGR readable raster/vector. Any ideas? --j [[alternative HTML version deleted]] ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
