From frtog at vestas.com Sun May 1 06:42:51 2016 From: frtog at vestas.com (=?iso-8859-1?Q?Frede_Aakmann_T=F8gersen?=) Date: Sun, 1 May 2016 04:42:51 +0000 Subject: [R-sig-Geo] problem with predict() in package raster and factor variables In-Reply-To: <1462012372564.1868@imr.no> References: <1462012372564.1868@imr.no> Message-ID: Hi Genoveva You haven't got a response to your question mainly due to a) missing information and b) missing reproducible example. If you had provided the missing information I guess you would have solved the problem yourself. I have never used raster::predict() but having a look at man for that function and you error message there is probably some differences between the data used to estimate the random forest model (you call that a subset of the object 'v') and the data in 'subbrick'. You should provide the structure of data used to fit the random forest model and 'subbrick': > str(v) > str(subbrick) Please also show all the relevant R code to obtain what you want in case the error message is not related to difference in the creation of the subset of 'v' and 'subbrick' Yours sincerely / Med venlig hilsen Frede Aakmann T?gersen Specialist, M.Sc., Ph.D. Plant Performance & Modeling Technology & Service Solutions T +45 9730 5135 M +45 2547 6050 frtog at vestas.com http://www.vestas.com Company reg. name: Vestas Wind Systems A/S This e-mail is subject to our e-mail disclaimer statement. Please refer to www.vestas.com/legal/notice If you have received this e-mail in error please contact the sender. -----Original Message----- From: R-sig-Geo [mailto:r-sig-geo-bounces at r-project.org] On Behalf Of Gonzalez-Mirelis Genoveva Sent: 30. april 2016 12:33 To: r-sig-geo at r-project.org Subject: [R-sig-Geo] problem with predict() in package raster and factor variables Dear list, I am trying to use the function predict() (in package raster), where I supply: the new data as a RasterBrick, the model (as fit in previous steps and using a different dataset), and a few more arguments including the levels of my only one categorical value. Here is the code I'm using: r1 <- predict(subbrick, CIF.pa, type="response", OOB=T, factors=f) But I keep getting the following error: Error in checkData(oldData, RET) : Classes of new data do not match original data Here are more details: > CIF.pa Random Forest using Conditional Inference Trees Number of trees: 1000 Response: PA Inputs: bathy20_1, TerClass, Smax_ann, Smean_ann, Smin_ann, SPDmax_ann, SPDmean_ann, Tmax_ann, Tmean_ann, Tmin_ann Number of observations: 986 Where 'TerClass' is a categorical variable. Here is the data used to train CIF.pa: > str(v) 'data.frame': 1257 obs. of 15 variables: $ RefNo : int 16 16 16 16 17 17 17 17 18 18 ... $ PointID : int 1 2 3 4 5 6 7 8 9 10 ... $ Count : int 0 0 0 0 0 0 0 0 0 0 ... $ PA : int 0 0 0 0 0 0 0 0 0 0 ... $ split : chr "T" "T" "T" "T" ... $ bathy20_1 : num 256 260 252 266 281 ... $ TerClass : num 2 2 1 1 1 2 1 1 3 3 ... $ Smax_ann : num 35.1 35.1 35.1 35.1 35.1 ... $ Smean_ann : num 35.1 35.1 35.1 35.1 35.1 ... $ Smin_ann : num 34.9 34.9 34.9 34.9 35 ... $ SPDmax_ann : num 0.379 0.376 0.378 0.372 0.352 ... $ SPDmean_ann: num 0.14 0.137 0.14 0.132 0.12 ... $ Tmax_ann : num 6.97 6.92 7.04 6.87 6.68 ... $ Tmean_ann : num 5.76 5.73 5.79 5.71 5.54 ... $ Tmin_ann : num 4.41 4.32 4.52 4.25 4.07 ... But actually, I used a subset of v to train the model, that where v$split=='T' Below are the values and class for TerClass for that subset > unique(v[v$split=='T',7]) [1] 2 1 3 4 6 5 > class(v$TerClass) [1] "numeric" And below are the values and class for the corresponding layer of the RasterBrick: > unique(values(subbrick$TerClass)) [1] 3 1 2 4 5 6 > class(values(subbrick$TerClass)) [1] "numeric" And finally, here is what f looks like: > f $TerClass [1] 2 1 3 4 6 5 > class(f) [1] "list" As far as I can see the classes in OldData and NewData should be the same, but the error persists. Any ideas on what I could be missing? Unfortunately I am unable to reproduce the problem (I only encounter it when using my data), but any help will be hugely appreciated Also, I am aware that I asked this question before (Apr 04, 2013; 1:22pm). Unfortunately I haven't gotten very far since then! Many thanks in advance for any pointers. Genoveva _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo From genoveva.gonzalez-mirelis at imr.no Sun May 1 11:01:51 2016 From: genoveva.gonzalez-mirelis at imr.no (Gonzalez-Mirelis Genoveva) Date: Sun, 1 May 2016 09:01:51 +0000 Subject: [R-sig-Geo] problem with predict() in package raster and factor variables In-Reply-To: References: <1462012372564.1868@imr.no>, Message-ID: <1462093310773.98970@imr.no> Dear Frede and list, My sincere apologies for not providing sufficient information or reproducible example. As a matter of fact, you are right and when I looked further into the data I used to estimate the random forest model I solved the problem myself! In case it's of interest, the problem was that the variable had to be converted to a factor *before* fitting the model, so that the result of str(v) should not be what I showed in my original mail, but instead it should be: 'data.frame': 1257 obs. of 15 variables: $ RefNo : int 16 16 16 16 17 17 17 17 18 18 ... $ PointID : int 1 2 3 4 5 6 7 8 9 10 ... $ Count : int 0 0 0 0 0 0 0 0 0 0 ... $ PA : int 0 0 0 0 0 0 0 0 0 0 ... $ split : chr "T" "T" "T" "T" ... $ bathy20_1 : num 256 260 252 266 281 ... $ TerClass : Factor w/ 6 levels "1","2","3","4",..: 2 2 1 1 1 2 1 1 3 3 ... etc Note that before, $TerClass was num, and now it's Factor w/ 6 levels And f should look like this: $TerClass [1] "1" "2" "3" "4" "5" "6" Then the predict() function works without any problems! Furthermore, there is an example in the help file that exactly represents my case, namely this bit: # create a RasterStack or RasterBrick with with a set of predictor layers logo <- brick(system.file("external/rlogo.grd", package="raster")) # known presence and absence points p <- matrix(c(48, 48, 48, 53, 50, 46, 54, 70, 84, 85, 74, 84, 95, 85, 66, 42, 26, 4, 19, 17, 7, 14, 26, 29, 39, 45, 51, 56, 46, 38, 31, 22, 34, 60, 70, 73, 63, 46, 43, 28), ncol=2) a <- matrix(c(22, 33, 64, 85, 92, 94, 59, 27, 30, 64, 60, 33, 31, 9, 99, 67, 15, 5, 4, 30, 8, 37, 42, 27, 19, 69, 60, 73, 3, 5, 21, 37, 52, 70, 74, 9, 13, 4, 17, 47), ncol=2) # extract values for points xy <- rbind(cbind(1, p), cbind(0, a)) v1 <- data.frame(cbind(pa=xy[,1], extract(logo, xy[,2:3]))) # cforest (other Random Forest implementation) example with factors argument v1$red <- as.factor(round(v1$red/100)) logo$red <- round(logo[[1]]/100) library(party) m <- cforest(pa~., control=cforest_unbiased(mtry=3), data=v1) f1 <- list(levels(v1$red)) names(f1) <- 'red' pc <- predict(logo, m, OOB=TRUE, factors=f1) Thank you all very much, and my apologies for wasting anyone's time. Genoveva ________________________________________ From: Frede Aakmann T?gersen Sent: Sunday, May 1, 2016 6:42 AM To: Gonzalez-Mirelis Genoveva; r-sig-geo at r-project.org Subject: RE: [R-sig-Geo] problem with predict() in package raster and factor variables Hi Genoveva You haven't got a response to your question mainly due to a) missing information and b) missing reproducible example. If you had provided the missing information I guess you would have solved the problem yourself. I have never used raster::predict() but having a look at man for that function and you error message there is probably some differences between the data used to estimate the random forest model (you call that a subset of the object 'v') and the data in 'subbrick'. You should provide the structure of data used to fit the random forest model and 'subbrick': > str(v) > str(subbrick) Please also show all the relevant R code to obtain what you want in case the error message is not related to difference in the creation of the subset of 'v' and 'subbrick' Yours sincerely / Med venlig hilsen Frede Aakmann T?gersen Specialist, M.Sc., Ph.D. Plant Performance & Modeling Technology & Service Solutions T +45 9730 5135 M +45 2547 6050 frtog at vestas.com http://www.vestas.com Company reg. name: Vestas Wind Systems A/S This e-mail is subject to our e-mail disclaimer statement. Please refer to www.vestas.com/legal/notice If you have received this e-mail in error please contact the sender. -----Original Message----- From: R-sig-Geo [mailto:r-sig-geo-bounces at r-project.org] On Behalf Of Gonzalez-Mirelis Genoveva Sent: 30. april 2016 12:33 To: r-sig-geo at r-project.org Subject: [R-sig-Geo] problem with predict() in package raster and factor variables Dear list, I am trying to use the function predict() (in package raster), where I supply: the new data as a RasterBrick, the model (as fit in previous steps and using a different dataset), and a few more arguments including the levels of my only one categorical value. Here is the code I'm using: r1 <- predict(subbrick, CIF.pa, type="response", OOB=T, factors=f) But I keep getting the following error: Error in checkData(oldData, RET) : Classes of new data do not match original data Here are more details: > CIF.pa Random Forest using Conditional Inference Trees Number of trees: 1000 Response: PA Inputs: bathy20_1, TerClass, Smax_ann, Smean_ann, Smin_ann, SPDmax_ann, SPDmean_ann, Tmax_ann, Tmean_ann, Tmin_ann Number of observations: 986 Where 'TerClass' is a categorical variable. Here is the data used to train CIF.pa: > str(v) 'data.frame': 1257 obs. of 15 variables: $ RefNo : int 16 16 16 16 17 17 17 17 18 18 ... $ PointID : int 1 2 3 4 5 6 7 8 9 10 ... $ Count : int 0 0 0 0 0 0 0 0 0 0 ... $ PA : int 0 0 0 0 0 0 0 0 0 0 ... $ split : chr "T" "T" "T" "T" ... $ bathy20_1 : num 256 260 252 266 281 ... $ TerClass : num 2 2 1 1 1 2 1 1 3 3 ... $ Smax_ann : num 35.1 35.1 35.1 35.1 35.1 ... $ Smean_ann : num 35.1 35.1 35.1 35.1 35.1 ... $ Smin_ann : num 34.9 34.9 34.9 34.9 35 ... $ SPDmax_ann : num 0.379 0.376 0.378 0.372 0.352 ... $ SPDmean_ann: num 0.14 0.137 0.14 0.132 0.12 ... $ Tmax_ann : num 6.97 6.92 7.04 6.87 6.68 ... $ Tmean_ann : num 5.76 5.73 5.79 5.71 5.54 ... $ Tmin_ann : num 4.41 4.32 4.52 4.25 4.07 ... But actually, I used a subset of v to train the model, that where v$split=='T' Below are the values and class for TerClass for that subset > unique(v[v$split=='T',7]) [1] 2 1 3 4 6 5 > class(v$TerClass) [1] "numeric" And below are the values and class for the corresponding layer of the RasterBrick: > unique(values(subbrick$TerClass)) [1] 3 1 2 4 5 6 > class(values(subbrick$TerClass)) [1] "numeric" And finally, here is what f looks like: > f $TerClass [1] 2 1 3 4 6 5 > class(f) [1] "list" As far as I can see the classes in OldData and NewData should be the same, but the error persists. Any ideas on what I could be missing? Unfortunately I am unable to reproduce the problem (I only encounter it when using my data), but any help will be hugely appreciated Also, I am aware that I asked this question before (Apr 04, 2013; 1:22pm). Unfortunately I haven't gotten very far since then! Many thanks in advance for any pointers. Genoveva _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo From milujisb at gmail.com Sun May 1 17:30:35 2016 From: milujisb at gmail.com (Miluji Sb) Date: Sun, 1 May 2016 17:30:35 +0200 Subject: [R-sig-Geo] Aggregate FIPS data to State and Census divisions Message-ID: Dear all, I have the following data by US FIPS code. Is there a package to aggregate the data by State and Census divisions? temp <- dput(head(pop1,5)) structure(list(FIPS = c("01001", "01003", "01005", "01007", "01009" ), death_2050A1 = c(18.19158, 101.63088, 13.18896, 10.30068, 131.91798), death_2050A2 = c(22.16349, 116.58387, 15.85324, 12.78564, 155.20506), death_2050B1 = c(21.38906, 76.23018, 21.38218, 17.14269, 151.64466), death_2050B2 = c(23.43543, 81.39378, 22.96802, 18.76926, 161.86404), death_2050BC = c(21.89947, 93.88002, 18.60352, 15.1032, 152.43414)), .Names = c("FIPS", "death_2050A1", "death_2050A2", "death_2050B1", "death_2050B2", "death_2050BC"), row.names = c(NA, 5L), class = "data.frame") Thank you! Sincerely, Milu [[alternative HTML version deleted]] From roman.lustrik at gmail.com Sun May 1 17:49:33 2016 From: roman.lustrik at gmail.com (=?UTF-8?Q?Roman_Lu=C5=A1trik?=) Date: Sun, 1 May 2016 17:49:33 +0200 Subject: [R-sig-Geo] Aggregate FIPS data to State and Census divisions In-Reply-To: References: Message-ID: Is `aggregate` doing anything for you? You can specify, with a formula interface, which column in a data.frame is the variable to summarise and which are used as factors by which to "cut" the data. Cheers, Roman On Sun, May 1, 2016 at 5:30 PM, Miluji Sb wrote: > Dear all, > > I have the following data by US FIPS code. Is there a package to aggregate > the data by State and Census divisions? > > temp <- dput(head(pop1,5)) > structure(list(FIPS = c("01001", "01003", "01005", "01007", "01009" > ), death_2050A1 = c(18.19158, 101.63088, 13.18896, 10.30068, > 131.91798), death_2050A2 = c(22.16349, 116.58387, 15.85324, 12.78564, > 155.20506), death_2050B1 = c(21.38906, 76.23018, 21.38218, 17.14269, > 151.64466), death_2050B2 = c(23.43543, 81.39378, 22.96802, 18.76926, > 161.86404), death_2050BC = c(21.89947, 93.88002, 18.60352, 15.1032, > 152.43414)), .Names = c("FIPS", "death_2050A1", "death_2050A2", > "death_2050B1", "death_2050B2", "death_2050BC"), row.names = c(NA, > 5L), class = "data.frame") > > Thank you! > > Sincerely, > > Milu > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- In God we trust, all others bring data. [[alternative HTML version deleted]] From milujisb at gmail.com Sun May 1 18:30:51 2016 From: milujisb at gmail.com (Miluji Sb) Date: Sun, 1 May 2016 18:30:51 +0200 Subject: [R-sig-Geo] Aggregate FIPS data to State and Census divisions In-Reply-To: References: Message-ID: Dear Roman, Thank you for your reply. I can use the aggregate function but its the matching FIPS codes to their states that I am having trouble. Thanks again. Sincerely, Milu On Sun, May 1, 2016 at 5:49 PM, Roman Lu?trik wrote: > Is `aggregate` doing anything for you? You can specify, with a formula > interface, which column in a data.frame is the variable to summarise and > which are used as factors by which to "cut" the data. > > Cheers, > Roman > > On Sun, May 1, 2016 at 5:30 PM, Miluji Sb wrote: > >> Dear all, >> >> I have the following data by US FIPS code. Is there a package to aggregate >> the data by State and Census divisions? >> >> temp <- dput(head(pop1,5)) >> structure(list(FIPS = c("01001", "01003", "01005", "01007", "01009" >> ), death_2050A1 = c(18.19158, 101.63088, 13.18896, 10.30068, >> 131.91798), death_2050A2 = c(22.16349, 116.58387, 15.85324, 12.78564, >> 155.20506), death_2050B1 = c(21.38906, 76.23018, 21.38218, 17.14269, >> 151.64466), death_2050B2 = c(23.43543, 81.39378, 22.96802, 18.76926, >> 161.86404), death_2050BC = c(21.89947, 93.88002, 18.60352, 15.1032, >> 152.43414)), .Names = c("FIPS", "death_2050A1", "death_2050A2", >> "death_2050B1", "death_2050B2", "death_2050BC"), row.names = c(NA, >> 5L), class = "data.frame") >> >> Thank you! >> >> Sincerely, >> >> Milu >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > > > > -- > In God we trust, all others bring data. > [[alternative HTML version deleted]] From kaushikjana11 at gmail.com Mon May 2 10:03:03 2016 From: kaushikjana11 at gmail.com (Kaushik Jana) Date: Mon, 2 May 2016 13:33:03 +0530 Subject: [R-sig-Geo] How the "gSymdifference" of rgoes package calculating the symmetric distance between two polygon Message-ID: 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]] From Andy.Bunn at wwu.edu Mon May 2 21:52:46 2016 From: Andy.Bunn at wwu.edu (Andy Bunn) Date: Mon, 2 May 2016 19:52:46 +0000 Subject: [R-sig-Geo] Teaching example of autocorrelated errors affecting interpretation of OLS Message-ID: HI all, thanks to all those to pointed me towards good environmental data sets for teaching spatial stats in R. We are plugging along on point patterns this week. This next query might be a bit of stretch but here goes. This class I'm teaching is made up of master's students who are from a variety of environmental fields (oceanography to toxicology to plant ecology). It's a fun group. A few of them get the gospel of thinking about space in terms of how pattern drives process and some learn to appreciate a spatial perspective because it is just a worthwhile thing in and of itself. However, a lot of the students just want to make sure that spatial autocorrelation isn't breaking their regressions. Many of them are doing some kind of regression analysis in their thesis work and are worried about spatial autocorrelation violating the regression assumptions (via non iid errors). I have them read (in order): 1. Hawkins et al. 2007 (DOI: 10.1111/j.0906-7590.2007.05117.x) 2. Hawkins 2012 (DOI: 10.1111/j.1365-2699.2011.02637.x) 3. Kuhn & Dormann 2012 (DOI: 10.1111/j.1365-2699.2012.02716.x) This both ameliorates some of their worries and worries them more. I also show them via simulation where autocorrelation can lead to trouble. E.g., I have an example where I simulate a SAR process with varying levels of autocorrelation and show them how an OLS model of y~x with spatially autocorrelated residuals gives an inefficient estimate of beta. (You do need very high levels of autocorrelation to do this I note.) What would be better would be to show them a worked example where autocorrelation has led to incorrect interpretation of some ecological process. Do any of you know of a case study like this? Something along the lines of "Smith et al thought Y was modeled well by X but when you consider the spatial structure of the residuals it turns out that their model was interpreted incorrectly." By the end of the course I want to push more of them over to appreciating spatial analysis for its own sake but do want them to consider the effects of non iid errors on the estimated covariance matrix of the estimates parameters in OLS. (Even if in general OLS is robust - a la Hawkins.) Sorry for the long email and many thanks, Andy [[alternative HTML version deleted]] From tmeeha at gmail.com Mon May 2 22:01:26 2016 From: tmeeha at gmail.com (Tim Meehan) Date: Mon, 2 May 2016 14:01:26 -0600 Subject: [R-sig-Geo] Teaching example of autocorrelated errors affecting interpretation of OLS In-Reply-To: References: Message-ID: Hi Andy, You can use the following for an example: http://iopscience.iop.org/article/10.1088/1748-9326/10/11/114001/meta Best, Tim On Mon, May 2, 2016 at 1:52 PM, Andy Bunn wrote: > HI all, thanks to all those to pointed me towards good environmental data > sets for teaching spatial stats in R. We are plugging along on point > patterns this week. > > This next query might be a bit of stretch but here goes. > > This class I'm teaching is made up of master's students who are from a > variety of environmental fields (oceanography to toxicology to plant > ecology). It's a fun group. A few of them get the gospel of thinking about > space in terms of how pattern drives process and some learn to appreciate a > spatial perspective because it is just a worthwhile thing in and of itself. > > However, a lot of the students just want to make sure that spatial > autocorrelation isn't breaking their regressions. Many of them are doing > some kind of regression analysis in their thesis work and are worried about > spatial autocorrelation violating the regression assumptions (via non iid > errors). I have them read (in order): > > 1. Hawkins et al. 2007 (DOI: 10.1111/j.0906-7590.2007.05117.x) > 2. Hawkins 2012 (DOI: 10.1111/j.1365-2699.2011.02637.x) > 3. Kuhn & Dormann 2012 (DOI: 10.1111/j.1365-2699.2012.02716.x) > > This both ameliorates some of their worries and worries them more. I also > show them via simulation where autocorrelation can lead to trouble. E.g., > I have an example where I simulate a SAR process with varying levels of > autocorrelation and show them how an OLS model of y~x with spatially > autocorrelated residuals gives an inefficient estimate of beta. (You do > need very high levels of autocorrelation to do this I note.) > > What would be better would be to show them a worked example where > autocorrelation has led to incorrect interpretation of some ecological > process. Do any of you know of a case study like this? Something along the > lines of "Smith et al thought Y was modeled well by X but when you > consider the spatial structure of the residuals it turns out that their > model was interpreted incorrectly." > > By the end of the course I want to push more of them over to appreciating > spatial analysis for its own sake but do want them to consider the effects > of non iid errors on the estimated covariance matrix of the estimates > parameters in OLS. (Even if in general OLS is robust - a la Hawkins.) > > Sorry for the long email and many thanks, Andy > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From hakim.abdi at nateko.lu.se Mon May 2 23:11:39 2016 From: hakim.abdi at nateko.lu.se (Hakim Abdi) Date: Mon, 2 May 2016 23:11:39 +0200 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported Message-ID: 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ DOWNLOAD: _______________ MODISserverOrder : LPDAAC, LAADS dlmethod : auto stubbornness : 5 PROCESSING: _______________ GDAL : GDAL 2.0.2, released 2016/01/26 MRT : Version 4.1 (March 2011) pixelSize : asIn outProj : GEOGRAPHIC resamplingType : NN dataFormat : GTiff DEPENDENCIES: _______________ > 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* > sessionInfo() R version 3.2.5 (2016-04-14) 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 loaded via a namespace (and not attached): [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 __________________________________________________ Hakim Abdi | PhD Candidate Center for Geobiosphere Science Department of Physical Geography and Ecosystem Science Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden [[alternative HTML version deleted]] From juta.kawalerowicz at nuffield.ox.ac.uk Tue May 3 10:30:43 2016 From: juta.kawalerowicz at nuffield.ox.ac.uk (Juta Kawalerowicz) Date: Tue, 3 May 2016 10:30:43 +0200 Subject: [R-sig-Geo] spatialpoints: each dot represents 100 individuals? In-Reply-To: <9b43c157-98b9-4ad9-8215-31ef934a2097@HUB05.ad.oak.ox.ac.uk> References: <9b43c157-98b9-4ad9-8215-31ef934a2097@HUB05.ad.oak.ox.ac.uk> Message-ID: Thanks for all suggestions! I was thinking that in the end a plasible approach would be to sample points, say if I have 100,000 and sample 1,000 then I can say that each point represents 100 people. Juta On Wed, Apr 27, 2016 at 11:13 PM, rubenfcasal wrote: > Alternatively, you might also consider data binning (implemented in > several packages: KernSmooth, ks, sm, npsp ,...). This technique is > commonly used in nonparametric statistics to reduce the computational > time (see e.g. Wand, M. P. (1994), Fast Computation of Multivariate > Kernel Estimators, Journal of Computational and Graphical Statistics, 3, > 433-445). > > For instance, using the npsp package (maintained by me...), you could do > something like this: > > library(npsp) > > bin <- binning(earthquakes[, c("lon", "lat")], nbin = c(50,50)) > > # ?bin$binw? will contain the binning weights (aggregations) at > locations ?coords(bin)? > > simage(bin) > > Additionally, you could estimate (nonparametrically) the spatial density: > > h <- h.cv(bin, ncv = 2)$h > > den <- np.den(bin, h = h) > > plot(den, log = FALSE, main = 'Estimated density') > > Best regards, > > Ruben. > > > El 25/04/2016 a las 13:35, Juta Kawalerowicz escribi?: > > Hi, > > > > I have a dataset with couple of million of points (individuals) and > > would like to do some mapping (I have the coordinates of each point) > > but given the number of observation I think it may be usuful to plot > > dots which represent 100 individuals (of a given group). Does anyone > > know a good way to aggregate up spatialpoints? Any suggestions would > > be much appreciated! > > > > Best wishes, > > Juta > > > > _______________________________________________ > > R-sig-Geo mailing list > > R-sig-Geo at r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > > > > [[alternative HTML version deleted]] > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From thi_veloso at yahoo.com.br Wed May 4 01:11:29 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Tue, 3 May 2016 23:11:29 +0000 (UTC) Subject: [R-sig-Geo] Mask a map using statistical significance References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> Dear all, In climate studies, it is a common practice to perform some statistical test between two fields (maps), and then plot the resulting map using a significance mask. This masking is usually done by adding some kind of pattern (shading, crosshatching etc) on top of the actual color palette. Examples can be seen here in this image https://www3.epa.gov/climatechange/images/science/GlobalPrecipMap-large.png and in the left images of this panel: http://www.nature.com/nclimate/journal/vaop/ncurrent/images_article/nclimate2996-f3.jpg In my case, I ran a statistical test for detecting trend on a time-series raster and I now have one raster with the trend for rainfall (in degree C per year) and one with the p-values associated to the test. My data looks roughly like this: require(raster) ## scratch raster objects and fill them with some random values r.trend <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) r.trend[] <- round(runif(50 * 50, min=0, max=3), digits=2) r.pvalue <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) r.pvalue[] <- round(runif(50 * 50, min=0.0001, max=0.1), digits=5) What I would like to do is to plot r.trend, and on top of it plot r.pvalue (as a pattern) where r.pvalues < 0.01 (corresponding to a significance level of 99%). Has anyone here ever tried to do a similar plot and can point me to any direction? I usually use rasterVis and ggplot2 to plot maps, but I would be open to try some other package and even other SIG software other than R. Many thanks in advance, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota From Frederic.Pons at cerema.fr Wed May 4 13:18:41 2016 From: Frederic.Pons at cerema.fr (PONS Frederic - CEREMA/DTerMed/DREC/SRILH) Date: Wed, 04 May 2016 13:18:41 +0200 Subject: [R-sig-Geo] RGRASS7 and Initgrass In-Reply-To: <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5729DA91.6000509@cerema.fr> Dear all I am working on windows 7. I have update my version of GRASS GIS 7.0.4 and R-3.2.5. I try to work with my old tools and I meet a problem with function InitGrass. i just want to share this problem and if possible understand if the problem depend on my installation of grass and r or release of InitGrass. Before I can use: loc=initGRASS(gisBase = Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) I have this problem: Error in if (class(t0) != "try-error" && is.character(t0) && nchar(t0) > : missing value where TRUE/FALSE needed I thonk it is in this osurce code: https://github.com/cran/rgrass7/blob/master/R/xml1.R I solve the problem uisng a false folder loc=initGRASS(gisBase = Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,addon_base=Chemin_de_l_exe_de_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) Best regards File: C:\Program Files\R\R-3.2.5\Cerema #Chemin de l'exe de Grass C:\GRASS GIS 7.0.4 #Monde Grass temporaire (1=oui, 0=non) 0 #Chemin des donnees Grass C:\GRASSDATA #Localisation Cerema #Jeu de donnees test #Projection (EPSG) 2154 #Chemin des routines R C:/PROGRA~1/R/R-32~1.5/cerema Code: # DICARTO_00_LectureMondeGrass # Version 2.0 06/10/2015 # Cerema # Frederic Pons, Celine Trmal DICARTO_00_LectureMondeGrass = function(chem_routine,Numero_de_calcul) { # Lecture de l'initialisation et cr??ation du monde Grass fichier_init=paste(chem_routine,"\\Init_Routine_Cerema",as.character(Numero_de_calcul),".txt",sep="") fid=file(fichier_init, open = "r") lignes <- readLines(fid) close(fid) Chemin_de_l_exe_de_Grass=as.character(lignes[2]) Chemin_des_donnees_Grass=as.character(lignes[6]) Localisation=as.character(lignes[8]) Jeu_de_donnees=as.character(lignes[10]) Projection=as.numeric(lignes[12]) Monde_grass_temp=as.numeric(lignes[4]) if (Monde_grass_temp==0) { loc=initGRASS(gisBase = Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,addon_base=Chemin_de_l_exe_de_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) ## convert default coordinate system x,y to epsg code 3347 (can be altered later) #execGRASS("g.mapset",flags=c("c"),parameters=list(mapset="PERMANENT")) #execGRASS("g.proj",flags=c("c"),epsg=as.integer(Projection)) #execGRASS("g.mapset",flags=c("c"),parameters=list(mapset=Jeu_de_donnees)) } else { loc=initGRASS(Chemin_de_l_exe_de_Grass, home=tempdir(),addon_base=Chemin_de_l_exe_de_Grass,override=T) } return(cbind(Chemin_de_l_exe_de_Grass,loc$GISDBASE,loc$LOCATION,loc$MAPSET,Projection)) } *Fr?d?ric Pons * *Expert hydraulique sur les inondations et al?as c?tiers **DREC/Service Risques Inondations Littoraux et Hydraulique **- T?l.: (33)4 42 24 76 68 * *Direction Territoriale M?diterran?e * Centre d??tudes et d?expertise sur les risques, l?environnement, la mobilit? et l?am?nagement www.cerema.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cerema.png Type: image/png Size: 6094 bytes Desc: not available URL: From jelewis02 at gmail.com Wed May 4 16:20:45 2016 From: jelewis02 at gmail.com (John Lewis) Date: Wed, 4 May 2016 10:20:45 -0400 Subject: [R-sig-Geo] Fwd: R-sig-Geo Digest, Vol 153, Issue 4 In-Reply-To: References: Message-ID: Hi, I think there is a more fundamental problem that you should consider. The use of p values and set significant levels are seriously being questioned as good statistical modelling practises. You might want to look at the recent policy statement by the American Statistical Association on this topic. There is even a strong movement to convince editors not to review papers which base the results on the above methods or at least advise the use of different procedures. If you are interested in reading this policy statement I would be happy to send a pdf copy. Cheers, John Lewis ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 May 2016 23:11:29 +0000 (UTC) From: "Thiago V. dos Santos" To: R-sig-geo Mailing List Subject: [R-sig-Geo] Mask a map using statistical significance Message-ID: <1350390896.5790739.1462317089174.JavaMail.yahoo at mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Dear all, In climate studies, it is a common practice to perform some statistical test between two fields (maps), and then plot the resulting map using a significance mask. This masking is usually done by adding some kind of pattern (shading, crosshatching etc) on top of the actual color palette. Examples can be seen here in this image https://www3.epa.gov/climatechange /images/science/GlobalPrecipMap-large.png and in the left images of this panel: http://www.nature.com/nclimate/journal/vaop/ncurrent /images_article/nclimate2996-f3.jpg In my case, I ran a statistical test for detecting trend on a time-series raster and I now have one raster with the trend for rainfall (in degree C per year) and one with the p-values associated to the test. My data looks roughly like this: require(raster) ## scratch raster objects and fill them with some random values r.trend <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) r.trend[] <- round(runif(50 * 50, min=0, max=3), digits=2) r.pvalue <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) r.pvalue[] <- round(runif(50 * 50, min=0.0001, max=0.1), digits=5) What I would like to do is to plot r.trend, and on top of it plot r.pvalue (as a pattern) where r.pvalues < 0.01 (corresponding to a significance level of 99%). Has anyone here ever tried to do a similar plot and can point me to any direction? I usually use rasterVis and ggplot2 to plot maps, but I would be open to try some other package and even other SIG software other than R. Many thanks in advance, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota ------------------------------ Subject: Digest Footer _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo ------------------------------ End of R-sig-Geo Digest, Vol 153, Issue 4 ***************************************** [[alternative HTML version deleted]] From b.rowlingson at lancaster.ac.uk Wed May 4 18:02:17 2016 From: b.rowlingson at lancaster.ac.uk (Barry Rowlingson) Date: Wed, 4 May 2016 17:02:17 +0100 Subject: [R-sig-Geo] Mask a map using statistical significance In-Reply-To: <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> Message-ID: Your example looks a bit rubbish because you have mostly isolated pixels. Let's make an example with an area so we can see the shading. > r.pvalue = raster(outer(-24:25,-24:25, function(a,b){a^2+b^2})/120000) > range(r.pvalue[]) [1] 0.00000000 0.01041667 now convert your raster to polygons at the threshold you are interested in. Let's imagine the area less than 0.001 (the central circle here): p_poly = rasterToPolygons(r.pvalue<0.001, dissolve=TRUE) and overlay hatched polygons: plot(r.pvalue) # or whatever your underlying data is plot(p_poly[p_poly$layer==1,],density=5,add=TRUE, border=NA) see help(polygon) for parameters to control the shading angle and density. The "border=NA" above hides the outline which looks like those maps you linked to. Barry On Wed, May 4, 2016 at 12:11 AM, Thiago V. dos Santos via R-sig-Geo wrote: > Dear all, > > In climate studies, it is a common practice to perform some statistical test between two fields (maps), and then plot the resulting map using a significance mask. This masking is usually done by adding some kind of pattern (shading, crosshatching etc) on top of the actual color palette. > > Examples can be seen here in this image https://www3.epa.gov/climatechange/images/science/GlobalPrecipMap-large.png and in the left images of this panel: > http://www.nature.com/nclimate/journal/vaop/ncurrent/images_article/nclimate2996-f3.jpg > In my case, I ran a statistical test for detecting trend on a time-series raster and I now have one raster with the trend for rainfall (in degree C per year) and one with the p-values associated to the test. > > My data looks roughly like this: > > require(raster) > > ## scratch raster objects and fill them with some random values > r.trend <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.trend[] <- round(runif(50 * 50, min=0, max=3), digits=2) > > r.pvalue <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.pvalue[] <- round(runif(50 * 50, min=0.0001, max=0.1), digits=5) > > > What I would like to do is to plot r.trend, and on top of it plot r.pvalue (as a pattern) where r.pvalues < 0.01 (corresponding to a significance level of 99%). > > Has anyone here ever tried to do a similar plot and can point me to any direction? > > I usually use rasterVis and ggplot2 to plot maps, but I would be open to try some other package and even other SIG software other than R. > > Many thanks in advance, -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo From Roger.Bivand at nhh.no Wed May 4 20:27:50 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Wed, 4 May 2016 20:27:50 +0200 Subject: [R-sig-Geo] RGRASS7 and Initgrass In-Reply-To: <5729DA91.6000509@cerema.fr> References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> <5729DA91.6000509@cerema.fr> Message-ID: On Wed, 4 May 2016, PONS Frederic - CEREMA/DTerMed/DREC/SRILH wrote: > Dear all > > I am working on windows 7. > > I have update my version of GRASS GIS 7.0.4 and R-3.2.5. > > I try to work with my old tools and I meet a problem with function > InitGrass. i just want to share this problem and if possible understand > if the problem depend on my installation of grass and r or release of > InitGrass. You have not said which version of rgrass7 you are using. I'm afraid this is very unclear. You are almost certainly using a very suboptimal approach. Have you thought of starting GRASS properly once, and doing whatever your function does in new mapsets? Or are the locations different? Please move this to the grass-stats list. After an error, do run traceback(). And establish first that initGRASS() works run in the R session itself rather than in a function (I doubt that this is easy to debug). Roger PS: Please note that the link to github is *not* the source, it is an unauthorised copy, and as maintainer I refuse to consider any references to it. The released source is on CRAN, and the development trunk may be browsed on R-Forge. Just "thinking" is no use, if you run under debug(), give the line number of specific issues. > > Before I can use: > loc=initGRASS(gisBase = > Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) > I have this problem: > Error in if (class(t0) != "try-error" && is.character(t0) && nchar(t0) > > : missing value where TRUE/FALSE needed > > I thonk it is in this osurce code: > https://github.com/cran/rgrass7/blob/master/R/xml1.R > > I solve the problem uisng a false folder > loc=initGRASS(gisBase = > Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,addon_base=Chemin_de_l_exe_de_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) > > Best regards > > File: C:\Program Files\R\R-3.2.5\Cerema > #Chemin de l'exe de Grass > C:\GRASS GIS 7.0.4 > #Monde Grass temporaire (1=oui, 0=non) > 0 > #Chemin des donnees Grass > C:\GRASSDATA > #Localisation > Cerema > #Jeu de donnees > test > #Projection (EPSG) > 2154 > #Chemin des routines R > C:/PROGRA~1/R/R-32~1.5/cerema > > > Code: > # DICARTO_00_LectureMondeGrass > # Version 2.0 06/10/2015 > # Cerema > # Frederic Pons, Celine Trmal > > DICARTO_00_LectureMondeGrass = function(chem_routine,Numero_de_calcul) > { > # Lecture de l'initialisation et cr??ation du monde Grass > fichier_init=paste(chem_routine,"\\Init_Routine_Cerema",as.character(Numero_de_calcul),".txt",sep="") > fid=file(fichier_init, open = "r") > lignes <- readLines(fid) > close(fid) > > Chemin_de_l_exe_de_Grass=as.character(lignes[2]) > Chemin_des_donnees_Grass=as.character(lignes[6]) > Localisation=as.character(lignes[8]) > Jeu_de_donnees=as.character(lignes[10]) > Projection=as.numeric(lignes[12]) > Monde_grass_temp=as.numeric(lignes[4]) > > if (Monde_grass_temp==0) { > loc=initGRASS(gisBase = > Chemin_de_l_exe_de_Grass,home=Chemin_des_donnees_Grass,gisDbase=Chemin_des_donnees_Grass,addon_base=Chemin_de_l_exe_de_Grass,location=Localisation,mapset=Jeu_de_donnees,override=T) > ## convert default coordinate system x,y to epsg code 3347 (can be > altered later) > #execGRASS("g.mapset",flags=c("c"),parameters=list(mapset="PERMANENT")) > #execGRASS("g.proj",flags=c("c"),epsg=as.integer(Projection)) > #execGRASS("g.mapset",flags=c("c"),parameters=list(mapset=Jeu_de_donnees)) > } else { > loc=initGRASS(Chemin_de_l_exe_de_Grass, > home=tempdir(),addon_base=Chemin_de_l_exe_de_Grass,override=T) > } > > return(cbind(Chemin_de_l_exe_de_Grass,loc$GISDBASE,loc$LOCATION,loc$MAPSET,Projection)) > } > *Fr?d?ric Pons * > *Expert hydraulique sur les inondations et al?as c?tiers > **DREC/Service Risques Inondations Littoraux et Hydraulique **- T?l.: (33)4 > 42 24 76 68 * > *Direction Territoriale M?diterran?e > * > Centre d??tudes et d?expertise sur les risques, l?environnement, la mobilit? > et l?am?nagement > www.cerema.fr > > > -- 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From Roger.Bivand at nhh.no Wed May 4 20:36:18 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Wed, 4 May 2016 20:36:18 +0200 Subject: [R-sig-Geo] Fwd: R-sig-Geo Digest, Vol 153, Issue 4 In-Reply-To: References: Message-ID: On Wed, 4 May 2016, John Lewis wrote: > Hi, > I think there is a more fundamental problem that you should consider. The > use of p values and set significant levels are seriously being questioned > as good statistical modelling practises. You might want to look at the > recent policy statement by the American Statistical Association on this > topic. There is even a strong movement to convince editors not to review > papers which base the results on the above methods or at least advise the > use of different procedures. > If you are interested in reading this policy statement I would be happy to > send a pdf copy. I believe that this link (to a manuscript covering the background and including the statement) is open: http://amstat.tandfonline.com/doi/pdf/10.1080/00031305.2016.1154108 Roger > Cheers, > John Lewis > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 3 May 2016 23:11:29 +0000 (UTC) > From: "Thiago V. dos Santos" > To: R-sig-geo Mailing List > Subject: [R-sig-Geo] Mask a map using statistical significance > Message-ID: > <1350390896.5790739.1462317089174.JavaMail.yahoo at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > Dear all, > > In climate studies, it is a common practice to perform some statistical > test between two fields (maps), and then plot the resulting map using a > significance mask. This masking is usually done by adding some kind of > pattern (shading, crosshatching etc) on top of the actual color palette. > > Examples can be seen here in this image https://www3.epa.gov/climatechange > /images/science/GlobalPrecipMap-large.png and in the left images of this > panel: > http://www.nature.com/nclimate/journal/vaop/ncurrent > /images_article/nclimate2996-f3.jpg > In my case, I ran a statistical test for detecting trend on a time-series > raster and I now have one raster with the trend for rainfall (in degree C > per year) and one with the p-values associated to the test. > > My data looks roughly like this: > > require(raster) > > ## scratch raster objects and fill them with some random values > r.trend <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.trend[] <- round(runif(50 * 50, min=0, max=3), digits=2) > > r.pvalue <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.pvalue[] <- round(runif(50 * 50, min=0.0001, max=0.1), digits=5) > > > What I would like to do is to plot r.trend, and on top of it plot r.pvalue > (as a pattern) where r.pvalues < 0.01 (corresponding to a significance > level of 99%). > > Has anyone here ever tried to do a similar plot and can point me to any > direction? > > I usually use rasterVis and ggplot2 to plot maps, but I would be open to > try some other package and even other SIG software other than R. > > Many thanks in advance, -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > ------------------------------ > > End of R-sig-Geo Digest, Vol 153, Issue 4 > ***************************************** > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From thi_veloso at yahoo.com.br Thu May 5 00:06:12 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Wed, 4 May 2016 22:06:12 +0000 (UTC) Subject: [R-sig-Geo] Mask a map using statistical significance In-Reply-To: References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> Message-ID: <316111629.6363386.1462399572213.JavaMail.yahoo@mail.yahoo.com> Thanks Barry and Arnaud (off-list) for the valuable hints. I ended up managing to use rasterVis' levelplot to produce the map I was looking for. The key step was to convert the raster I wanted to use as a mask to SpatialPoints, and then pass it as an additional layer to levelplot. The final map, produced using my actual data, can be visualized here:?https://dl.dropboxusercontent.com/u/27700634/rainfall_trend.png.?Stippling indicates regions exceeding the 95% statistical significance. ? | ? | | ? | | ? | ? | ? | ? | ? | | | | | | View on dl.dropboxuserconten... | Preview by Yahoo | | | | ? | Greetings, ?-- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota On Wednesday, May 4, 2016 11:02 AM, Barry Rowlingson wrote: Your example looks a bit rubbish because you have mostly isolated pixels. Let's make an example with an area so we can see the shading. > r.pvalue = raster(outer(-24:25,-24:25, function(a,b){a^2+b^2})/120000) > range(r.pvalue[]) [1] 0.00000000 0.01041667 now convert your raster to polygons at the threshold you are interested in. Let's imagine the area less than 0.001 (the central circle here): p_poly = rasterToPolygons(r.pvalue<0.001, dissolve=TRUE) and overlay hatched polygons: plot(r.pvalue) # or whatever your underlying data is plot(p_poly[p_poly$layer==1,],density=5,add=TRUE, border=NA) see help(polygon) for parameters to control the shading angle and density. The "border=NA" above hides the outline which looks like those maps you linked to. Barry On Wed, May 4, 2016 at 12:11 AM, Thiago V. dos Santos via R-sig-Geo wrote: > Dear all, > > In climate studies, it is a common practice to perform some statistical test between two fields (maps), and then plot the resulting map using a significance mask. This masking is usually done by adding some kind of pattern (shading, crosshatching etc) on top of the actual color palette. > > Examples can be seen here in this image https://www3.epa.gov/climatechange/images/science/GlobalPrecipMap-large.png and in the left images of this panel: > http://www.nature.com/nclimate/journal/vaop/ncurrent/images_article/nclimate2996-f3.jpg > In my case, I ran a statistical test for detecting trend on a time-series raster and I now have one raster with the trend for rainfall (in degree C per year) and one with the p-values associated to the test. > > My data looks roughly like this: > > require(raster) > > ## scratch raster objects and fill them with some random values > r.trend <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.trend[] <- round(runif(50 * 50, min=0, max=3), digits=2) > > r.pvalue <- raster(nrows=50, ncols=50, xmn=-58, xmx=-48, ymn=-33, ymx=-22) > r.pvalue[] <- round(runif(50 * 50, min=0.0001, max=0.1), digits=5) > > > What I would like to do is to plot r.trend, and on top of it plot r.pvalue (as a pattern) where r.pvalues < 0.01 (corresponding to a significance level of 99%). > > Has anyone here ever tried to do a similar plot and can point me to any direction? > > I usually use rasterVis and ggplot2 to plot maps, but I would be open to try some other package and even other SIG software other than R. > > Many thanks in advance, -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo [[alternative HTML version deleted]] From englishchristophera at gmail.com Fri May 6 14:20:40 2016 From: englishchristophera at gmail.com (chris english) Date: Fri, 6 May 2016 15:20:40 +0300 Subject: [R-sig-Geo] Bagidis semi-distance for tracking data Message-ID: 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]] From nell.redu at hotmail.fr Fri May 6 21:00:36 2016 From: nell.redu at hotmail.fr (Nelly Reduan) Date: Fri, 6 May 2016 19:00:36 +0000 Subject: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) In-Reply-To: References: , Message-ID: Thank you very much Forrest for your answer. How can I call the function "gdal_proximity" in R via system() ? Thanks a lot for your time. Nell ________________________________ De : Forrest Stevens Envoy? : mercredi 13 avril 2016 22:37:01 ? : Nelly Reduan; Michael Sumner; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) So you're correct, the buffer() and distance() functions you're using will take a long period of time. The code below illustrates the shortcut that I've used in the past when buffering only by the limit of one pixel, since it uses queens-case connectance and distance between cell-centers based on that connectance rule. This uses the gridDistance() function which is much faster than calculating straight line distances. You can see that the distance-based calculation takes under 40 seconds. But do notice that the buffer it creates by setting the threshold is around both classes and is indiscriminate of the nearest class: library(raster) clip_buff <- raster("clip_study_area_2010.tif") system.time(d <- gridDistance(clip_buff, c(2,3))) # user system elapsed # 37.36 11.00 48.41 rf[(rf != 2 & rf != 3)] <- NA ## Set buffer to 10m just for fun and assign ## value of 4 to that buffered region: rf[ d > 0 & d <= 10 ] <- 4 plot(rf) If you want to buffer by more than one pixel dimension then you'll probably want straight line distances and I'd suggest using GDAL and using the gdal_proximity utility via a system() call. Alternatively, you could look into other utilities that have better-optimized raster-based distance tools. Hopefully this gives you some ideas on how to proceed? Sincerely, Forrest On Wed, Apr 13, 2016 at 9:18 PM Nelly Reduan > wrote: I put a cropped raster with 3581676 cells in the link below: https://www.dropbox.com/sh/ewaz4yncdqt7kxj/AAAEHyuWyHzBE7gSINA1oayTa?dl=0 Here is my code to built the buffers: rf <- clip_buff rf [(rf != 2 & rf != 3)] <- NA plot(rf) system.time(corr <- buffer(rf, 10)) system.time(dist_rf <- distance(rf)) I stopped the code with the functions "buffer" and "distance" after two hours. Thanks a lot for your time. Have a nice day. Nell ________________________________ De : Michael Sumner > Envoy? : mardi 12 avril 2016 20:36 ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) I think we still haven't seen a print of the raster object? It may be a tiled file on disk? Try readAll to pull into memory, if it is tiled and read in on demand via gdal tools like extract will be very slow since access is done line by line. But just guessing, please give full details and ideally a reproducible example. Cheers, Mije On Wed, 13 Apr 2016, 02:33 Nelly Reduan > wrote: Yes, I tested the functions "distance" and "buffer" by using a cropped raster with around 5 million cells. But my original raster has 48096864 cells. Ideally, I would like to build the buffers from my original raster. Here are some characteristics of the original raster: class : RasterLayer dimensions : 4876, 9864, 48096864 (nrow, ncol, ncell) extent : 188384.5, 484304.5, 4914481, 5060761 (xmin, xmax, ymin, ymax) coord. ref. : +proj=tmerc +lat_0=0 +lon_0=-73.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Thanks a lot for your help. Have a nice day. Nell ________________________________ De : Forrest Stevens > Envoy? : lundi 11 avril 2016 18:55 ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) And this is for a raster with around 5 milliion cells? Your results surprise me a bit, especially if the bottleneck is at the call to buffer()/distance(). Your best bet is to wait for a response from Robert Hijmans or someone else working on the package, they might have some other tricks up their sleeves. In any case, I agree, 5+ hours is extremely excessive. Sincerely, Forrest On Mon, Apr 11, 2016 at 6:57 PM Nelly Reduan >> wrote: Thank you very much Forrest for your answer. I don't think I have memory problems (my computer has a 32 GB memory). Here is my code to draw the 100-m buffers with the function "buffer" (package raster): r1 <- r ## r is the original raster and has a resolution of 10m r1[(r1[]!=2 & r1[]!=5)]=NA plot(r1) r2 <- buffer(r1, 10) I also tested the function distance (package raster): r1 <- r ## r is the original raster and has a resolution of 10m r1[(r1[]!=2 & r1[]!=5)]=NA plot(r1) r3 <- distance(r1) In the two cases, I stopped the functions afer 5 hours as this was too long ! For the moment, I haven't find solutions. Thanks a lot for your time. Have a nice day. Nell ________________________________ De : Forrest Stevens >> Envoy? : lundi 11 avril 2016 09:09 ? : Nelly Reduan; r-sig-geo at r-project.org> Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) Five million cells isn't all that many, how slow is too slow? Buffering a raster of about 10 million cells on my laptop takes on the order of 20 seconds or so for a binary raster. Is it possible that you're fighting memory problems? In the past when doing multiple ring buffers I've found it faster to calculate a distance-to raster first, and then apply multiple logical comparisons on the distance raster. I don't know if this applies to your situation or not but it's one trick that might help. Sincerely, Forrest On Mon, Apr 11, 2016 at 10:58 AM Nelly Reduan >> wrote: Hello, I would like to build 100-m buffers (representing ecological corridors) around land cover attributes in a raster layer and to assign a given value (i.e., value of 13) to buffer cells. To do this, I'm using the function "buffer" (package raster) to draw the buffers around particular raster cells (i.e., cell values of 2 and 5). For example, in the image below, the buffers are represented in blue (cell values of 13) and the particular raster cells are represented in yellow (cell values of 2). The problem is that the time to run the function "buffer" is very low because I have a raster of 5000000 cells. Does anyone know how I can reduce the buffering time ? Thanks a lot for your time. Have a nice day. Nell [Capture.PNG] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org> https://stat.ethz.ch/mailman/listinfo/r-sig-geo [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] From nell.redu at hotmail.fr Mon May 9 19:36:52 2016 From: nell.redu at hotmail.fr (Nelly Reduan) Date: Mon, 9 May 2016 17:36:52 +0000 Subject: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) In-Reply-To: References: , , Message-ID: I have tried the following code to compute distances from raster pixels of 5 via the function "gdal_proximity": pypath <- Sys.which("C:\\OSGeo4W64\\bin\\gdal_proximity") owd <- getwd() on.exit(setwd(owd)) setwd(dirname(pypath)) rastpath <- "H:\\Project\\grassland.tif" outpath <- "H:\\Project\\distance.shp" maxDist <- 50 system2("C:\\OSGeo4W64\\OSGeo4W.bat", args=c(pypath,rastpath,outpath,maxDist)) But I obtain the error message: gdal_proximity.py srcfile dstfile [-srcband n] [-dstband n] [-of format] [-co name=value]* [-ot Byte/Int16/Int32/Float32/etc] [-values n,n,n] [-distunits PIXEL/GEO] [-maxdist n] [-nodata n] [-fixed-buf-val n] [-q] Warning message: running command '"C:\OSGeo4W64\OSGeo4W.bat" C:\OSGEO4~1\bin\GDAL_P~2.BAT H:\Project\grassland.tif H:\Project\distance.shp 50' had status 1 Here are some details about the raster "grassland.tif" > grassland class : RasterLayer dimensions : 9887, 30532, 301869884 (nrow, ncol, ncell) resolution : 10, 10 (x, y) extent : -515893.7, -210573.7, 110739.6, 209609.6 (xmin, xmax, ymin, ymax) coord. ref. : +proj=lcc +lat_1=46 +lat_2=60 +lat_0=44 +lon_0=-68.5 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs values : 5, 5 (min, max) Thanks a lot for your time. Have a nice day Nell ________________________________ De : Nelly Reduan Envoy? : vendredi 6 mai 2016 12:00:36 ? : Forrest Stevens; Michael Sumner; r-sig-geo at r-project.org Objet : RE: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) Thank you very much Forrest for your answer. How can I call the function "gdal_proximity" in R via system() ? Thanks a lot for your time. Nell ________________________________ De : Forrest Stevens Envoy? : mercredi 13 avril 2016 22:37:01 ? : Nelly Reduan; Michael Sumner; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) So you're correct, the buffer() and distance() functions you're using will take a long period of time. The code below illustrates the shortcut that I've used in the past when buffering only by the limit of one pixel, since it uses queens-case connectance and distance between cell-centers based on that connectance rule. This uses the gridDistance() function which is much faster than calculating straight line distances. You can see that the distance-based calculation takes under 40 seconds. But do notice that the buffer it creates by setting the threshold is around both classes and is indiscriminate of the nearest class: library(raster) clip_buff <- raster("clip_study_area_2010.tif") system.time(d <- gridDistance(clip_buff, c(2,3))) # user system elapsed # 37.36 11.00 48.41 rf[(rf != 2 & rf != 3)] <- NA ## Set buffer to 10m just for fun and assign ## value of 4 to that buffered region: rf[ d > 0 & d <= 10 ] <- 4 plot(rf) If you want to buffer by more than one pixel dimension then you'll probably want straight line distances and I'd suggest using GDAL and using the gdal_proximity utility via a system() call. Alternatively, you could look into other utilities that have better-optimized raster-based distance tools. Hopefully this gives you some ideas on how to proceed? Sincerely, Forrest On Wed, Apr 13, 2016 at 9:18 PM Nelly Reduan > wrote: I put a cropped raster with 3581676 cells in the link below: https://www.dropbox.com/sh/ewaz4yncdqt7kxj/AAAEHyuWyHzBE7gSINA1oayTa?dl=0 Here is my code to built the buffers: rf <- clip_buff rf [(rf != 2 & rf != 3)] <- NA plot(rf) system.time(corr <- buffer(rf, 10)) system.time(dist_rf <- distance(rf)) I stopped the code with the functions "buffer" and "distance" after two hours. Thanks a lot for your time. Have a nice day. Nell ________________________________ De : Michael Sumner > Envoy? : mardi 12 avril 2016 20:36 ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) I think we still haven't seen a print of the raster object? It may be a tiled file on disk? Try readAll to pull into memory, if it is tiled and read in on demand via gdal tools like extract will be very slow since access is done line by line. But just guessing, please give full details and ideally a reproducible example. Cheers, Mije On Wed, 13 Apr 2016, 02:33 Nelly Reduan > wrote: Yes, I tested the functions "distance" and "buffer" by using a cropped raster with around 5 million cells. But my original raster has 48096864 cells. Ideally, I would like to build the buffers from my original raster. Here are some characteristics of the original raster: class : RasterLayer dimensions : 4876, 9864, 48096864 (nrow, ncol, ncell) extent : 188384.5, 484304.5, 4914481, 5060761 (xmin, xmax, ymin, ymax) coord. ref. : +proj=tmerc +lat_0=0 +lon_0=-73.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Thanks a lot for your help. Have a nice day. Nell ________________________________ De : Forrest Stevens > Envoy? : lundi 11 avril 2016 18:55 ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) And this is for a raster with around 5 milliion cells? Your results surprise me a bit, especially if the bottleneck is at the call to buffer()/distance(). Your best bet is to wait for a response from Robert Hijmans or someone else working on the package, they might have some other tricks up their sleeves. In any case, I agree, 5+ hours is extremely excessive. Sincerely, Forrest On Mon, Apr 11, 2016 at 6:57 PM Nelly Reduan >> wrote: Thank you very much Forrest for your answer. I don't think I have memory problems (my computer has a 32 GB memory). Here is my code to draw the 100-m buffers with the function "buffer" (package raster): r1 <- r ## r is the original raster and has a resolution of 10m r1[(r1[]!=2 & r1[]!=5)]=NA plot(r1) r2 <- buffer(r1, 10) I also tested the function distance (package raster): r1 <- r ## r is the original raster and has a resolution of 10m r1[(r1[]!=2 & r1[]!=5)]=NA plot(r1) r3 <- distance(r1) In the two cases, I stopped the functions afer 5 hours as this was too long ! For the moment, I haven't find solutions. Thanks a lot for your time. Have a nice day. Nell ________________________________ De : Forrest Stevens >> Envoy? : lundi 11 avril 2016 09:09 ? : Nelly Reduan; r-sig-geo at r-project.org> Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) Five million cells isn't all that many, how slow is too slow? Buffering a raster of about 10 million cells on my laptop takes on the order of 20 seconds or so for a binary raster. Is it possible that you're fighting memory problems? In the past when doing multiple ring buffers I've found it faster to calculate a distance-to raster first, and then apply multiple logical comparisons on the distance raster. I don't know if this applies to your situation or not but it's one trick that might help. Sincerely, Forrest On Mon, Apr 11, 2016 at 10:58 AM Nelly Reduan >> wrote: Hello, I would like to build 100-m buffers (representing ecological corridors) around land cover attributes in a raster layer and to assign a given value (i.e., value of 13) to buffer cells. To do this, I'm using the function "buffer" (package raster) to draw the buffers around particular raster cells (i.e., cell values of 2 and 5). For example, in the image below, the buffers are represented in blue (cell values of 13) and the particular raster cells are represented in yellow (cell values of 2). The problem is that the time to run the function "buffer" is very low because I have a raster of 5000000 cells. Does anyone know how I can reduce the buffering time ? Thanks a lot for your time. Have a nice day. Nell [Capture.PNG] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org> https://stat.ethz.ch/mailman/listinfo/r-sig-geo [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] From rubenfcasal at gmail.com Mon May 9 23:59:16 2016 From: rubenfcasal at gmail.com (=?UTF-8?B?UnViw6luIEZlcm7DoW5kZXotQ2FzYWw=?=) Date: Mon, 9 May 2016 23:59:16 +0200 Subject: [R-sig-Geo] Mask a map using statistical significance In-Reply-To: <316111629.6363386.1462399572213.JavaMail.yahoo@mail.yahoo.com> References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> <316111629.6363386.1462399572213.JavaMail.yahoo@mail.yahoo.com> Message-ID: I will appreciate instructions to reproduce this map... Thanks... Ruben FC El 05/05/2016 00:06, "Thiago V. dos Santos via R-sig-Geo" < r-sig-geo at r-project.org> escribi?: Thanks Barry and Arnaud (off-list) for the valuable hints. I ended up managing to use rasterVis' levelplot to produce the map I was looking for. The key step was to convert the raster I wanted to use as a mask to SpatialPoints, and then pass it as an additional layer to levelplot. The final map, produced using my actual data, can be visualized here: https://dl. dropboxusercontent.com/u/27700634/rainfall_trend.png. Stippling indicates regions exceeding the 95% statistical significance. [[alternative HTML version deleted]] From a.brown at ieee.org Tue May 10 03:51:56 2016 From: a.brown at ieee.org (Alexander Brown) Date: Mon, 9 May 2016 21:51:56 -0400 Subject: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) In-Reply-To: References: Message-ID: I've attempted to use "OSGeo4W.bat" and the like, and have also seen such error messages. Shell functions like "OSGeo4W.bat" are transcriptions of Linux/UNIX shell scripts and can't be expected to work in a Windows environment, and are a very low priority in open source spatial software, which have many more important problems. (Google "OSGeo4W.bat" to see a variety of problem reports.) It's well worth the effort of assembling a Linux environment and learning to use it, for any important problems to be solved with open source tools, including GDAL. >From https://translate.google.com, Les fonctions "Shell" comme "OSGeo4W.bat" sont des transcriptions de Linux / UNIX ''shell scripts" -- ne peuvent pas ?tre appel?s ? travailler dans un environnement Windows, et sont une priorit? tr?s faible en logiciel open source spatiale, qui ont des probl?mes beaucoup plus importants. (Google "OSGeo4W.bat" pour voir une vari?t? de rapports de probl?mes.) Il vaut bien l'effort d'assemblage d'un environnement Linux et d'apprendre ? l'utiliser, pour tous les probl?mes importants ? r?soudre avec des outils open source, y compris GDAL. Sorry, best I can do. Good luck! On Mon, May 9, 2016 at 1:36 PM, Nelly Reduan wrote: > I have tried the following code to compute distances from raster pixels of > 5 via the function "gdal_proximity": > > > pypath <- Sys.which("C:\\OSGeo4W64\\bin\\gdal_proximity") > owd <- getwd() > on.exit(setwd(owd)) > setwd(dirname(pypath)) > rastpath <- "H:\\Project\\grassland.tif" > outpath <- "H:\\Project\\distance.shp" > maxDist <- 50 > system2("C:\\OSGeo4W64\\OSGeo4W.bat", > args=c(pypath,rastpath,outpath,maxDist)) > > > But I obtain the error message: > > gdal_proximity.py srcfile dstfile [-srcband n] [-dstband n] > [-of format] [-co name=value]* > [-ot Byte/Int16/Int32/Float32/etc] > [-values n,n,n] [-distunits PIXEL/GEO] > [-maxdist n] [-nodata n] [-fixed-buf-val n] [-q] > Warning message: > running command '"C:\OSGeo4W64\OSGeo4W.bat" > C:\OSGEO4~1\bin\GDAL_P~2.BAT H:\Project\grassland.tif > H:\Project\distance.shp 50' had status 1 > > > Here are some details about the raster "grassland.tif" > > > grassland > class : RasterLayer > dimensions : 9887, 30532, 301869884 (nrow, ncol, ncell) > resolution : 10, 10 (x, y) > extent : -515893.7, -210573.7, 110739.6, 209609.6 (xmin, xmax, > ymin, ymax) > coord. ref. : +proj=lcc +lat_1=46 +lat_2=60 +lat_0=44 +lon_0=-68.5 > +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > values : 5, 5 (min, max) > > > Thanks a lot for your time. > Have a nice day > Nell > > > ________________________________ > De : Nelly Reduan > Envoy? : vendredi 6 mai 2016 12:00:36 > ? : Forrest Stevens; Michael Sumner; r-sig-geo at r-project.org > Objet : RE: [R-sig-Geo] How to reduce the buffering time with the function > "buffer" (package raster) > > > Thank you very much Forrest for your answer. How can I call the function > "gdal_proximity" in R via system() ? > > > Thanks a lot for your time. > > Nell > > ________________________________ > De : Forrest Stevens > Envoy? : mercredi 13 avril 2016 22:37:01 > ? : Nelly Reduan; Michael Sumner; Forrest Stevens; r-sig-geo at r-project.org > Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function > "buffer" (package raster) > > So you're correct, the buffer() and distance() functions you're using will > take a long period of time. The code below illustrates the shortcut that > I've used in the past when buffering only by the limit of one pixel, since > it uses queens-case connectance and distance between cell-centers based on > that connectance rule. This uses the gridDistance() function which is much > faster than calculating straight line distances. You can see that the > distance-based calculation takes under 40 seconds. But do notice that the > buffer it creates by setting the threshold is around both classes and is > indiscriminate of the nearest class: > > library(raster) > > clip_buff <- raster("clip_study_area_2010.tif") > > system.time(d <- gridDistance(clip_buff, c(2,3))) > # user system elapsed > # 37.36 11.00 48.41 > > rf[(rf != 2 & rf != 3)] <- NA > > ## Set buffer to 10m just for fun and assign > ## value of 4 to that buffered region: > rf[ d > 0 & d <= 10 ] <- 4 > plot(rf) > > If you want to buffer by more than one pixel dimension then you'll > probably want straight line distances and I'd suggest using GDAL and using > the gdal_proximity utility via a system() call. Alternatively, you could > look into other utilities that have better-optimized raster-based distance > tools. Hopefully this gives you some ideas on how to proceed? > > Sincerely, > Forrest > > > On Wed, Apr 13, 2016 at 9:18 PM Nelly Reduan nell.redu at hotmail.fr>> wrote: > > I put a cropped raster with 3581676 cells in the link below: > > > https://www.dropbox.com/sh/ewaz4yncdqt7kxj/AAAEHyuWyHzBE7gSINA1oayTa?dl=0 > > > Here is my code to built the buffers: > > rf <- clip_buff > > rf [(rf != 2 & rf != 3)] <- NA > > plot(rf) > > system.time(corr <- buffer(rf, 10)) > > system.time(dist_rf <- distance(rf)) > > > I stopped the code with the functions "buffer" and "distance" after two > hours. > > > Thanks a lot for your time. > > Have a nice day. > > Nell > > > > ________________________________ > De : Michael Sumner > > Envoy? : mardi 12 avril 2016 20:36 > > ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org r-sig-geo at r-project.org> > Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function > "buffer" (package raster) > > I think we still haven't seen a print of the raster object? > > It may be a tiled file on disk? Try readAll to pull into memory, if it is > tiled and read in on demand via gdal tools like extract will be very slow > since access is done line by line. > > But just guessing, please give full details and ideally a reproducible > example. > > Cheers, Mije > > On Wed, 13 Apr 2016, 02:33 Nelly Reduan nell.redu at hotmail.fr>> wrote: > Yes, I tested the functions "distance" and "buffer" by using a cropped > raster with around 5 million cells. But my original raster has 48096864 > cells. Ideally, I would like to build the buffers from my original raster. > Here are some characteristics of the original raster: > > > class : RasterLayer > > dimensions : 4876, 9864, 48096864 (nrow, ncol, ncell) > > extent : 188384.5, 484304.5, 4914481, 5060761 (xmin, xmax, ymin, > ymax) > > coord. ref. : +proj=tmerc +lat_0=0 +lon_0=-73.5 +k=0.9999 +x_0=304800 > +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs > > > Thanks a lot for your help. > > Have a nice day. > > Nell > > > > ________________________________ > De : Forrest Stevens r-sig-geo at forreststevens.com>> > Envoy? : lundi 11 avril 2016 18:55 > ? : Nelly Reduan; Forrest Stevens; r-sig-geo at r-project.org r-sig-geo at r-project.org> > Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function > "buffer" (package raster) > > And this is for a raster with around 5 milliion cells? Your results > surprise me a bit, especially if the bottleneck is at the call to > buffer()/distance(). Your best bet is to wait for a response from Robert > Hijmans or someone else working on the package, they might have some other > tricks up their sleeves. In any case, I agree, 5+ hours is extremely > excessive. > > Sincerely, > Forrest > > On Mon, Apr 11, 2016 at 6:57 PM Nelly Reduan nell.redu at hotmail.fr> nell.redu at hotmail.fr>>> wrote: > > Thank you very much Forrest for your answer. I don't think I have memory > problems (my computer has a 32 GB memory). > > > Here is my code to draw the 100-m buffers with the function "buffer" > (package raster): > > r1 <- r ## r is the original raster and has a resolution of 10m > r1[(r1[]!=2 & r1[]!=5)]=NA > plot(r1) > r2 <- buffer(r1, 10) > > > I also tested the function distance (package raster): > > r1 <- r ## r is the original raster and has a resolution of 10m > r1[(r1[]!=2 & r1[]!=5)]=NA > plot(r1) > r3 <- distance(r1) > > > In the two cases, I stopped the functions afer 5 hours as this was too > long ! For the moment, I haven't find solutions. > > > Thanks a lot for your time. > > Have a nice day. > > Nell > > > > ________________________________ > De : Forrest Stevens r-sig-geo at forreststevens.com> r-sig-geo at forreststevens.com>>> > Envoy? : lundi 11 avril 2016 09:09 > ? : Nelly Reduan; r-sig-geo at r-project.org >> > Objet : Re: [R-sig-Geo] How to reduce the buffering time with the function > "buffer" (package raster) > > Five million cells isn't all that many, how slow is too slow? Buffering a > raster of about 10 million cells on my laptop takes on the order of 20 > seconds or so for a binary raster. Is it possible that you're fighting > memory problems? > > In the past when doing multiple ring buffers I've found it faster to > calculate a distance-to raster first, and then apply multiple logical > comparisons on the distance raster. I don't know if this applies to your > situation or not but it's one trick that might help. > > Sincerely, > Forrest > > On Mon, Apr 11, 2016 at 10:58 AM Nelly Reduan nell.redu at hotmail.fr>>> wrote: > > Hello, > > > I would like to build 100-m buffers (representing ecological corridors) > around land cover attributes in a raster layer and to assign a given value > (i.e., value of 13) to buffer cells. > > > To do this, I'm using the function "buffer" (package raster) to draw the > buffers around particular raster cells (i.e., cell values of 2 and 5). For > example, in the image below, the buffers are represented in blue (cell > values of 13) and the particular raster cells are represented in yellow > (cell values of 2). > > > The problem is that the time to run the function "buffer" is very low > because I have a raster of 5000000 cells. Does anyone know how I can reduce > the buffering time ? > > > Thanks a lot for your time. > > Have a nice day. > > Nell > > > [Capture.PNG] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org R-sig-Geo at r-project.org> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- > Dr. Michael Sumner > Software and Database Engineer > Australian Antarctic Division > 203 Channel Highway > Kingston Tasmania 7050 Australia > > > [[alternative HTML version deleted]] > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From adamhsparks at gmail.com Tue May 10 08:39:24 2016 From: adamhsparks at gmail.com (Adam H Sparks) Date: Tue, 10 May 2016 16:39:24 +1000 Subject: [R-sig-Geo] Warning when stacking, masking or cropping raster objects Message-ID: Hi all, I'm working on a vignette from the R-OpenSci auunconf, https://github.com/saundersk1/auunconf16/blob/master/Vignette%20BoM.Rmd, and am suddenly getting warning messages where I've never had any before with this process. In the "Australian Water Availability Project (AWAP)" section, at the very end of the file, some grid files are downloaded and saved and GADM level 2 data are fetched to do cropping and masking. Two weeks ago when we put this together it all worked with no error messages. Today as I'm working on cleaning up the vignette I'm getting error messages I've never seen before when doing these things. For example, the line: cfiles <- stack(dir(pattern = "grid$")) Now returns these warning messages: Warning messages: 1: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 2: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 3: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 4: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 5: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 6: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 7: In `[<-`(`*tmp*`, nl, value = r) : implicit list embedding of S4 objects is deprecated When I try to mask I get similar messages about the implicit list embedding of S4 objects being deprecated. For now in the vignette I've suppressed the warning messages as the code appears to work, it just gives these warnings, but I'd like to understand why I'm getting them. -- Adam Sparks Associate Professor Field Crops Pathology Centre for Crop Health University of Southern Queensland Toowoomba, QLD, AU @adamhsparks [[alternative HTML version deleted]] From tech_dev at wildintellect.com Tue May 10 19:21:03 2016 From: tech_dev at wildintellect.com (Alex M) Date: Tue, 10 May 2016 10:21:03 -0700 Subject: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster) In-Reply-To: References: Message-ID: <5732187F.2060207@wildintellect.com> On 05/09/2016 10:36 AM, Nelly Reduan wrote: > But I obtain the error message: > > gdal_proximity.py srcfile dstfile [-srcband n] [-dstband n] > [-of format] [-co name=value]* > [-ot Byte/Int16/Int32/Float32/etc] > [-values n,n,n] [-distunits PIXEL/GEO] > [-maxdist n] [-nodata n] [-fixed-buf-val n] [-q] > Warning message: > running command '"C:\OSGeo4W64\OSGeo4W.bat" C:\OSGEO4~1\bin\GDAL_P~2.BAT H:\Project\grassland.tif H:\Project\distance.shp 50' had status 1 I would test the command directly on the osgeo4w shell first to figure out what's wrong. Note, I think that command outputs a raster not a shp. Thanks, Alex From thi_veloso at yahoo.com.br Tue May 10 21:50:02 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Tue, 10 May 2016 19:50:02 +0000 (UTC) Subject: [R-sig-Geo] Mask a map using statistical significance In-Reply-To: References: <1350390896.5790739.1462317089174.JavaMail.yahoo.ref@mail.yahoo.com> <1350390896.5790739.1462317089174.JavaMail.yahoo@mail.yahoo.com> <316111629.6363386.1462399572213.JavaMail.yahoo@mail.yahoo.com> Message-ID: <598405574.1759604.1462909802959.JavaMail.yahoo@mail.yahoo.com> Ruben, This is a tentative reproducible example using "real" spatial data, rather than the synthetic data I proposed in the original question. (I should have thought of this example earlier, in order to spatially please Barry lol) require(raster) require(rasterVis) # Scratch raster objects data(volcano) r1 <- raster(volcano) over <- ifelse(volcano >=160 & volcano <=180, 1, NA) # This is the "mask" raster r2 <- raster(over) # And this is the key step: # To convert the "mask" raster to spatial points r.mask <- rasterToPoints(r2, spatial=TRUE) # Plot levelplot(r1, margin=F) + layer(sp.points(r.mask, pch=20, cex=0.3, alpha=0.8)) It looks a little better now. To control the parameters of the points (such as color, size, type etc), documentation is available in ?sp.points . Greetings, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota On Monday, May 9, 2016 4:59 PM, Rub?n Fern?ndez-Casal wrote: I will appreciate instructions to reproduce this map... Thanks... Ruben FC El 05/05/2016 00:06, "Thiago V. dos Santos via R-sig-Geo" escribi?: Thanks Barry and Arnaud (off-list) for the valuable hints. I ended up managing to use rasterVis' levelplot to produce the map I was looking for. The key step was to convert the raster I wanted to use as a mask to SpatialPoints, and then pass it as an additional layer to levelplot. The final map, produced using my actual data, can be visualized here: https://dl. dropboxusercontent.com/u/27700634/rainfall_trend.png. Stippling indicates regions exceeding the 95% statistical significance. From juta.kawalerowicz at nuffield.ox.ac.uk Wed May 11 14:51:53 2016 From: juta.kawalerowicz at nuffield.ox.ac.uk (Juta Kawalerowicz) Date: Wed, 11 May 2016 14:51:53 +0200 Subject: [R-sig-Geo] spsample bug? Message-ID: Hi I encountred a problme when running a loop to generate randomly distributed points within a polygon. The error I get is: Error in .local(x, n, type, ...) : iteration did not converge; try enlarging argument iter Here is the code which allows to get this error (although you will get it for different i). Any ideas would be much appreciated. Juta ###import polygon shapefile from Dropbox con <- url("https://www.dropbox.com/s/b6v2e14dr6rn3zw/spsample.RData?raw=1") load(con) #see what's inside plot(dry.grid.u, col="red", axes=TRUE) class(dry.grid.u) #let's say we want 11 points generated n<-11 #works fine for doing it just once points<-spsample(dry.grid.u,n=n,type="random") plot(points, add=TRUE) #but when looped over many times there is a problem for (i in 1:5000){ print(i) points<-spsample(dry.grid.u,n=n,type="random") } [[alternative HTML version deleted]] From tech_dev at wildintellect.com Wed May 11 17:09:53 2016 From: tech_dev at wildintellect.com (Alex Mandel) Date: Wed, 11 May 2016 08:09:53 -0700 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: Message-ID: <57334B41.5050304@wildintellect.com> 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ > > > DOWNLOAD: > _______________ > MODISserverOrder : LPDAAC, LAADS > dlmethod : auto > stubbornness : 5 > > > PROCESSING: > _______________ > GDAL : GDAL 2.0.2, released 2016/01/26 > MRT : Version 4.1 (March 2011) > pixelSize : asIn > outProj : GEOGRAPHIC > resamplingType : NN > dataFormat : GTiff > > > DEPENDENCIES: > _______________ > >> 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* >> sessionInfo() > R version 3.2.5 (2016-04-14) > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 > > loaded via a namespace (and not attached): > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 > > > > __________________________________________________ > > Hakim Abdi | PhD Candidate > Center for Geobiosphere Science > > Department of Physical Geography and Ecosystem Science > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > From edzer.pebesma at uni-muenster.de Wed May 11 17:28:11 2016 From: edzer.pebesma at uni-muenster.de (Edzer Pebesma) Date: Wed, 11 May 2016 17:28:11 +0200 Subject: [R-sig-Geo] spsample bug? In-Reply-To: References: Message-ID: <57334F8B.7030200@uni-muenster.de> On 11/05/16 14:51, Juta Kawalerowicz wrote: > Hi I encountred a problme when running a loop to generate randomly > distributed points within a polygon. The error I get is: > > Error in .local(x, n, type, ...) : > iteration did not converge; try enlarging argument iter did you try enlarging argument iter? For me this worked: ... points <- spsample(dry.grid.u, n = n, type = "random", iter = 6) > > Here is the code which allows to get this error (although you will get it > for different i). Any ideas would be much appreciated. > > Juta > > ###import polygon shapefile from Dropbox > con <- url("https://www.dropbox.com/s/b6v2e14dr6rn3zw/spsample.RData?raw=1") > load(con) > > #see what's inside > plot(dry.grid.u, col="red", axes=TRUE) > class(dry.grid.u) > > #let's say we want 11 points generated > n<-11 > #works fine for doing it just once > points<-spsample(dry.grid.u,n=n,type="random") > plot(points, add=TRUE) > > #but when looped over many times there is a problem > > for (i in 1:5000){ > print(i) > points<-spsample(dry.grid.u,n=n,type="random") > } > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From juta.kawalerowicz at nuffield.ox.ac.uk Wed May 11 17:33:46 2016 From: juta.kawalerowicz at nuffield.ox.ac.uk (Juta Kawalerowicz) Date: Wed, 11 May 2016 17:33:46 +0200 Subject: [R-sig-Geo] spsample bug? In-Reply-To: <711445fa-b392-44e0-80ac-1c3b3c4cf139@HUB03.ad.oak.ox.ac.uk> References: <711445fa-b392-44e0-80ac-1c3b3c4cf139@HUB03.ad.oak.ox.ac.uk> Message-ID: Yes, this seems to solve this problem. Many thanks Edzer! Juta On Wed, May 11, 2016 at 5:28 PM, Edzer Pebesma < edzer.pebesma at uni-muenster.de> wrote: > > > On 11/05/16 14:51, Juta Kawalerowicz wrote: > > Hi I encountred a problme when running a loop to generate randomly > > distributed points within a polygon. The error I get is: > > > > Error in .local(x, n, type, ...) : > > iteration did not converge; try enlarging argument iter > > did you try enlarging argument iter? For me this worked: > > ... > points <- spsample(dry.grid.u, n = n, type = "random", iter = 6) > > > > > Here is the code which allows to get this error (although you will get it > > for different i). Any ideas would be much appreciated. > > > > Juta > > > > ###import polygon shapefile from Dropbox > > con <- url(" > https://www.dropbox.com/s/b6v2e14dr6rn3zw/spsample.RData?raw=1") > > load(con) > > > > #see what's inside > > plot(dry.grid.u, col="red", axes=TRUE) > > class(dry.grid.u) > > > > #let's say we want 11 points generated > > n<-11 > > #works fine for doing it just once > > points<-spsample(dry.grid.u,n=n,type="random") > > plot(points, add=TRUE) > > > > #but when looped over many times there is a problem > > > > for (i in 1:5000){ > > print(i) > > points<-spsample(dry.grid.u,n=n,type="random") > > } > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > R-sig-Geo mailing list > > R-sig-Geo at 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 > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From hakim.abdi at nateko.lu.se Mon May 16 10:47:59 2016 From: hakim.abdi at nateko.lu.se (Hakim Abdi) Date: Mon, 16 May 2016 10:47:59 +0200 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: Message-ID: 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ > > > > > > DOWNLOAD: > > _______________ > > MODISserverOrder : LPDAAC, LAADS > > dlmethod : auto > > stubbornness : 5 > > > > > > PROCESSING: > > _______________ > > GDAL : GDAL 2.0.2, released 2016/01/26 > > MRT : Version 4.1 (March 2011) > > pixelSize : asIn > > outProj : GEOGRAPHIC > > resamplingType : NN > > dataFormat : GTiff > > > > > > DEPENDENCIES: > > _______________ > > > >> 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* > >> sessionInfo() > > R version 3.2.5 (2016-04-14) > > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 > > > > loaded via a namespace (and not attached): > > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 > > > > > > > > __________________________________________________ > > > > Hakim Abdi | PhD Candidate > > Center for Geobiosphere Science > > > > Department of Physical Geography and Ecosystem Science > > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > R-sig-Geo mailing list > > R-sig-Geo at r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gdalDriversOutput.jpg Type: image/jpeg Size: 25422 bytes Desc: not available URL: From aolinto.lst at gmail.com Mon May 16 20:32:04 2016 From: aolinto.lst at gmail.com (Antonio Silva) Date: Mon, 16 May 2016 15:32:04 -0300 Subject: [R-sig-Geo] getting mean values for each raster in a stack Message-ID: Dear R users I have a raster stack and a polygon. I want the mean value inside this polygon for each raster in the stack. I'm doing the following: vals <- extract(stack,polygon) colMeans(r.vals[[1]]) # only for mean values # or for (i in 1:nlayers(stack)) {print(mean(vals[[1]][,i]))} # mean or other parameter I also tried to use lapply, but I got only the overall mean with lapply(vals, FUN=mean) I wonder if there is a way to get the mean (and other parameters) for each layer using lapply function. Thanks in advance. Antonio Olinto [[alternative HTML version deleted]] From aolinto.lst at gmail.com Mon May 16 22:50:37 2016 From: aolinto.lst at gmail.com (Antonio Silva) Date: Mon, 16 May 2016 17:50:37 -0300 Subject: [R-sig-Geo] getting mean values for each raster in a stack In-Reply-To: References: Message-ID: Hi, After many trials and some reading I got what I need apply(vals[[1]],2,mean) Anyway I would welcome comments to improve this solution. Best regards Antonio Olinto 2016-05-16 15:32 GMT-03:00 Antonio Silva : > Dear R users > > I have a raster stack and a polygon. > > I want the mean value inside this polygon for each raster in the stack. > > I'm doing the following: > > vals <- extract(stack,polygon) > colMeans(r.vals[[1]]) # only for mean values > # or > for (i in 1:nlayers(stack)) {print(mean(vals[[1]][,i]))} # mean or other > parameter > > I also tried to use lapply, but I got only the overall mean with > lapply(vals, FUN=mean) > > I wonder if there is a way to get the mean (and other parameters) for each > layer using lapply function. > > Thanks in advance. > > Antonio Olinto > > -- Ant?nio Olinto ?vila da Silva Bi?logo / Ocean?grafo Instituto de Pesca (Fisheries Institute) S?o Paulo, Brasil [[alternative HTML version deleted]] From edzer.pebesma at uni-muenster.de Mon May 16 23:01:35 2016 From: edzer.pebesma at uni-muenster.de (Edzer Pebesma) Date: Mon, 16 May 2016 23:01:35 +0200 Subject: [R-sig-Geo] getting mean values for each raster in a stack In-Reply-To: References: Message-ID: <573A352F.3050207@uni-muenster.de> Did you try: extract(stack, polygon, mean) ? On 16/05/16 22:50, Antonio Silva wrote: > Hi, > > After many trials and some reading I got what I need > > apply(vals[[1]],2,mean) > > Anyway I would welcome comments to improve this solution. > > Best regards > > Antonio Olinto > > > 2016-05-16 15:32 GMT-03:00 Antonio Silva : > >> Dear R users >> >> I have a raster stack and a polygon. >> >> I want the mean value inside this polygon for each raster in the stack. >> >> I'm doing the following: >> >> vals <- extract(stack,polygon) >> colMeans(r.vals[[1]]) # only for mean values >> # or >> for (i in 1:nlayers(stack)) {print(mean(vals[[1]][,i]))} # mean or other >> parameter >> >> I also tried to use lapply, but I got only the overall mean with >> lapply(vals, FUN=mean) >> >> I wonder if there is a way to get the mean (and other parameters) for each >> layer using lapply function. >> >> Thanks in advance. >> >> Antonio Olinto >> >> > > -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From aolinto.lst at gmail.com Mon May 16 23:14:56 2016 From: aolinto.lst at gmail.com (Antonio Silva) Date: Mon, 16 May 2016 18:14:56 -0300 Subject: [R-sig-Geo] getting mean values for each raster in a stack In-Reply-To: <573A352F.3050207@uni-muenster.de> References: <573A352F.3050207@uni-muenster.de> Message-ID: Dear Pebesma No I din't, thanks. Probably I have not read enough. extract package:raster fun: function to summarize the values (e.g. ?mean?). The function should take a single numeric vector as argument and return a single value (e.g. mean, min or max), and accept a ?na.rm? argument ... ?? Thanks again. A.O. 2016-05-16 18:01 GMT-03:00 Edzer Pebesma : > Did you try: > > extract(stack, polygon, mean) > > ? > > On 16/05/16 22:50, Antonio Silva wrote: > > Hi, > > > > After many trials and some reading I got what I need > > > > apply(vals[[1]],2,mean) > > > > Anyway I would welcome comments to improve this solution. > > > > Best regards > > > > Antonio Olinto > > > > > > 2016-05-16 15:32 GMT-03:00 Antonio Silva : > > > >> Dear R users > >> > >> I have a raster stack and a polygon. > >> > >> I want the mean value inside this polygon for each raster in the stack. > >> > >> I'm doing the following: > >> > >> vals <- extract(stack,polygon) > >> colMeans(r.vals[[1]]) # only for mean values > >> # or > >> for (i in 1:nlayers(stack)) {print(mean(vals[[1]][,i]))} # mean or other > >> parameter > >> > >> I also tried to use lapply, but I got only the overall mean with > >> lapply(vals, FUN=mean) > >> > >> I wonder if there is a way to get the mean (and other parameters) for > each > >> layer using lapply function. > >> > >> Thanks in advance. > >> > >> Antonio Olinto > >> > >> > > > > > > -- > 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 at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Ant?nio Olinto ?vila da Silva Bi?logo / Ocean?grafo Instituto de Pesca (Fisheries Institute) S?o Paulo, Brasil [[alternative HTML version deleted]] From thi_veloso at yahoo.com.br Tue May 17 06:20:16 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Tue, 17 May 2016 04:20:16 +0000 (UTC) Subject: [R-sig-Geo] Warning when stacking, masking or cropping raster objects In-Reply-To: References: Message-ID: <1799021526.3209448.1463458816813.JavaMail.yahoo@mail.yahoo.com> I also noticed those warnings after the last raster update. Here is one simple way to reproduce them: library(raster) r <- raster(nrows=100, ncols=100, xmn=5, xmx=10, ymn=46, ymx=51) r[] <- 1:ncell(r) # crop raster with a SpatialPolygon* object if (require(rgdal) & require(rgeos)) { p <- shapefile(system.file("external/lux.shp", package="raster")) } # Crop and mask rc <- crop(r, extent(p)) rc <- mask(rc, p) I wonder if there are new instructions to crop/mask rasters that are not yet documented... Greetings, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota On Tuesday, May 10, 2016 1:45 AM, Adam H Sparks wrote: Hi all, I'm working on a vignette from the R-OpenSci auunconf, https://github.com/saundersk1/auunconf16/blob/master/Vignette%20BoM.Rmd, and am suddenly getting warning messages where I've never had any before with this process. In the "Australian Water Availability Project (AWAP)" section, at the very end of the file, some grid files are downloaded and saved and GADM level 2 data are fetched to do cropping and masking. Two weeks ago when we put this together it all worked with no error messages. Today as I'm working on cleaning up the vignette I'm getting error messages I've never seen before when doing these things. For example, the line: cfiles <- stack(dir(pattern = "grid$")) Now returns these warning messages: Warning messages: 1: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 2: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 3: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 4: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 5: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 6: In `[<-`(`*tmp*`, j, value = ) : implicit list embedding of S4 objects is deprecated 7: In `[<-`(`*tmp*`, nl, value = r) : implicit list embedding of S4 objects is deprecated When I try to mask I get similar messages about the implicit list embedding of S4 objects being deprecated. For now in the vignette I've suppressed the warning messages as the code appears to work, it just gives these warnings, but I'd like to understand why I'm getting them. -- Adam Sparks Associate Professor Field Crops Pathology Centre for Crop Health University of Southern Queensland Toowoomba, QLD, AU @adamhsparks [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo From englishchristophera at gmail.com Tue May 17 08:52:12 2016 From: englishchristophera at gmail.com (chris english) Date: Tue, 17 May 2016 09:52:12 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: Message-ID: 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.2 Rcpp_0.12.4 grid_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 > Hmmmm. 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >> > >> > >> > DOWNLOAD: >> > _______________ >> > MODISserverOrder : LPDAAC, LAADS >> > dlmethod : auto >> > stubbornness : 5 >> > >> > >> > PROCESSING: >> > _______________ >> > GDAL : GDAL 2.0.2, released 2016/01/26 >> > MRT : Version 4.1 (March 2011) >> > pixelSize : asIn >> > outProj : GEOGRAPHIC >> > resamplingType : NN >> > dataFormat : GTiff >> > >> > >> > DEPENDENCIES: >> > _______________ >> > >> >> 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* >> >> sessionInfo() >> > R version 3.2.5 (2016-04-14) >> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >> > >> > loaded via a namespace (and not attached): >> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >> > >> > >> > >> > __________________________________________________ >> > >> > Hakim Abdi | PhD Candidate >> > Center for Geobiosphere Science >> > >> > Department of Physical Geography and Ecosystem Science >> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >> > >> > [[alternative HTML version deleted]] >> > >> > _______________________________________________ >> > R-sig-Geo mailing list >> > R-sig-Geo at r-project.org >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > >> >> > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From englishchristophera at gmail.com Tue May 17 09:05:07 2016 From: englishchristophera at gmail.com (chris english) Date: Tue, 17 May 2016 10:05:07 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: Message-ID: 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 < englishchristophera at 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.2 Rcpp_0.12.4 grid_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 > > > Hmmmm. 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>> > >>> > >>> > DOWNLOAD: >>> > _______________ >>> > MODISserverOrder : LPDAAC, LAADS >>> > dlmethod : auto >>> > stubbornness : 5 >>> > >>> > >>> > PROCESSING: >>> > _______________ >>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>> > MRT : Version 4.1 (March 2011) >>> > pixelSize : asIn >>> > outProj : GEOGRAPHIC >>> > resamplingType : NN >>> > dataFormat : GTiff >>> > >>> > >>> > DEPENDENCIES: >>> > _______________ >>> > >>> >> 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* >>> >> sessionInfo() >>> > R version 3.2.5 (2016-04-14) >>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>> > >>> > loaded via a namespace (and not attached): >>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >>> > >>> > >>> > >>> > __________________________________________________ >>> > >>> > Hakim Abdi | PhD Candidate >>> > Center for Geobiosphere Science >>> > >>> > Department of Physical Geography and Ecosystem Science >>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>> > >>> > [[alternative HTML version deleted]] >>> > >>> > _______________________________________________ >>> > R-sig-Geo mailing list >>> > R-sig-Geo at r-project.org >>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> > >>> >>> >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > > [[alternative HTML version deleted]] From hakim.abdi at nateko.lu.se Tue May 17 09:07:33 2016 From: hakim.abdi at nateko.lu.se (Hakim Abdi) Date: Tue, 17 May 2016 09:07:33 +0200 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: Same here. Loading rgdal didn't make a difference. On Tue, May 17, 2016 at 9:05 AM, chris english < englishchristophera at 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 < > englishchristophera at 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.2 Rcpp_0.12.4 grid_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 >> > >> Hmmmm. 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>> > >>>> > >>>> > DOWNLOAD: >>>> > _______________ >>>> > MODISserverOrder : LPDAAC, LAADS >>>> > dlmethod : auto >>>> > stubbornness : 5 >>>> > >>>> > >>>> > PROCESSING: >>>> > _______________ >>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>> > MRT : Version 4.1 (March 2011) >>>> > pixelSize : asIn >>>> > outProj : GEOGRAPHIC >>>> > resamplingType : NN >>>> > dataFormat : GTiff >>>> > >>>> > >>>> > DEPENDENCIES: >>>> > _______________ >>>> > >>>> >> 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* >>>> >> sessionInfo() >>>> > R version 3.2.5 (2016-04-14) >>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>> > >>>> > loaded via a namespace (and not attached): >>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >>>> > >>>> > >>>> > >>>> > __________________________________________________ >>>> > >>>> > Hakim Abdi | PhD Candidate >>>> > Center for Geobiosphere Science >>>> > >>>> > Department of Physical Geography and Ecosystem Science >>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>> > >>>> > [[alternative HTML version deleted]] >>>> > >>>> > _______________________________________________ >>>> > R-sig-Geo mailing list >>>> > R-sig-Geo at r-project.org >>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>> > >>>> >>>> >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> >> >> > [[alternative HTML version deleted]] From loic.dutrieux at wur.nl Tue May 17 10:03:53 2016 From: loic.dutrieux at wur.nl (=?UTF-8?Q?Lo=c3=afc_Dutrieux?=) Date: Tue, 17 May 2016 10:03:53 +0200 Subject: [R-sig-Geo] Warning when stacking, masking or cropping raster objects In-Reply-To: <1799021526.3209448.1463458816813.JavaMail.yahoo@mail.yahoo.com> References: <1799021526.3209448.1463458816813.JavaMail.yahoo@mail.yahoo.com> Message-ID: <573AD069.5080400@wur.nl> It's related to a change in R, not in raster. See "DEPRECATED AND DEFUNCT" related to R 3.3.0 in https://cran.r-project.org/src/base/NEWS Cheers, Lo?c On 05/17/2016 06:20 AM, Thiago V. dos Santos via R-sig-Geo wrote: > I also noticed those warnings after the last raster update. Here is one simple way to reproduce them: > > > library(raster) > r <- raster(nrows=100, ncols=100, xmn=5, xmx=10, ymn=46, ymx=51) > r[] <- 1:ncell(r) > > # crop raster with a SpatialPolygon* object > if (require(rgdal) & require(rgeos)) { > p <- shapefile(system.file("external/lux.shp", package="raster")) > } > > # Crop and mask > rc <- crop(r, extent(p)) > rc <- mask(rc, p) > > > I wonder if there are new instructions to crop/mask rasters that are not yet documented... > Greetings, > -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > > > On Tuesday, May 10, 2016 1:45 AM, Adam H Sparks wrote: > Hi all, > I'm working on a vignette from the R-OpenSci auunconf, > https://github.com/saundersk1/auunconf16/blob/master/Vignette%20BoM.Rmd, > and am suddenly getting warning messages where I've never had any before > with this process. > > In the "Australian Water Availability Project (AWAP)" section, at the very > end of the file, some grid files are downloaded and saved and GADM level 2 > data are fetched to do cropping and masking. > > Two weeks ago when we put this together it all worked with no error > messages. Today as I'm working on cleaning up the vignette I'm getting > error messages I've never seen before when doing these things. > > For example, the line: > cfiles <- stack(dir(pattern = "grid$")) > > Now returns these warning messages: > Warning messages: > 1: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 2: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 3: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 4: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 5: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 6: In `[<-`(`*tmp*`, j, value = ) : > implicit list embedding of S4 objects is deprecated > 7: In `[<-`(`*tmp*`, nl, value = r) : > implicit list embedding of S4 objects is deprecated > > When I try to mask I get similar messages about the implicit list embedding > of S4 objects being deprecated. > > For now in the vignette I've suppressed the warning messages as the code > appears to work, it just gives these warnings, but I'd like to understand > why I'm getting them. > > > From adamhsparks at gmail.com Tue May 17 11:06:10 2016 From: adamhsparks at gmail.com (Adam H Sparks) Date: Tue, 17 May 2016 19:06:10 +1000 Subject: [R-sig-Geo] Warning when stacking, masking or cropping raster objects In-Reply-To: <573AD069.5080400@wur.nl> References: <1799021526.3209448.1463458816813.JavaMail.yahoo@mail.yahoo.com> <573AD069.5080400@wur.nl> Message-ID: Thanks, Lo?c, I read the NEWS but didn't fully understand/realise that was what was happening here. On 17 May 2016 at 18:03, Lo?c Dutrieux wrote: > It's related to a change in R, not in raster. See "DEPRECATED AND DEFUNCT" > related to R 3.3.0 in https://cran.r-project.org/src/base/NEWS > > Cheers, > Lo?c > > > On 05/17/2016 06:20 AM, Thiago V. dos Santos via R-sig-Geo wrote: > >> I also noticed those warnings after the last raster update. Here is one >> simple way to reproduce them: >> >> >> library(raster) >> r <- raster(nrows=100, ncols=100, xmn=5, xmx=10, ymn=46, ymx=51) >> r[] <- 1:ncell(r) >> >> # crop raster with a SpatialPolygon* object >> if (require(rgdal) & require(rgeos)) { >> p <- shapefile(system.file("external/lux.shp", package="raster")) >> } >> >> # Crop and mask >> rc <- crop(r, extent(p)) >> rc <- mask(rc, p) >> >> >> I wonder if there are new instructions to crop/mask rasters that are not >> yet documented... >> Greetings, >> -- Thiago V. dos Santos >> >> PhD student >> Land and Atmospheric Science >> University of Minnesota >> >> >> >> On Tuesday, May 10, 2016 1:45 AM, Adam H Sparks >> wrote: >> Hi all, >> I'm working on a vignette from the R-OpenSci auunconf, >> https://github.com/saundersk1/auunconf16/blob/master/Vignette%20BoM.Rmd, >> and am suddenly getting warning messages where I've never had any before >> with this process. >> >> In the "Australian Water Availability Project (AWAP)" section, at the very >> end of the file, some grid files are downloaded and saved and GADM level 2 >> data are fetched to do cropping and masking. >> >> Two weeks ago when we put this together it all worked with no error >> messages. Today as I'm working on cleaning up the vignette I'm getting >> error messages I've never seen before when doing these things. >> >> For example, the line: >> cfiles <- stack(dir(pattern = "grid$")) >> >> Now returns these warning messages: >> Warning messages: >> 1: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 2: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 3: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 4: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 5: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 6: In `[<-`(`*tmp*`, j, value = ) : >> implicit list embedding of S4 objects is deprecated >> 7: In `[<-`(`*tmp*`, nl, value = r) : >> implicit list embedding of S4 objects is deprecated >> >> When I try to mask I get similar messages about the implicit list >> embedding >> of S4 objects being deprecated. >> >> For now in the vignette I've suppressed the warning messages as the code >> appears to work, it just gives these warnings, but I'd like to understand >> why I'm getting them. >> >> >> >> > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Adam Sparks Associate Professor Field Crops Pathology Centre for Crop Health University of Southern Queensland Toowoomba, QLD, AU @adamhsparks [[alternative HTML version deleted]] From larroque.jeremy at gmail.com Tue May 17 11:43:17 2016 From: larroque.jeremy at gmail.com (Jeremy Larroque) Date: Tue, 17 May 2016 11:43:17 +0200 Subject: [R-sig-Geo] K-select tolerance Message-ID: <056ed8d4-bed4-002c-bb97-ada82c449aaa@gmail.com> Dear list members, I am performing a K-select analysis (/kselect/ function in adehabitatHS), I have been able to compute the marginality for each animal, but does anyone know how to compute the tolerance for each individual? Many thanks! Jeremy [[alternative HTML version deleted]] From dncgst at gnewarchaeology.it Tue May 17 13:44:28 2016 From: dncgst at gnewarchaeology.it (Domenico Giusti) Date: Tue, 17 May 2016 13:44:28 +0200 Subject: [R-sig-Geo] R 3.3.0 - spatstat 1.45-2 - envelope -- Error in nrank%%1 : non-numeric argument to binary operator Message-ID: <573B041C.3040805@gnewarchaeology.it> Dear all, I get "Error in nrank%%1 : non-numeric argument to binary operator" running > data("amacrine") > E <- envelope(amacrine, Kcross, "on", "off", nsim=19, global=FALSE) Envelope works fine running > E <- alltypes(amacrine, Kcross, nsim=19, envelope=TRUE, global=FALSE) Thanks, -- Domenico Giusti GPG keyID: 2048R/A3AB7054F6E5D778 From r.turner at auckland.ac.nz Tue May 17 23:08:23 2016 From: r.turner at auckland.ac.nz (Rolf Turner) Date: Wed, 18 May 2016 09:08:23 +1200 Subject: [R-sig-Geo] R 3.3.0 - spatstat 1.45-2 - envelope -- Error in nrank%%1 : non-numeric argument to binary operator In-Reply-To: <573B041C.3040805@gnewarchaeology.it> References: <573B041C.3040805@gnewarchaeology.it> Message-ID: <93b393fe-19eb-e5d0-2059-614cfa428a7e@auckland.ac.nz> On 17/05/16 23:44, Domenico Giusti wrote: > Dear all, > > I get "Error in nrank%%1 : non-numeric argument to binary operator" running > >> data("amacrine") >> E <- envelope(amacrine, Kcross, "on", "off", nsim=19, global=FALSE) > > Envelope works fine running > >> E <- alltypes(amacrine, Kcross, nsim=19, envelope=TRUE, global=FALSE) > > Thanks, Try: E <- envelope(amacrine, Kcross, funargs=list(i="on",j="off"), nsim=19,global=FALSE) cheers, Rolf Turner P. S. Note that you *do not need* to set "global=FALSE"; this is the default. R. T. -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 From milujisb at gmail.com Wed May 18 00:25:54 2016 From: milujisb at gmail.com (Miluji Sb) Date: Wed, 18 May 2016 00:25:54 +0200 Subject: [R-sig-Geo] Address from Wikimapia Message-ID: Is it possible to convert latitude and longitude into addresses in R using Wikimapia mapping instead of Google? The reason being that Wikimapia addresses have more details. This is the code I have been using but this obtains the information from Google. library(data.table) library(ggmap) coords<- structure(list(Lattitude = c(23.8642394, 23.8643628, 23.8645843, 23.8632958, 23.8632859), Longitude = c(90.3981852, 90.3981042, 90.3954784, 90.3940043, 90.3940025)), .Names = c("Lattitude", "Longitude"), row.names = c(NA, 5L), class = "data.frame") coords$textAddress <- mapply(FUN = function(lon, lat) revgeocode(c(lon, lat)), coords$Longitude, coords$Lattitude) Thank you! Sincerely, Milu [[alternative HTML version deleted]] From istazahn at gmail.com Wed May 18 03:56:23 2016 From: istazahn at gmail.com (Ista Zahn) Date: Tue, 17 May 2016 21:56:23 -0400 Subject: [R-sig-Geo] Address from Wikimapia In-Reply-To: References: Message-ID: Maybe. The API is documented at http://wikimapia.org/api. You can interact with the API using (e.g.) the httr or curl packages in R. Best, Ista On May 17, 2016 6:27 PM, "Miluji Sb" wrote: Is it possible to convert latitude and longitude into addresses in R using Wikimapia mapping instead of Google? The reason being that Wikimapia addresses have more details. This is the code I have been using but this obtains the information from Google. library(data.table) library(ggmap) coords<- structure(list(Lattitude = c(23.8642394, 23.8643628, 23.8645843, 23.8632958, 23.8632859), Longitude = c(90.3981852, 90.3981042, 90.3954784, 90.3940043, 90.3940025)), .Names = c("Lattitude", "Longitude"), row.names = c(NA, 5L), class = "data.frame") coords$textAddress <- mapply(FUN = function(lon, lat) revgeocode(c(lon, lat)), coords$Longitude, coords$Lattitude) Thank you! Sincerely, Milu [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo [[alternative HTML version deleted]] From bob at rudis.net Wed May 18 04:18:27 2016 From: bob at rudis.net (boB Rudis) Date: Tue, 17 May 2016 22:18:27 -0400 Subject: [R-sig-Geo] Address from Wikimapia In-Reply-To: References: Message-ID: Just be aware that their API limit is up to 100 requests in 5 minutes. On Tue, May 17, 2016 at 9:56 PM, Ista Zahn wrote: > Maybe. The API is documented at http://wikimapia.org/api. You can interact > with the API using (e.g.) the httr or curl packages in R. > > Best, > Ista > On May 17, 2016 6:27 PM, "Miluji Sb" wrote: > > Is it possible to convert latitude and longitude into addresses in R using > Wikimapia mapping instead of Google? The reason being that Wikimapia > addresses have more details. > > This is the code I have been using but this obtains the information from > Google. > > library(data.table) > library(ggmap) > > coords<- structure(list(Lattitude = c(23.8642394, 23.8643628, 23.8645843, > 23.8632958, 23.8632859), Longitude = c(90.3981852, 90.3981042, > 90.3954784, 90.3940043, 90.3940025)), .Names = c("Lattitude", > "Longitude"), row.names = c(NA, 5L), class = "data.frame") > > coords$textAddress <- mapply(FUN = function(lon, lat) revgeocode(c(lon, > lat)), coords$Longitude, coords$Lattitude) > > Thank you! > > Sincerely, > > Milu > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo From englishchristophera at gmail.com Wed May 18 07:53:43 2016 From: englishchristophera at gmail.com (chris english) Date: Wed, 18 May 2016 08:53:43 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: > ?MODISoptions > MODIS:::checkTools("GDAL") Checking availabillity of GDAL: OK, GDAL 2.1.0dev, released 2015/99/99 found! > getOption("MODIS_gdalOutDriver") [1] name description 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 wrote: > Same here. Loading rgdal didn't make a difference. > > On Tue, May 17, 2016 at 9:05 AM, chris english < > englishchristophera at 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 < >> englishchristophera at 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.2 Rcpp_0.12.4 grid_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 >>> > >>> Hmmmm. 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 < >>>> tech_dev at 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 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>>> > >>>>> > >>>>> > DOWNLOAD: >>>>> > _______________ >>>>> > MODISserverOrder : LPDAAC, LAADS >>>>> > dlmethod : auto >>>>> > stubbornness : 5 >>>>> > >>>>> > >>>>> > PROCESSING: >>>>> > _______________ >>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>>> > MRT : Version 4.1 (March 2011) >>>>> > pixelSize : asIn >>>>> > outProj : GEOGRAPHIC >>>>> > resamplingType : NN >>>>> > dataFormat : GTiff >>>>> > >>>>> > >>>>> > DEPENDENCIES: >>>>> > _______________ >>>>> > >>>>> >> 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* >>>>> >> sessionInfo() >>>>> > R version 3.2.5 (2016-04-14) >>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>>> > >>>>> > loaded via a namespace (and not attached): >>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >>>>> > >>>>> > >>>>> > >>>>> > __________________________________________________ >>>>> > >>>>> > Hakim Abdi | PhD Candidate >>>>> > Center for Geobiosphere Science >>>>> > >>>>> > Department of Physical Geography and Ecosystem Science >>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>>> > >>>>> > [[alternative HTML version deleted]] >>>>> > >>>>> > _______________________________________________ >>>>> > R-sig-Geo mailing list >>>>> > R-sig-Geo at r-project.org >>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>> > >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>> >>> >>> >> > [[alternative HTML version deleted]] From dncgst at gnewarchaeology.it Wed May 18 11:00:57 2016 From: dncgst at gnewarchaeology.it (Domenico Giusti) Date: Wed, 18 May 2016 11:00:57 +0200 Subject: [R-sig-Geo] R 3.3.0 - spatstat 1.45-2 - envelope -- Error in nrank%%1 : non-numeric argument to binary operator In-Reply-To: <93b393fe-19eb-e5d0-2059-614cfa428a7e@auckland.ac.nz> References: <573B041C.3040805@gnewarchaeology.it> <93b393fe-19eb-e5d0-2059-614cfa428a7e@auckland.ac.nz> Message-ID: <573C2F49.3050409@gnewarchaeology.it> Thank you! P.S. I use to type the options, to remind me what I'm doing :) On 05/17/2016 11:08 PM, Rolf Turner wrote: > On 17/05/16 23:44, Domenico Giusti wrote: >> Dear all, >> >> I get "Error in nrank%%1 : non-numeric argument to binary operator" >> running >> >>> data("amacrine") >>> E <- envelope(amacrine, Kcross, "on", "off", nsim=19, global=FALSE) >> >> Envelope works fine running >> >>> E <- alltypes(amacrine, Kcross, nsim=19, envelope=TRUE, global=FALSE) >> >> Thanks, > > Try: > > E <- envelope(amacrine, Kcross, funargs=list(i="on",j="off"), > nsim=19,global=FALSE) > > cheers, > > Rolf Turner > > P. S. Note that you *do not need* to set "global=FALSE"; this is the > default. > > R. T. > > -- Domenico Giusti GPG keyID: 2048R/A3AB7054F6E5D778 From englishchristophera at gmail.com Wed May 18 13:13:00 2016 From: englishchristophera at gmail.com (chris english) Date: Wed, 18 May 2016 14:13:00 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: 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 < englishchristophera at 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] name description 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 > wrote: > >> Same here. Loading rgdal didn't make a difference. >> >> On Tue, May 17, 2016 at 9:05 AM, chris english < >> englishchristophera at 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 < >>> englishchristophera at 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.2 Rcpp_0.12.4 grid_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 >>>> > >>>> Hmmmm. 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 < >>>>> tech_dev at 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 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>>>> > >>>>>> > >>>>>> > DOWNLOAD: >>>>>> > _______________ >>>>>> > MODISserverOrder : LPDAAC, LAADS >>>>>> > dlmethod : auto >>>>>> > stubbornness : 5 >>>>>> > >>>>>> > >>>>>> > PROCESSING: >>>>>> > _______________ >>>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>>>> > MRT : Version 4.1 (March 2011) >>>>>> > pixelSize : asIn >>>>>> > outProj : GEOGRAPHIC >>>>>> > resamplingType : NN >>>>>> > dataFormat : GTiff >>>>>> > >>>>>> > >>>>>> > DEPENDENCIES: >>>>>> > _______________ >>>>>> > >>>>>> >> 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* >>>>>> >> sessionInfo() >>>>>> > R version 3.2.5 (2016-04-14) >>>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>>>> > >>>>>> > loaded via a namespace (and not attached): >>>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >>>>>> > >>>>>> > >>>>>> > >>>>>> > __________________________________________________ >>>>>> > >>>>>> > Hakim Abdi | PhD Candidate >>>>>> > Center for Geobiosphere Science >>>>>> > >>>>>> > Department of Physical Geography and Ecosystem Science >>>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>>>> > >>>>>> > [[alternative HTML version deleted]] >>>>>> > >>>>>> > _______________________________________________ >>>>>> > R-sig-Geo mailing list >>>>>> > R-sig-Geo at r-project.org >>>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>> > >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> R-sig-Geo mailing list >>>>> R-sig-Geo at r-project.org >>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>> >>>> >>>> >>> >> > [[alternative HTML version deleted]] From englishchristophera at gmail.com Wed May 18 13:56:44 2016 From: englishchristophera at gmail.com (chris english) Date: Wed, 18 May 2016 14:56:44 +0300 Subject: [R-sig-Geo] Cran R Bagidis (semi-metric) and functional curve data Message-ID: 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]] From madiazl at gmail.com Wed May 18 18:22:27 2016 From: madiazl at gmail.com (Andres Diaz) Date: Wed, 18 May 2016 18:22:27 +0200 Subject: [R-sig-Geo] Creating a grid Message-ID: Hello everybody, I am trying to build a grid from a polygon, using the functions spsample and gridded, but it seems there is something wrong with the coordinates in longitude and latitude which not work properly. Someone have an answer? #load the packages require(SP) #countries coordinates in longitude, latitude Albaniax<-c(20.0100272335,19.8572911876,19.2897912464,19.4794450497,19.3072091765,19.5216631874,19.4425003026,19.5991632702,19.3677732887,19.2885363079,19.6515270311,19.8225000867,20.0714181366,20.5251360888,20.5896452275,20.5191631446,20.7408091636,20.9834910775,21.0420822572,20.7919272061,20.6670821107,20.3154181886,20.4133271998,20.2200001113,20.0100272335) Albaniay<-c(39.6912001762,40.0434731274,40.4214540464,40.3548539581,40.6453091998,40.9098541347,41.4069450832,41.7797181580,41.8490001200,42.1829091596,42.6231910886,42.4719361250,42.5609091892,42.2130540039,41.8821911156,41.2463821837,40.9095361253,40.8558911066,40.5640270347,40.4315450196,40.0962450871,39.9918000353,39.8201361432,39.6473542729,39.6912001762) Algeriax<-c(4.2452821739600,3.3319452420500,3.1170091041500,3.2780541307000,3.2330542070000,2.4216631785700,2.2036091403200,1.7897181364400,1.6275003139800,1.1763911453200,1.1708002482500,-4.8061089467500,-8.6667909290000,-8.6666638593500,-8.6672179031500,-7.1262549561800,-6.5833998220400,-6.4002817239600,-5.5306907830400,-4.9151368878800,-3.6222177582600,-3.6001368077500,-3.8238908754500,-3.8134728403300,-2.9994457033400,-2.8594457917000,-1.1805549395600,-1.2504179350800,-1.0118087879800,-1.3827817652700,-1.6666637508500,-1.6544457858300,-1.7933367716900,-1.6925819366500,-1.8549638767700,-1.7575998568500,-2.2094459624300,-1.3693088617100,-0.7916638001530,-0.3731268749630,-0.0522178320053,0.2041631291760,1.1825002116500,2.5725002205000,2.9002091662500,3.9016630348300,4.7887453313600,5.3280540822500,6.3983362842300,6.9204182124000,7.1705543204200,7.2297181517900,7.8766632802500,8.6220270396900,8.1816633033000,8.3763911755000,8.2605541114800,8.4011090727600,8.2527091530000,7.5288910757300,7.4925002048000,7.7430540668800,8.1577730351600,8.3486091897100,9.0572183036200,9.5371090838500,9.3113911362300,9.8397180851900,9.7902822906800,9.9558362782400,9.7344452366900,9.9305542789000,9.8716631946600,9.4994451694600,9.3983361151900,10.0320820931000,10.0544451784000,10.2522180284000,11.5588911906000,11.9864731952000,7.4637730756100,5.8125002592300,4.2452821739600) Algeriay<-c(19.1466642562000,18.9763910895000,19.1455541570000,19.4058271711000,19.8171450983000,20.0530542668000,20.2830541935000,20.3129180764000,20.5711090257000,20.7337449375000,21.1008540251000,25.0002731406000,27.2904541814000,27.6666640042000,28.7094450141000,29.6358270373000,29.5683272355000,29.8044451133000,29.9059730951000,30.5098541843000,30.9736091303000,31.0908271967000,31.1615910791000,31.6980541739000,31.8333271951000,32.0865270563000,32.1122182602000,32.3234732339000,32.5055541552000,32.7244450427000,33.2588820638000,34.0836092031000,34.3783271455000,34.4890820940000,34.6143731066000,34.7546450949000,35.0858271660000,35.3129182370000,35.7650000417000,35.9027730493000,35.8061090860000,36.1033360673000,36.5122182134000,36.5891640848000,36.7947820609000,36.9147182109000,36.8938910255000,36.6402732425000,37.0863911554000,36.8843001165000,36.9200001510000,37.0863911554000,36.8475000411000,36.9413641135000,36.5052731361000,36.4201361336000,35.8563820650000,35.1922181604000,34.6552090685000,34.1043091513000,33.8875001609000,33.2291641937000,33.0280541727000,32.5333361410000,32.0955541984000,30.2343909823000,30.1272181239000,29.1599999713000,28.2705541457000,27.8462452744000,27.3160360852000,26.8597180666000,26.5141640490000,26.3575000756000,26.1533271396000,25.3294450637000,24.8380539771000,24.6058271463000,24.3025001512000,23.5223090810000,20.8566732593000,19.4461090891000,19.1466642562000) #creating poligons Albania = Polygon(cbind(Albaniax, Albaniay)) Algeria = Polygon(cbind(Algeriax, Algeriay)) AlbaniaPol = Polygons(list(Albania), ID=as.numeric(1)) AlgeriaPol = Polygons(list(Algeria), ID=as.numeric(2)) # creating the object spatial polygon Countries = SpatialPolygons(list(AlbaniaPol,AlgeriaPol), 1:2 ,proj4string=CRS("+proj=longlat +datum=WGS84")) # here I am specifing the G.C # retriving the points from the spatial polygon Pointlocationcountries <- spsample(Countries, type="regular", cellsize=1000, offset = c(0.5, 0.5)) #here is the errror Error in .local(obj, ...) : cannot derive coordinates from non-numeric matrix #creating the grid gridded(Pointlocationcountries)<-TRUE -- Andr?s D. [[alternative HTML version deleted]] From edzer.pebesma at uni-muenster.de Wed May 18 18:43:44 2016 From: edzer.pebesma at uni-muenster.de (Edzer Pebesma) Date: Wed, 18 May 2016 18:43:44 +0200 Subject: [R-sig-Geo] Creating a grid In-Reply-To: References: Message-ID: <573C9BC0.7000109@uni-muenster.de> On 18/05/16 18:22, Andres Diaz wrote: > Hello everybody, > > > I am trying to build a grid from a polygon, using the functions spsample > and gridded, but it seems there is something wrong with the coordinates in > longitude and latitude which not work properly. > > Someone have an answer? > > > > #load the packages > require(SP) this should be require(sp) as package names are case sensitive. > > #countries coordinates in longitude, latitude > > Albaniax<-c(20.0100272335,19.8572911876,19.2897912464,19.4794450497,19.3072091765,19.5216631874,19.4425003026,19.5991632702,19.3677732887,19.2885363079,19.6515270311,19.8225000867,20.0714181366,20.5251360888,20.5896452275,20.5191631446,20.7408091636,20.9834910775,21.0420822572,20.7919272061,20.6670821107,20.3154181886,20.4133271998,20.2200001113,20.0100272335) > Albaniay<-c(39.6912001762,40.0434731274,40.4214540464,40.3548539581,40.6453091998,40.9098541347,41.4069450832,41.7797181580,41.8490001200,42.1829091596,42.6231910886,42.4719361250,42.5609091892,42.2130540039,41.8821911156,41.2463821837,40.9095361253,40.8558911066,40.5640270347,40.4315450196,40.0962450871,39.9918000353,39.8201361432,39.6473542729,39.6912001762) > > Algeriax<-c(4.2452821739600,3.3319452420500,3.1170091041500,3.2780541307000,3.2330542070000,2.4216631785700,2.2036091403200,1.7897181364400,1.6275003139800,1.1763911453200,1.1708002482500,-4.8061089467500,-8.6667909290000,-8.6666638593500,-8.6672179031500,-7.1262549561800,-6.5833998220400,-6.4002817239600,-5.5306907830400,-4.9151368878800,-3.6222177582600,-3.6001368077500,-3.8238908754500,-3.8134728403300,-2.9994457033400,-2.8594457917000,-1.1805549395600,-1.2504179350800,-1.0118087879800,-1.3827817652700,-1.6666637508500,-1.6544457858300,-1.7933367716900,-1.6925819366500,-1.8549638767700,-1.7575998568500,-2.2094459624300,-1.3693088617100,-0.7916638001530,-0.3731268749630,-0.0522178320053,0.2041631291760,1.1825002116500,2.5725002205000,2.9002091662500,3.9016630348300,4.7887453313600,5.3280540822500,6.3983362842300,6.9204182124000,7.1705543204200,7.2297181517900,7.8766632802500,8.6220270396900,8.1816633033000,8.3763911755000,8.2605541114800,8.4011090727600,8.2527091530000,7.528891075 7300,7.4925002048000,7.7430540668800,8.1577730351600,8.3486091897100,9.0572183036200,9.5371090838500,9.3113911362300,9.8397180851900,9.7902822906800,9.9558362782400,9.7344452366900,9.9305542789000,9.8716631946600,9.4994451694600,9.3983361151900,10.0320820931000,10.0544451784000,10.2522180284000,11.5588911906000,11.9864731952000,7.4637730756100,5.8125002592300,4.2452821739600) > > Algeriay<-c(19.1466642562000,18.9763910895000,19.1455541570000,19.4058271711000,19.8171450983000,20.0530542668000,20.2830541935000,20.3129180764000,20.5711090257000,20.7337449375000,21.1008540251000,25.0002731406000,27.2904541814000,27.6666640042000,28.7094450141000,29.6358270373000,29.5683272355000,29.8044451133000,29.9059730951000,30.5098541843000,30.9736091303000,31.0908271967000,31.1615910791000,31.6980541739000,31.8333271951000,32.0865270563000,32.1122182602000,32.3234732339000,32.5055541552000,32.7244450427000,33.2588820638000,34.0836092031000,34.3783271455000,34.4890820940000,34.6143731066000,34.7546450949000,35.0858271660000,35.3129182370000,35.7650000417000,35.9027730493000,35.8061090860000,36.1033360673000,36.5122182134000,36.5891640848000,36.7947820609000,36.9147182109000,36.8938910255000,36.6402732425000,37.0863911554000,36.8843001165000,36.9200001510000,37.0863911554000,36.8475000411000,36.9413641135000,36.5052731361000,36.4201361336000,35.8563820650000,35.1922181604000 ,34.6552090685000,34.1043091513000,33.8875001609000,33.2291641937000,33.0280541727000,32.5333361410000,32.0955541984000,30.2343909823000,30.1272181239000,29.1599999713000,28.2705541457000,27.8462452744000,27.3160360852000,26.8597180666000,26.5141640490000,26.3575000756000,26.1533271396000,25.3294450637000,24.8380539771000,24.6058271463000,24.3025001512000,23.5223090810000,20.8566732593000,19.4461090891000,19.1466642562000) > > #creating poligons > Albania = Polygon(cbind(Albaniax, Albaniay)) > Algeria = Polygon(cbind(Algeriax, Algeriay)) > > AlbaniaPol = Polygons(list(Albania), ID=as.numeric(1)) > AlgeriaPol = Polygons(list(Algeria), ID=as.numeric(2)) > > > > # creating the object spatial polygon > > Countries = SpatialPolygons(list(AlbaniaPol,AlgeriaPol), 1:2 > ,proj4string=CRS("+proj=longlat +datum=WGS84")) # here I am specifing the > G.C > > > # retriving the points from the spatial polygon > > Pointlocationcountries <- spsample(Countries, type="regular", > cellsize=1000, offset = c(0.5, 0.5)) > > #here is the errror > Error in .local(obj, ...) : > cannot derive coordinates from non-numeric matrix Although I admit that the error message is far from helpful, you're making a wrong assumption here: you assume cellsize can be in metres, where the polygon in question has coordinates in degrees long/lat. You can do two things: 1. define a meaningful cell size in degrees, e.g. cellsize = 0.1 2. project the polygon using spTransform to a reference system where the units of coordinates are in metres, and then use cellsize = 1000 > > > > #creating the grid > > gridded(Pointlocationcountries)<-TRUE > > > -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From kmb56 at berkeley.edu Wed May 18 19:08:21 2016 From: kmb56 at berkeley.edu (Kenny Bell) Date: Wed, 18 May 2016 10:08:21 -0700 Subject: [R-sig-Geo] gBuffer solution to invalid objects problem fails Message-ID: Hi all, I have been getting the below error a few times. I have seen in several places that a zero-width gBuffer call will fix the topology problem. However, in this case, I find that the call to gBuffer generates a 4 point horizontal line, not solving the problem. Is there another solution? Thanks for any help! My code: library(sp) library(rgeos) load("r-sig-geo.RData") gIntersection(grid_poly, new_poly, byid = c(TRUE, FALSE), id = as.character(grid_poly at data[,1]), # if there are coinciding lines, gIntersection # returns a cross. drop_lower_td = TRUE, checkValidity = TRUE) # new_poly is invalid # Error in rgeos::gIntersection(grid_poly, new_poly, byid = c(TRUE, FALSE), : # Invalid objects found # In addition: Warning message: # In RGEOSUnaryPredFunc(spgeom, byid, "rgeos_isvalid") : # Self-intersection at or near point 172.23206269997971 -42.13157792003453 # Try using gBuffer as suggested here: # http://gis.stackexchange.com/questions/163445/r-solution-for-topologyexception-input-geom-1-is-invalid-self-intersection-er new_poly1 <- gBuffer(new_poly, width = 0) plot(new_poly1) # Generates a line (i.e. kills the polygon)? ? r-sig-geo.RData ? [[alternative HTML version deleted]] From englishchristophera at gmail.com Thu May 19 06:10:54 2016 From: englishchristophera at gmail.com (chris english) Date: Thu, 19 May 2016 07:10:54 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: 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 < englishchristophera at 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 < > englishchristophera at 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] name description 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 >> wrote: >> >>> Same here. Loading rgdal didn't make a difference. >>> >>> On Tue, May 17, 2016 at 9:05 AM, chris english < >>> englishchristophera at 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 < >>>> englishchristophera at 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.2 Rcpp_0.12.4 >>>>> grid_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 >>>>> > >>>>> Hmmmm. 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 < >>>>>> tech_dev at 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 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>>>>> > >>>>>>> > >>>>>>> > DOWNLOAD: >>>>>>> > _______________ >>>>>>> > MODISserverOrder : LPDAAC, LAADS >>>>>>> > dlmethod : auto >>>>>>> > stubbornness : 5 >>>>>>> > >>>>>>> > >>>>>>> > PROCESSING: >>>>>>> > _______________ >>>>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>>>>> > MRT : Version 4.1 (March 2011) >>>>>>> > pixelSize : asIn >>>>>>> > outProj : GEOGRAPHIC >>>>>>> > resamplingType : NN >>>>>>> > dataFormat : GTiff >>>>>>> > >>>>>>> > >>>>>>> > DEPENDENCIES: >>>>>>> > _______________ >>>>>>> > >>>>>>> >> 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* >>>>>>> >> sessionInfo() >>>>>>> > R version 3.2.5 (2016-04-14) >>>>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>>>>> > >>>>>>> > loaded via a namespace (and not attached): >>>>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 lattice_0.20-33 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > __________________________________________________ >>>>>>> > >>>>>>> > Hakim Abdi | PhD Candidate >>>>>>> > Center for Geobiosphere Science >>>>>>> > >>>>>>> > Department of Physical Geography and Ecosystem Science >>>>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>>>>> > >>>>>>> > [[alternative HTML version deleted]] >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > R-sig-Geo mailing list >>>>>>> > R-sig-Geo at r-project.org >>>>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> R-sig-Geo mailing list >>>>>> R-sig-Geo at r-project.org >>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>> >>>>> >>>>> >>>> >>> >> > [[alternative HTML version deleted]] From roman.lustrik at gmail.com Thu May 19 09:28:25 2016 From: roman.lustrik at gmail.com (=?UTF-8?Q?Roman_Lu=C5=A1trik?=) Date: Thu, 19 May 2016 09:28:25 +0200 Subject: [R-sig-Geo] gBuffer solution to invalid objects problem fails In-Reply-To: References: Message-ID: Hi Kenny, can you provide a small, reproducible example which replicates this behavior? Cheers, Roman On Wed, May 18, 2016 at 7:08 PM, Kenny Bell wrote: > Hi all, > > I have been getting the below error a few times. I have seen in several > places that a zero-width gBuffer call will fix the topology problem. > However, in this case, I find that the call to gBuffer generates a 4 point > horizontal line, not solving the problem. Is there another solution? Thanks > for any help! > > My code: > > library(sp) > library(rgeos) > load("r-sig-geo.RData") > > gIntersection(grid_poly, new_poly, > byid = c(TRUE, FALSE), > id = as.character(grid_poly at data[,1]), > # if there are coinciding lines, gIntersection > # returns a cross. > drop_lower_td = TRUE, > checkValidity = TRUE) > # new_poly is invalid > # Error in rgeos::gIntersection(grid_poly, new_poly, byid = c(TRUE, FALSE), > : > # Invalid objects found > # In addition: Warning message: > # In RGEOSUnaryPredFunc(spgeom, byid, > "rgeos_isvalid") : > # Self-intersection at or near point > 172.23206269997971 -42.13157792003453 > > # Try using gBuffer as suggested here: > # > > http://gis.stackexchange.com/questions/163445/r-solution-for-topologyexception-input-geom-1-is-invalid-self-intersection-er > > new_poly1 <- gBuffer(new_poly, width = 0) > plot(new_poly1) > # Generates a line (i.e. kills the polygon)? > ? > r-sig-geo.RData > > ? > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- In God we trust, all others bring data. [[alternative HTML version deleted]] From englishchristophera at gmail.com Thu May 19 12:31:00 2016 From: englishchristophera at gmail.com (chris english) Date: Thu, 19 May 2016 13:31:00 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: 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 TRUE FALSE 51 HDF4Image HDF4 Dataset TRUE FALSE FALSE 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 < englishchristophera at 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 < > englishchristophera at 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 < >> englishchristophera at 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] name description 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 >>> wrote: >>> >>>> Same here. Loading rgdal didn't make a difference. >>>> >>>> On Tue, May 17, 2016 at 9:05 AM, chris english < >>>> englishchristophera at 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 < >>>>> englishchristophera at 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.2 Rcpp_0.12.4 >>>>>> grid_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 >>>>>> > >>>>>> Hmmmm. 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 < >>>>>>> tech_dev at 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 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>>>>>> > >>>>>>>> > >>>>>>>> > DOWNLOAD: >>>>>>>> > _______________ >>>>>>>> > MODISserverOrder : LPDAAC, LAADS >>>>>>>> > dlmethod : auto >>>>>>>> > stubbornness : 5 >>>>>>>> > >>>>>>>> > >>>>>>>> > PROCESSING: >>>>>>>> > _______________ >>>>>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>>>>>> > MRT : Version 4.1 (March 2011) >>>>>>>> > pixelSize : asIn >>>>>>>> > outProj : GEOGRAPHIC >>>>>>>> > resamplingType : NN >>>>>>>> > dataFormat : GTiff >>>>>>>> > >>>>>>>> > >>>>>>>> > DEPENDENCIES: >>>>>>>> > _______________ >>>>>>>> > >>>>>>>> >> 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* >>>>>>>> >> sessionInfo() >>>>>>>> > R version 3.2.5 (2016-04-14) >>>>>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>>>>>> > >>>>>>>> > loaded via a namespace (and not attached): >>>>>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 >>>>>>>> lattice_0.20-33 >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > __________________________________________________ >>>>>>>> > >>>>>>>> > Hakim Abdi | PhD Candidate >>>>>>>> > Center for Geobiosphere Science >>>>>>>> > >>>>>>>> > Department of Physical Geography and Ecosystem Science >>>>>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>>>>>> > >>>>>>>> > [[alternative HTML version deleted]] >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > R-sig-Geo mailing list >>>>>>>> > R-sig-Geo at r-project.org >>>>>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> R-sig-Geo mailing list >>>>>>> R-sig-Geo at r-project.org >>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > [[alternative HTML version deleted]] From Roger.Bivand at nhh.no Thu May 19 21:02:20 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Thu, 19 May 2016 21:02:20 +0200 Subject: [R-sig-Geo] gBuffer solution to invalid objects problem fails In-Reply-To: References: Message-ID: There is an example in the message, but Kenny is ignoring the message from gBuffer: Warning message: In gBuffer(new_poly, width = 0) : Spatial object is not projected; GEOS expects planar coordinates and the differences in geographical coordinates are small. The warning is given for a reason. Intersection is projection-agnostic, but buffer is not. I don't know whether this is the reason. Roger On Thu, 19 May 2016, Roman Lu?trik wrote: > Hi Kenny, > > can you provide a small, reproducible example which replicates this > behavior? > > Cheers, > Roman > > On Wed, May 18, 2016 at 7:08 PM, Kenny Bell wrote: > >> Hi all, >> >> I have been getting the below error a few times. I have seen in several >> places that a zero-width gBuffer call will fix the topology problem. >> However, in this case, I find that the call to gBuffer generates a 4 point >> horizontal line, not solving the problem. Is there another solution? Thanks >> for any help! >> >> My code: >> >> library(sp) >> library(rgeos) >> load("r-sig-geo.RData") >> >> gIntersection(grid_poly, new_poly, >> byid = c(TRUE, FALSE), >> id = as.character(grid_poly at data[,1]), >> # if there are coinciding lines, gIntersection >> # returns a cross. >> drop_lower_td = TRUE, >> checkValidity = TRUE) >> # new_poly is invalid >> # Error in rgeos::gIntersection(grid_poly, new_poly, byid = c(TRUE, FALSE), >> : >> # Invalid objects found >> # In addition: Warning message: >> # In RGEOSUnaryPredFunc(spgeom, byid, >> "rgeos_isvalid") : >> # Self-intersection at or near point >> 172.23206269997971 -42.13157792003453 >> >> # Try using gBuffer as suggested here: >> # >> >> http://gis.stackexchange.com/questions/163445/r-solution-for-topologyexception-input-geom-1-is-invalid-self-intersection-er >> >> new_poly1 <- gBuffer(new_poly, width = 0) >> plot(new_poly1) >> # Generates a line (i.e. kills the polygon)? >> ? >> r-sig-geo.RData >> >> ? >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > > > > -- > In God we trust, all others bring data. > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From kmb56 at berkeley.edu Thu May 19 21:55:45 2016 From: kmb56 at berkeley.edu (Kenny Bell) Date: Thu, 19 May 2016 12:55:45 -0700 Subject: [R-sig-Geo] gBuffer solution to invalid objects problem fails In-Reply-To: References: Message-ID: Great, this works: new_poly <- sp::spTransform(new_poly, "+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +units=m +no_defs") grid_poly <- sp::spTransform(grid_poly, "+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +units=m +no_defs") new_poly1 <- gBuffer(new_poly, width = 0) plot(new_poly1) # Works gIntersection(grid_poly, new_poly1, byid = c(TRUE, FALSE), id = as.character(grid_poly at data[,1]), # if there are coinciding lines, gIntersection # returns a cross. drop_lower_td = TRUE, checkValidity = TRUE) Thanks so much Roger! On Thu, May 19, 2016 at 12:02 PM, Roger Bivand wrote: > There is an example in the message, but Kenny is ignoring the message from > gBuffer: > > Warning message: > In gBuffer(new_poly, width = 0) : > Spatial object is not projected; GEOS expects planar coordinates > > and the differences in geographical coordinates are small. The warning is > given for a reason. Intersection is projection-agnostic, but buffer is not. > I don't know whether this is the reason. > > Roger > > > > On Thu, 19 May 2016, Roman Lu?trik wrote: > > Hi Kenny, >> >> can you provide a small, reproducible example which replicates this >> behavior? >> >> Cheers, >> Roman >> >> On Wed, May 18, 2016 at 7:08 PM, Kenny Bell wrote: >> >> Hi all, >>> >>> I have been getting the below error a few times. I have seen in several >>> places that a zero-width gBuffer call will fix the topology problem. >>> However, in this case, I find that the call to gBuffer generates a 4 >>> point >>> horizontal line, not solving the problem. Is there another solution? >>> Thanks >>> for any help! >>> >>> My code: >>> >>> library(sp) >>> library(rgeos) >>> load("r-sig-geo.RData") >>> >>> gIntersection(grid_poly, new_poly, >>> byid = c(TRUE, FALSE), >>> id = as.character(grid_poly at data[,1]), >>> # if there are coinciding lines, gIntersection >>> # returns a cross. >>> drop_lower_td = TRUE, >>> checkValidity = TRUE) >>> # new_poly is invalid >>> # Error in rgeos::gIntersection(grid_poly, new_poly, byid = c(TRUE, >>> FALSE), >>> : >>> # Invalid objects found >>> # In addition: Warning message: >>> # In RGEOSUnaryPredFunc(spgeom, byid, >>> "rgeos_isvalid") : >>> # Self-intersection at or near point >>> 172.23206269997971 -42.13157792003453 >>> >>> # Try using gBuffer as suggested here: >>> # >>> >>> >>> http://gis.stackexchange.com/questions/163445/r-solution-for-topologyexception-input-geom-1-is-invalid-self-intersection-er >>> >>> new_poly1 <- gBuffer(new_poly, width = 0) >>> plot(new_poly1) >>> # Generates a line (i.e. kills the polygon)? >>> ? >>> r-sig-geo.RData >>> >>> ? >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> >> >> >> >> >> -- >> In God we trust, all others bring data. >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at 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.Bivand at nhh.no > http://orcid.org/0000-0003-2392-6140 > https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en > http://depsy.org/person/434412 -- Kendon Bell Email: kmb56 at berkeley.edu Phone: (510) 612-3375 Ph.D. Candidate Department of Agricultural & Resource Economics University of California, Berkeley [[alternative HTML version deleted]] From nickeubank at gmail.com Thu May 19 22:41:57 2016 From: nickeubank at gmail.com (Nick Eubank) Date: Thu, 19 May 2016 20:41:57 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset Message-ID: Hi All, Trying to an equivalent to the "nearest" tool in ArcGIS for two SpatialPointDataFrames. I can do the naive implementation by calculating all pairwise distances using gDistance and taking the min, but I have some huge datasets and was looking for something more efficient. (For example, here's a trick with knearneigh for points in same dataset ( http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r )). Any suggestions? Thanks! Nick [[alternative HTML version deleted]] From mdsumner at gmail.com Thu May 19 23:59:21 2016 From: mdsumner at gmail.com (Michael Sumner) Date: Thu, 19 May 2016 21:59:21 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: Use nabor package, it takes a little to learn but is crazy fast. Happy to show if you make a relevant example. Mike On Fri, May 20, 2016, 06:42 Nick Eubank wrote: > Hi All, > > Trying to an equivalent to the "nearest" tool in ArcGIS for two > SpatialPointDataFrames. I can do the naive implementation by calculating > all pairwise distances using gDistance and taking the min, but I have some > huge datasets and was looking for something more efficient. (For example, > here's a trick with knearneigh for points in same dataset ( > > http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r > )). > > Any suggestions? > > Thanks! > > Nick > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] From nickeubank at gmail.com Fri May 20 00:03:26 2016 From: nickeubank at gmail.com (Nick Eubank) Date: Thu, 19 May 2016 22:03:26 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: Thanks Michael! Super easy context: two SpatialPointsDataFrames ("voters", "polling.places"). Each has coordinate columns "x" and "y". Is it just: library(nabor) knn(voters, query = polling.places, k=1) ? On Thu, May 19, 2016 at 2:59 PM Michael Sumner wrote: > Use nabor package, it takes a little to learn but is crazy fast. > > Happy to show if you make a relevant example. > Mike > > On Fri, May 20, 2016, 06:42 Nick Eubank wrote: > >> Hi All, >> >> Trying to an equivalent to the "nearest" tool in ArcGIS for two >> SpatialPointDataFrames. I can do the naive implementation by calculating >> all pairwise distances using gDistance and taking the min, but I have some >> huge datasets and was looking for something more efficient. (For example, >> here's a trick with knearneigh for points in same dataset ( >> >> http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r >> )). >> >> Any suggestions? >> >> Thanks! >> >> Nick >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > -- > Dr. Michael Sumner > Software and Database Engineer > Australian Antarctic Division > 203 Channel Highway > Kingston Tasmania 7050 Australia > > [[alternative HTML version deleted]] From nickeubank at gmail.com Fri May 20 00:38:12 2016 From: nickeubank at gmail.com (Nick Eubank) Date: Thu, 19 May 2016 22:38:12 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: For other's reference, that was almost right: To get distance from each voter to closest polling place, the syntax was: knn.results = knn(data=coordinates(polling.places), query=coordinates(voters), k=1) On Thu, May 19, 2016 at 3:03 PM Nick Eubank wrote: > Thanks Michael! > > Super easy context: two SpatialPointsDataFrames ("voters", > "polling.places"). Each has coordinate columns "x" and "y". > > Is it just: > > library(nabor) > knn(voters, query = polling.places, k=1) > > ? > > On Thu, May 19, 2016 at 2:59 PM Michael Sumner wrote: > >> Use nabor package, it takes a little to learn but is crazy fast. >> >> Happy to show if you make a relevant example. >> Mike >> >> On Fri, May 20, 2016, 06:42 Nick Eubank wrote: >> >>> Hi All, >>> >>> Trying to an equivalent to the "nearest" tool in ArcGIS for two >>> SpatialPointDataFrames. I can do the naive implementation by calculating >>> all pairwise distances using gDistance and taking the min, but I have >>> some >>> huge datasets and was looking for something more efficient. (For example, >>> here's a trick with knearneigh for points in same dataset ( >>> >>> http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r >>> )). >>> >>> Any suggestions? >>> >>> Thanks! >>> >>> Nick >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>> >> -- >> Dr. Michael Sumner >> Software and Database Engineer >> Australian Antarctic Division >> 203 Channel Highway >> Kingston Tasmania 7050 Australia >> >> [[alternative HTML version deleted]] From nickeubank at gmail.com Fri May 20 00:48:20 2016 From: nickeubank at gmail.com (Nick Eubank) Date: Thu, 19 May 2016 22:48:20 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: Last note for future searchers: also suggested was the SearchTree library: http://stackoverflow.com/questions/37333747/for-each-point-distance-to-nearest-point-in-second-dataset-in-r On Thu, May 19, 2016 at 3:38 PM Nick Eubank wrote: > For other's reference, that was almost right: > > To get distance from each voter to closest polling place, the syntax was: > > knn.results = knn(data=coordinates(polling.places), > query=coordinates(voters), k=1) > > > > On Thu, May 19, 2016 at 3:03 PM Nick Eubank wrote: > >> Thanks Michael! >> >> Super easy context: two SpatialPointsDataFrames ("voters", >> "polling.places"). Each has coordinate columns "x" and "y". >> >> Is it just: >> >> library(nabor) >> knn(voters, query = polling.places, k=1) >> >> ? >> >> On Thu, May 19, 2016 at 2:59 PM Michael Sumner >> wrote: >> >>> Use nabor package, it takes a little to learn but is crazy fast. >>> >>> Happy to show if you make a relevant example. >>> Mike >>> >>> On Fri, May 20, 2016, 06:42 Nick Eubank wrote: >>> >>>> Hi All, >>>> >>>> Trying to an equivalent to the "nearest" tool in ArcGIS for two >>>> SpatialPointDataFrames. I can do the naive implementation by calculating >>>> all pairwise distances using gDistance and taking the min, but I have >>>> some >>>> huge datasets and was looking for something more efficient. (For >>>> example, >>>> here's a trick with knearneigh for points in same dataset ( >>>> >>>> http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r >>>> )). >>>> >>>> Any suggestions? >>>> >>>> Thanks! >>>> >>>> Nick >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>> >>> -- >>> Dr. Michael Sumner >>> Software and Database Engineer >>> Australian Antarctic Division >>> 203 Channel Highway >>> Kingston Tasmania 7050 Australia >>> >>> [[alternative HTML version deleted]] From mdsumner at gmail.com Fri May 20 03:37:42 2016 From: mdsumner at gmail.com (Michael Sumner) Date: Fri, 20 May 2016 01:37:42 +0000 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: On Fri, 20 May 2016 at 08:38 Nick Eubank wrote: > For other's reference, that was almost right: > > To get distance from each voter to closest polling place, the syntax was: > > knn.results = knn(data=coordinates(polling.places), > query=coordinates(voters), k=1) > > > Great! Be sure to use the WKNNF approach to cache the kdtree of the data - it only needs to be done once, but calls to knn obviously will redo that part. Also, you'll probably want to do it with coordinates in a map projection where nearest-neighbour distance makes sense for your domain. Cheers, Mike. > On Thu, May 19, 2016 at 3:03 PM Nick Eubank wrote: > >> Thanks Michael! >> >> Super easy context: two SpatialPointsDataFrames ("voters", >> "polling.places"). Each has coordinate columns "x" and "y". >> >> Is it just: >> >> library(nabor) >> knn(voters, query = polling.places, k=1) >> >> ? >> >> On Thu, May 19, 2016 at 2:59 PM Michael Sumner >> wrote: >> >>> Use nabor package, it takes a little to learn but is crazy fast. >>> >>> Happy to show if you make a relevant example. >>> Mike >>> >>> On Fri, May 20, 2016, 06:42 Nick Eubank wrote: >>> >>>> Hi All, >>>> >>>> Trying to an equivalent to the "nearest" tool in ArcGIS for two >>>> SpatialPointDataFrames. I can do the naive implementation by calculating >>>> all pairwise distances using gDistance and taking the min, but I have >>>> some >>>> huge datasets and was looking for something more efficient. (For >>>> example, >>>> here's a trick with knearneigh for points in same dataset ( >>>> >>>> http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r >>>> )). >>>> >>>> Any suggestions? >>>> >>>> Thanks! >>>> >>>> Nick >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>> >>> -- >>> Dr. Michael Sumner >>> Software and Database Engineer >>> Australian Antarctic Division >>> 203 Channel Highway >>> Kingston Tasmania 7050 Australia >>> >>> -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] From Andy.Bunn at wwu.edu Fri May 20 05:41:29 2016 From: Andy.Bunn at wwu.edu (Andy Bunn) Date: Fri, 20 May 2016 03:41:29 +0000 Subject: [R-sig-Geo] extracting centroids from map data Message-ID: Hello all, I'm working on a map. I'd like to extract centroids of the counties below in order to plot them as points. How can I do this? Many thanks, Andy ~~~~ library(ggplot2) library(maps) all_states <- map_data("county") states <- subset(all_states, region %in% c("iowa", "illinois", "indiana", "michigan", "minnesota","ohio", "wisconsin")) p <- ggplot() p <- p + geom_polygon( data=states, aes(x=long, y=lat, group = group), color="grey10", fill="white" ) p <- p + theme(aspect.ratio=1) p [[alternative HTML version deleted]] From bfalevlist at gmail.com Fri May 20 06:48:38 2016 From: bfalevlist at gmail.com (=?UTF-8?Q?Bede-Fazekas_=c3=81kos?=) Date: Fri, 20 May 2016 06:48:38 +0200 Subject: [R-sig-Geo] extracting centroids from map data In-Reply-To: References: Message-ID: <38141c4e-17ac-8368-f266-1a04478de779@gmail.com> Hello Andy, you'll need these: library(rgeos) centroids <- gCentroid(states, byid=TRUE, id = NULL) after you convert your data.frame to SpatialPolygons or SpatialPolygonsDataFrame (package sp). HTH, ?kos 2016.05.20. 5:41 keltez?ssel, Andy Bunn ?rta: > Hello all, I'm working on a map. I'd like to extract centroids of the counties below in order to plot them as points. How can I do this? > > Many thanks, Andy > > ~~~~ > > library(ggplot2) > library(maps) > all_states <- map_data("county") > states <- subset(all_states, region %in% c("iowa", "illinois", "indiana", > "michigan", "minnesota","ohio", > "wisconsin")) > p <- ggplot() > p <- p + geom_polygon( data=states, aes(x=long, y=lat, group = group), > color="grey10", fill="white" ) > p <- p + theme(aspect.ratio=1) > p > > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > From kaushikjana11 at gmail.com Fri May 20 09:21:06 2016 From: kaushikjana11 at gmail.com (Kaushik Jana) Date: Fri, 20 May 2016 12:51:06 +0530 Subject: [R-sig-Geo] Drawing spokes from a fixed point to the boundary of a polygon and take the maximum cut point Message-ID: Hello everyone, I am working with spatial polygon and using SP and RGEOS package. I am having problem to find the maximum-distance intersect points with spokes (drawn from a kind of centroid) and the polygon boundary. Thanks, Kaushik *Here is the details steps:* Consider a 2-D polygon (with no holes) with the vertices > X= x y [1,] -13.07387755 6.752311920 [2,] -9.33770907 5.067708782 [3,] -7.49002198 9.665618999 [4,] -3.75490263 7.978791961 [5,] -0.02026076 6.289741026 [6,] -1.86977386 1.692942758 [7,] 1.86397021 0.001667924 [8,] 5.60020191 -1.689606910 [9,] 9.33298897 -3.380881745 [10,] 11.18475614 1.213692624 [11,] 14.91650047 -0.479806108 [12,] 13.06430891 -5.074380477 [13,] 11.21735861 -9.665618999 [14,] 7.48745370 -7.974344164 [15,] 3.75607922 -6.283069330 [16,] 0.02026968 -4.591794496 [17,] -3.71404150 -2.901631611 [18,] -7.44784360 -1.213692624 [19,] -11.18014866 0.472022464 [20,] -14.91491149 2.155513653 [21,] -13.07387755 6.752311920 Consider a point (centre of the convex hull of X): >cent_0=c(0.4315245,0.3889576) I am drawing equi-angled (around 360 degree of the centre) spokes from the above centre to the vertices of the polygon. *Here is my R-code to draw the spokes:* >n=50 # Number of equi angled spokes from center >xcent = cent_0[1] >ycent = cent_0[2] >cent = sp::SpatialPoints(cbind(xcent, ycent)) >pts = sp::SpatialPoints(X) ## take the furthest distance from centre to vertex, times two! >r = 2 * max(sp::spDistsN1(pts, cent)) >theta=seq(0,2*pi,length=n+1)[-(n+1)] ## construct a big wheel of spoke lines >sl = sp::SpatialLines(lapply(1:length(theta),function(id){ >t = theta[id] >sp::Lines(list(sp::Line(rbind(c(xcent, ycent),c(xcent + r * cos(t),ycent + r * sin(t))))),ID=id)})) ## construct the polygon as a SpatialPolygons object: >pol=sp::SpatialPolygons(list(sp::Polygons(list(sp::Polygon(rbind(xy,xy[1,]))),ID=1))) ## overlay spokes on polygon as "SpatialLines" so we do line-on-line ## intersect which gets us points >spokes = rgeos::gIntersection(sl, as(pol,"SpatialLines"), byid=TRUE) >spokes I want to have the maximum-distance intersect points with the spokes and the polygon boundary. If a spoke (corresponding to a specific angle) don't intersect the boundary of the polygon then we take the intersect point as the centre itself for that angle. So finally I want to have *n *boundary points on the (one for each angle) polygon which obtained from the above scheme. Stuck here in doing this. Any suggestions!! [[alternative HTML version deleted]] From dtnava at hotmail.com Fri May 20 14:53:17 2016 From: dtnava at hotmail.com (Daniela Nava) Date: Fri, 20 May 2016 09:53:17 -0300 Subject: [R-sig-Geo] spatial data with binomial distribution Message-ID: Hello,I'm trying to simulate a grid with binomial distribution spacially dependent. For the normal distribution, the package geoR has the command grf(). Has anyone some ideia how can I do this?Thanks a lot, Daniela. Daniela Trentin Nava Msc. em Estat?stica pela UFPE Professora da UTFPR - Campus Toledo Email alternativo: dnava at utfpr.edu.br Hapiness is a decision. You are as happy as you decide to be. [[alternative HTML version deleted]] From thierry.onkelinx at inbo.be Fri May 20 15:04:50 2016 From: thierry.onkelinx at inbo.be (Thierry Onkelinx) Date: Fri, 20 May 2016 15:04:50 +0200 Subject: [R-sig-Geo] spatial data with binomial distribution In-Reply-To: References: Message-ID: Dear Daniela, You could first generate a grid with the mean proportion on the logit scale. You can use grf() to do that since the mean in the logit scale is linear like the normal distribution. In step 2 you backtransform from the logit scale to the original scale. E.g. with plogis(). Step 3 generates binomial values based on the proportions from step 2. E.g. with rbinom(). Best regards, ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey 2016-05-20 14:53 GMT+02:00 Daniela Nava : > Hello,I'm trying to simulate a grid with binomial distribution spacially > dependent. For the normal distribution, the package geoR has the command > grf(). Has anyone some ideia how can I do this?Thanks a lot, Daniela. > > > > Daniela Trentin Nava > Msc. em Estat?stica pela UFPE > Professora da UTFPR - Campus Toledo > Email alternativo: dnava at utfpr.edu.br > > Hapiness is a decision. You are as happy as you decide to be. > > [[alternative HTML version deleted]] > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From cryan at binghamton.edu Fri May 20 01:11:09 2016 From: cryan at binghamton.edu (Christopher W Ryan) Date: Thu, 19 May 2016 19:11:09 -0400 Subject: [R-sig-Geo] For each point, distance to nearest point in second dataset In-Reply-To: References: Message-ID: See also the spatstat package, and its nncross function. --Chris Ryan On Thu, May 19, 2016 at 6:48 PM, Nick Eubank wrote: > Last note for future searchers: also suggested was the SearchTree library: > http://stackoverflow.com/questions/37333747/for-each-point-distance-to-nearest-point-in-second-dataset-in-r > > > > On Thu, May 19, 2016 at 3:38 PM Nick Eubank wrote: > >> For other's reference, that was almost right: >> >> To get distance from each voter to closest polling place, the syntax was: >> >> knn.results = knn(data=coordinates(polling.places), >> query=coordinates(voters), k=1) >> >> >> >> On Thu, May 19, 2016 at 3:03 PM Nick Eubank wrote: >> >>> Thanks Michael! >>> >>> Super easy context: two SpatialPointsDataFrames ("voters", >>> "polling.places"). Each has coordinate columns "x" and "y". >>> >>> Is it just: >>> >>> library(nabor) >>> knn(voters, query = polling.places, k=1) >>> >>> ? >>> >>> On Thu, May 19, 2016 at 2:59 PM Michael Sumner >>> wrote: >>> >>>> Use nabor package, it takes a little to learn but is crazy fast. >>>> >>>> Happy to show if you make a relevant example. >>>> Mike >>>> >>>> On Fri, May 20, 2016, 06:42 Nick Eubank wrote: >>>> >>>>> Hi All, >>>>> >>>>> Trying to an equivalent to the "nearest" tool in ArcGIS for two >>>>> SpatialPointDataFrames. I can do the naive implementation by calculating >>>>> all pairwise distances using gDistance and taking the min, but I have >>>>> some >>>>> huge datasets and was looking for something more efficient. (For >>>>> example, >>>>> here's a trick with knearneigh for points in same dataset ( >>>>> >>>>> http://gis.stackexchange.com/questions/132384/distance-to-nearest-point-for-every-point-same-spatialpointsdataframe-in-r >>>>> )). >>>>> >>>>> Any suggestions? >>>>> >>>>> Thanks! >>>>> >>>>> Nick >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> _______________________________________________ >>>>> R-sig-Geo mailing list >>>>> R-sig-Geo at r-project.org >>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>> >>>> -- >>>> Dr. Michael Sumner >>>> Software and Database Engineer >>>> Australian Antarctic Division >>>> 203 Channel Highway >>>> Kingston Tasmania 7050 Australia >>>> >>>> > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo From thi_veloso at yahoo.com.br Sat May 21 22:02:23 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Sat, 21 May 2016 20:02:23 +0000 (UTC) Subject: [R-sig-Geo] Run focal function on a multi-layer raster References: <2134943069.304803.1463860943622.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <2134943069.304803.1463860943622.JavaMail.yahoo@mail.yahoo.com> I have a multi-layer raster, in this case a rasterbrick, on which I would like to apply a focal function on each layer, and get another rasterbrick as a result. I am trying to use calc, but apparently I am not assembling my function in the proper way: require(raster) r <- raster(ncol=50, nrow=50) r[]=1:ncell(r) b <- brick(r,r,r,r,r,r) b <- b * 1:6 myfocalfun <- function(x){ b.f <- focal(x, w=matrix(1, 5, 5), mean) return(b.f) } b1 <- calc(b, myfocalfun) Error in .calcTest(x[1:5], fun, na.rm, forcefun, forceapply) : cannot use this function What am I missing here? Greetings, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota From loic.dutrieux at wur.nl Sat May 21 22:54:09 2016 From: loic.dutrieux at wur.nl (=?UTF-8?Q?Lo=c3=afc_Dutrieux?=) Date: Sat, 21 May 2016 22:54:09 +0200 Subject: [R-sig-Geo] Run focal function on a multi-layer raster In-Reply-To: <2134943069.304803.1463860943622.JavaMail.yahoo@mail.yahoo.com> References: <2134943069.304803.1463860943622.JavaMail.yahoo.ref@mail.yahoo.com> <2134943069.304803.1463860943622.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5740CAF1.4080406@wur.nl> Hi Thiago, calc is not aware of neighbouring pixels in the x,y dimensions, so functions like focal cannot work. I found the function below in an old repos of mine. It still seems to work fine :) #' Focal for RasterBrick or RasterStack #' #' @param x RasterBrick/Stack or character pointing to multilayer raster object written on disk #' @param w See \code{\link{focal}} #' @param ... Arguments to be passed to \code{\link{focal}} #' #' @import raster #' @export #' multiFocal <- function(x, w=matrix(1, nr=3, nc=3), ...) { if(is.character(x)) { x <- brick(x) } # The function to be applied to each individual layer fun <- function(ind, x, w, ...){ focal(x[[ind]], w=w, ...) } n <- seq(nlayers(x)) list <- lapply(X=n, FUN=fun, x=x, w=w, ...) out <- stack(list) return(out) } On 05/21/2016 10:02 PM, Thiago V. dos Santos via R-sig-Geo wrote: > I have a multi-layer raster, in this case a rasterbrick, on which I would like to apply a focal function on each layer, and get another rasterbrick as a result. > > I am trying to use calc, but apparently I am not assembling my function in the proper way: > > require(raster) > r <- raster(ncol=50, nrow=50) > r[]=1:ncell(r) > b <- brick(r,r,r,r,r,r) > b <- b * 1:6 > multiFocal(b, w=matrix(1, 5, 5), mean) Cheers, Lo?c > myfocalfun <- function(x){ > b.f <- focal(x, w=matrix(1, 5, 5), mean) > return(b.f) > } > > b1 <- calc(b, myfocalfun) > > Error in .calcTest(x[1:5], fun, na.rm, forcefun, forceapply) : > cannot use this function > > What am I missing here? > Greetings, > -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > From thi_veloso at yahoo.com.br Sun May 22 00:24:26 2016 From: thi_veloso at yahoo.com.br (Thiago V. dos Santos) Date: Sat, 21 May 2016 22:24:26 +0000 (UTC) Subject: [R-sig-Geo] Run focal function on a multi-layer raster In-Reply-To: <5740CAF1.4080406@wur.nl> References: <2134943069.304803.1463860943622.JavaMail.yahoo.ref@mail.yahoo.com> <2134943069.304803.1463860943622.JavaMail.yahoo@mail.yahoo.com> <5740CAF1.4080406@wur.nl> Message-ID: <1714185786.313852.1463869466417.JavaMail.yahoo@mail.yahoo.com> Hi Lo?c, Thanks for the hint - it worked like a charm! Greetings, -- Thiago V. dos Santos PhD student Land and Atmospheric Science University of Minnesota On Saturday, May 21, 2016 3:54 PM, Lo?c Dutrieux wrote: Hi Thiago, calc is not aware of neighbouring pixels in the x,y dimensions, so functions like focal cannot work. I found the function below in an old repos of mine. It still seems to work fine :) #' Focal for RasterBrick or RasterStack #' #' @param x RasterBrick/Stack or character pointing to multilayer raster object written on disk #' @param w See \code{\link{focal}} #' @param ... Arguments to be passed to \code{\link{focal}} #' #' @import raster #' @export #' multiFocal <- function(x, w=matrix(1, nr=3, nc=3), ...) { if(is.character(x)) { x <- brick(x) } # The function to be applied to each individual layer fun <- function(ind, x, w, ...){ focal(x[[ind]], w=w, ...) } n <- seq(nlayers(x)) list <- lapply(X=n, FUN=fun, x=x, w=w, ...) out <- stack(list) return(out) } On 05/21/2016 10:02 PM, Thiago V. dos Santos via R-sig-Geo wrote: > I have a multi-layer raster, in this case a rasterbrick, on which I would like to apply a focal function on each layer, and get another rasterbrick as a result. > > I am trying to use calc, but apparently I am not assembling my function in the proper way: > > require(raster) > r <- raster(ncol=50, nrow=50) > r[]=1:ncell(r) > b <- brick(r,r,r,r,r,r) > b <- b * 1:6 > multiFocal(b, w=matrix(1, 5, 5), mean) Cheers, Lo?c > myfocalfun <- function(x){ > b.f <- focal(x, w=matrix(1, 5, 5), mean) > return(b.f) > } > > b1 <- calc(b, myfocalfun) > > Error in .calcTest(x[1:5], fun, na.rm, forcefun, forceapply) : > cannot use this function > > What am I missing here? > Greetings, > -- Thiago V. dos Santos > > PhD student > Land and Atmospheric Science > University of Minnesota > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo From englishchristophera at gmail.com Sun May 22 16:38:17 2016 From: englishchristophera at gmail.com (chris english) Date: Sun, 22 May 2016 17:38:17 +0300 Subject: [R-sig-Geo] How the "gSymdifference" of rgoes package calculating the symmetric distance between two polygon In-Reply-To: References: Message-ID: 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 at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From yasmine.mohamed at Bue.edu.eg Mon May 23 15:23:44 2016 From: yasmine.mohamed at Bue.edu.eg (yasmine mohamed) Date: Mon, 23 May 2016 13:23:44 +0000 Subject: [R-sig-Geo] TSA error using packet 1 any (sp) is not TRUE Message-ID: Hello Guys, I am trying to do Trend Surface Analysis (TSA) via OLS as rainfall function of longitude and latitude. This TSA needs spatialgriddataframe which is grd. The code went fine, but the graph has the following message written inside error using packet 1 any (sp) is not TRUE Here is my Code: rain.tsm <- lm(rain~I(LON^2)+ I(LAT^2)+I(LON*LAT), data=yr757.eda) summary(rain.tsm) library(sp) gridded(grd) = TRUE # Make it a grid grd$tsm.pred <- predict(rain.tsm, grd) pts <- list('sp.points', yr757.eda, pch=1, cex=0.7, col='black') spplot(grd, zcol='tsm.pred', first= FALSE, scales=list(draw=T), main="Rainfall Estimates (Trend Surface Model)", sp.layout=pts) Cheers, Yasmine [[alternative HTML version deleted]] From englishchristophera at gmail.com Wed May 25 00:34:03 2016 From: englishchristophera at gmail.com (chris english) Date: Wed, 25 May 2016 01:34:03 +0300 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: 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.2 Rcpp_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&t=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 wrote: > 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 TRUE FALSE > > 51 HDF4Image HDF4 Dataset TRUE FALSE FALSE > > 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 > 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 >> 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 >>> wrote: >>>> >>>> > ?MODISoptions >>>> > MODIS:::checkTools("GDAL") >>>> Checking availabillity of GDAL: >>>> OK, GDAL 2.1.0dev, released 2015/99/99 found! >>>> > getOption("MODIS_gdalOutDriver") >>>> [1] name description 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 >>>> wrote: >>>>> >>>>> Same here. Loading rgdal didn't make a difference. >>>>> >>>>> On Tue, May 17, 2016 at 9:05 AM, chris english >>>>> 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 >>>>>> 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.2 Rcpp_0.12.4 >>>>>>> grid_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 >>>>>>> > >>>>>>> Hmmmm. 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > DOWNLOAD: >>>>>>>>> > _______________ >>>>>>>>> > MODISserverOrder : LPDAAC, LAADS >>>>>>>>> > dlmethod : auto >>>>>>>>> > stubbornness : 5 >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > PROCESSING: >>>>>>>>> > _______________ >>>>>>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 >>>>>>>>> > MRT : Version 4.1 (March 2011) >>>>>>>>> > pixelSize : asIn >>>>>>>>> > outProj : GEOGRAPHIC >>>>>>>>> > resamplingType : NN >>>>>>>>> > dataFormat : GTiff >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > DEPENDENCIES: >>>>>>>>> > _______________ >>>>>>>>> > >>>>>>>>> >> 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* >>>>>>>>> >> sessionInfo() >>>>>>>>> > R version 3.2.5 (2016-04-14) >>>>>>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 >>>>>>>>> > >>>>>>>>> > loaded via a namespace (and not attached): >>>>>>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 >>>>>>>>> > lattice_0.20-33 >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > __________________________________________________ >>>>>>>>> > >>>>>>>>> > Hakim Abdi | PhD Candidate >>>>>>>>> > Center for Geobiosphere Science >>>>>>>>> > >>>>>>>>> > Department of Physical Geography and Ecosystem Science >>>>>>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden >>>>>>>>> > >>>>>>>>> > [[alternative HTML version deleted]] >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > R-sig-Geo mailing list >>>>>>>>> > R-sig-Geo at r-project.org >>>>>>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> R-sig-Geo mailing list >>>>>>>> R-sig-Geo at r-project.org >>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandresantosbr at yahoo.com.br Wed May 25 03:17:13 2016 From: alexandresantosbr at yahoo.com.br (ASANTOS) Date: Tue, 24 May 2016 21:17:13 -0400 Subject: [R-sig-Geo] Calculate each polygon percentage inside a circles Message-ID: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> Dear members, I will try to calculate each polygon percentage inside a circles given an arbitrary radius in a shapefile object with the code below and my output needs to be (Two first columns with center os circle coordinates and values of each polygon percentage): "pts$x" "pts$y" "ID1" "ID2" "ID3" "ID4" 180486.1 330358.8 16.3 0.2 NA 17.3 179884.4 331420.8 88.3 NA 96.3 NA 179799.6 333062.5 25.3 22.3 0.5 NA ... For this I try to do: #Packages require(shapefiles) require(rgdal) require(maptools) require(spatstat) require(berryFunctions) #Create 4 polygons (I create polygons because is more simple that given a shapefile in a post) sr1=Polygons(list(Polygon(cbind(c(180114, 180553, 181127, 181477, 181294, 181007, 180409, 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, 332618, 332413, 332349)))),'1') sr2=Polygons(list(Polygon(cbind(c(180042, 180545, 180553, 180314, 179955, 179142, 179437, 179524, 179979, 180042), c(332373, 332026, 331426, 330889, 330683, 331133, 331623, 332152, 332357, 332373)))),'2') sr3=Polygons(list(Polygon(cbind(c(179110, 179907, 180433, 180712, 180752, 180329, 179875, 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110), c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, 329783, 329665, 329720, 329933, 330478, 331062, 331086)))),'3') sr4=Polygons(list(Polygon(cbind(c(180304, 180403,179632,179420,180304), c(332791, 333204, 333635, 333058, 332791)))),'4') #Spatial Polygons sr=SpatialPolygons(list(sr1,sr2,sr3,sr4)) srdf=SpatialPolygonsDataFrame(sr, data.frame(row.names=c('1','2','3','4'), PIDS=1:4)) #Create shapefile writeOGR(srdf, getwd(), 'POLY', 'ESRI Shapefile') #Read shapefile contorno_line_X <- readShapeSpatial("POLY.shp") plot(contorno_line_X) #Create ~28 random points in my window contorno_line_spat <- as(contorno_line_X,"owin") pts <- rpoispp(lambda=0.000005, win=contorno_line_spat) points(pts, col="blue") #Set the radius for the plots radius <- 600 # radius in meters #Draw the circles using berryFunctions package for(i in 1:length(pts$x)) circle(pts$x[i],pts$y[i],r=radius, col=rgb(1,0.5,0,alpha=0.4), border=NA) # Now I'd like to calculate de polygon percentage around each point in a 600 meters radius. This is possible? There are any function for this? Thanks, Alexandre -- ====================================================================== Alexandre dos Santos Prote??o Florestal IFMT - Instituto Federal de Educa??o, Ci?ncia e Tecnologia de Mato Grosso Campus C?ceres Caixa Postal 244 Avenida dos Ramires, s/n Bairro: Distrito Industrial C?ceres - MT CEP: 78.200-000 Fone: (+55) 65 8132-8112 (TIM) (+55) 65 9686-6970 (VIVO) alexandre.santos at cas.ifmt.edu.br Lattes: http://lattes.cnpq.br/1360403201088680 OrcID: orcid.org/0000-0001-8232-6722 Researchgate: https://www.researchgate.net/profile/Alexandre_Santos10 LinkedIn: https://br.linkedin.com/in/alexandre-dos-santos-87961635 ====================================================================== [[alternative HTML version deleted]] From juantomas.sayago at gmail.com Wed May 25 04:13:28 2016 From: juantomas.sayago at gmail.com (Juan Tomas Sayago Gomez) Date: Wed, 25 May 2016 02:13:28 +0000 Subject: [R-sig-Geo] Calculate each polygon percentage inside a circles In-Reply-To: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> References: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> Message-ID: you should check the intersect function. I used it like in this function in the link: http://gis.stackexchange.com/questions/140504/extracting-intersection-areas-in-r Juan On Tue, May 24, 2016 at 9:17 PM ASANTOS via R-sig-Geo < r-sig-geo at r-project.org> wrote: > Dear members, > > I will try to calculate each polygon percentage inside a circles > given an arbitrary radius in a shapefile object with the code below and > my output needs to be (Two first columns with center os circle > coordinates and values of each polygon percentage): > > "pts$x" "pts$y" "ID1" "ID2" "ID3" "ID4" > 180486.1 330358.8 16.3 0.2 NA 17.3 > 179884.4 331420.8 88.3 NA 96.3 NA > 179799.6 333062.5 25.3 22.3 0.5 NA > ... > > For this I try to do: > > #Packages > require(shapefiles) > require(rgdal) > require(maptools) > require(spatstat) > require(berryFunctions) > > > #Create 4 polygons (I create polygons because is more simple that given > a shapefile in a post) > > sr1=Polygons(list(Polygon(cbind(c(180114, 180553, 181127, 181477, > 181294, 181007, 180409, > 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, > 332618, 332413, 332349)))),'1') > sr2=Polygons(list(Polygon(cbind(c(180042, 180545, 180553, 180314, > 179955, 179142, 179437, > 179524, 179979, 180042), c(332373, 332026, 331426, 330889, 330683, > 331133, 331623, 332152, 332357, 332373)))),'2') > sr3=Polygons(list(Polygon(cbind(c(179110, 179907, 180433, 180712, > 180752, 180329, 179875, > 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110), > c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, > 329783, 329665, 329720, 329933, 330478, 331062, 331086)))),'3') > sr4=Polygons(list(Polygon(cbind(c(180304, 180403,179632,179420,180304), > c(332791, 333204, 333635, 333058, 332791)))),'4') > > #Spatial Polygons > sr=SpatialPolygons(list(sr1,sr2,sr3,sr4)) > srdf=SpatialPolygonsDataFrame(sr, > data.frame(row.names=c('1','2','3','4'), PIDS=1:4)) > > #Create shapefile > writeOGR(srdf, getwd(), 'POLY', 'ESRI Shapefile') > > #Read shapefile > contorno_line_X <- readShapeSpatial("POLY.shp") > plot(contorno_line_X) > > #Create ~28 random points in my window > contorno_line_spat <- as(contorno_line_X,"owin") > pts <- rpoispp(lambda=0.000005, win=contorno_line_spat) > points(pts, col="blue") > > #Set the radius for the plots > radius <- 600 # radius in meters > > #Draw the circles using berryFunctions package > for(i in 1:length(pts$x)) circle(pts$x[i],pts$y[i],r=radius, > col=rgb(1,0.5,0,alpha=0.4), border=NA) > # > > Now I'd like to calculate de polygon percentage around each point in a > 600 meters radius. This is possible? There are any function for this? > > Thanks, > > Alexandre > > -- > ====================================================================== > Alexandre dos Santos > Prote??o Florestal > IFMT - Instituto Federal de Educa??o, Ci?ncia e Tecnologia de Mato Grosso > Campus C?ceres > Caixa Postal 244 > Avenida dos Ramires, s/n > Bairro: Distrito Industrial > C?ceres - MT CEP: 78.200-000 > Fone: (+55) 65 8132-8112 (TIM) (+55) 65 9686-6970 (VIVO) > > alexandre.santos at cas.ifmt.edu.br > Lattes: http://lattes.cnpq.br/1360403201088680 > OrcID: orcid.org/0000-0001-8232-6722 > Researchgate: https://www.researchgate.net/profile/Alexandre_Santos10 > LinkedIn: https://br.linkedin.com/in/alexandre-dos-santos-87961635 > ====================================================================== > > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo [[alternative HTML version deleted]] From eduardodiez at gmx.com Wed May 25 05:15:27 2016 From: eduardodiez at gmx.com (Eduardo Diez) Date: Wed, 25 May 2016 00:15:27 -0300 Subject: [R-sig-Geo] Bearing angle of UTM projected SpatialLines Message-ID: Dear everyone, I'm used to calculating the compass angles (clockwise from due North) of line features projected in UTM using the tool Linear Directional Mean from ArcGIS. I could find functions for performing a similar task but taking Origin -> Destination points and only in Lat/Lon (geographic coordinates) namely: geosphere::bearing and maptools::gzAzimuth. (Somehow they give different results for the same set of points: around 0.05 degrees, maybe because of the trigonometry) Because of the nature of my work it has to be in UTM. Perhaps someone skillfull in trigonometry can figure it out but i'm not the case. Is there a way to do this in R? Thanks, Eduardo [[alternative HTML version deleted]] From r.turner at auckland.ac.nz Wed May 25 05:55:23 2016 From: r.turner at auckland.ac.nz (Rolf Turner) Date: Wed, 25 May 2016 15:55:23 +1200 Subject: [R-sig-Geo] [FORGED] Calculate each polygon percentage inside a circles In-Reply-To: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> References: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> Message-ID: <332c038d-5a96-4396-d3f5-d7664e3f0c0b@auckland.ac.nz> Dear Alexandre, Your tasks can all be done very simply in spatstat. The code follows. Note that I had to reverse the point order for sr2 and sr3 because spatstat requires that the vertices of (exterior) boundaries of polygonal windows be given in anticlockwise order. I commented out the plotting of the discs centred at each point of the simulated pattern since I found the plot to be unenlightening and messy looking. The resulting percentages that you are after are in "pct". If you want more precision for the disc areas, set npoly equal to a large number than the default 128 (e.g.1024 or 2048) in the calls to disc(). cheers, Rolf Turner -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 #================================================================================== library(spatstat) bdry <- list(cbind(c(180114, 180553, 181127, 181477, 181294, 181007, 180409, 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, 332618, 332413, 332349)), cbind(rev(c(180042, 180545, 180553, 180314, 179955, 179142, 179437, 179524, 179979, 180042)), rev(c(332373, 332026, 331426, 330889, 330683, 331133, 331623, 332152, 332357, 332373))), cbind(rev(c(179110, 179907, 180433, 180712, 180752, 180329, 179875, 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110)), rev(c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, 329783, 329665, 329720, 329933, 330478, 331062, 331086))), cbind(c(180304, 180403,179632,179420,180304), c(332791, 333204, 333635, 333058, 332791))) W <- owin(poly=bdry) set.seed(42) X <- rpoispp(28/area.owin(W),win=W) plot(X,cols="blue") #for(i in 1:npoints(X)) plot(disc(radius=600,centre=c(X$x[i],X$y[i])), # add=TRUE,col=rgb(1,0.5,0,alpha=0.4),border=NA) # To be fair, calculate the area of the discs using area.owin() # rather than as pi*600^2. AD <- area.owin(disc(radius=600)) pct <- numeric(npoints(X)) for(i in 1:npoints(X)) { Di <- disc(radius=600,centre=c(X$x[i],X$y[i])) pct[i] <- 100*area.owin(intersect.owin(Di,W))/AD } #================================================================================== On 25/05/16 13:17, ASANTOS via R-sig-Geo wrote: > Dear members, > > I will try to calculate each polygon percentage inside a circles > given an arbitrary radius in a shapefile object with the code below and > my output needs to be (Two first columns with center os circle > coordinates and values of each polygon percentage): > > "pts$x" "pts$y" "ID1" "ID2" "ID3" "ID4" > 180486.1 330358.8 16.3 0.2 NA 17.3 > 179884.4 331420.8 88.3 NA 96.3 NA > 179799.6 333062.5 25.3 22.3 0.5 NA > ... > > For this I try to do: > > #Packages > require(shapefiles) > require(rgdal) > require(maptools) > require(spatstat) > require(berryFunctions) > > > #Create 4 polygons (I create polygons because is more simple that given > a shapefile in a post) > > sr1=Polygons(list(Polygon(cbind(c(180114, 180553, 181127, 181477, > 181294, 181007, 180409, > 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, > 332618, 332413, 332349)))),'1') > sr2=Polygons(list(Polygon(cbind(c(180042, 180545, 180553, 180314, > 179955, 179142, 179437, > 179524, 179979, 180042), c(332373, 332026, 331426, 330889, 330683, > 331133, 331623, 332152, 332357, 332373)))),'2') > sr3=Polygons(list(Polygon(cbind(c(179110, 179907, 180433, 180712, > 180752, 180329, 179875, > 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110), > c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, > 329783, 329665, 329720, 329933, 330478, 331062, 331086)))),'3') > sr4=Polygons(list(Polygon(cbind(c(180304, 180403,179632,179420,180304), > c(332791, 333204, 333635, 333058, 332791)))),'4') > > #Spatial Polygons > sr=SpatialPolygons(list(sr1,sr2,sr3,sr4)) > srdf=SpatialPolygonsDataFrame(sr, > data.frame(row.names=c('1','2','3','4'), PIDS=1:4)) > > #Create shapefile > writeOGR(srdf, getwd(), 'POLY', 'ESRI Shapefile') > > #Read shapefile > contorno_line_X <- readShapeSpatial("POLY.shp") > plot(contorno_line_X) > > #Create ~28 random points in my window > contorno_line_spat <- as(contorno_line_X,"owin") > pts <- rpoispp(lambda=0.000005, win=contorno_line_spat) > points(pts, col="blue") > > #Set the radius for the plots > radius <- 600 # radius in meters > > #Draw the circles using berryFunctions package > for(i in 1:length(pts$x)) circle(pts$x[i],pts$y[i],r=radius, > col=rgb(1,0.5,0,alpha=0.4), border=NA) > # > > Now I'd like to calculate de polygon percentage around each point in a > 600 meters radius. This is possible? There are any function for this? > > Thanks, > > Alexandre > From Roger.Bivand at nhh.no Wed May 25 09:32:29 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Wed, 25 May 2016 09:32:29 +0200 Subject: [R-sig-Geo] Bearing angle of UTM projected SpatialLines In-Reply-To: References: Message-ID: On Wed, 25 May 2016, Eduardo Diez wrote: > Dear everyone, > I'm used to calculating the compass angles (clockwise from due North) of > line features projected in UTM using the tool Linear Directional Mean > > from ArcGIS. > I could find functions for performing a similar task but taking Origin -> > Destination points and only in Lat/Lon (geographic coordinates) namely: > geosphere::bearing and maptools::gzAzimuth. (Somehow they give different > results for the same set of points: around 0.05 degrees, maybe because of > the trigonometry) > Because of the nature of my work it has to be in UTM. Interesting question. Could you please provide a test set of pairs of coordinates with the fully qualified UTM projection (which datum in particular, and if WGS84, which version - there are several), the output from ArcGIS (which version), and the geographical coordinates you see in ArcGIS (to remove the possibility that it is a projection issue on the R side). They don't need to mean anything, only that they can show us what the problem is in code and numeric terms. A link to an R file and an RDS file would be helpful. Roger > Perhaps someone skillfull in trigonometry can figure it out but i'm not the > case. > Is there a way to do this in R? > > Thanks, > Eduardo > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From hakim.abdi at nateko.lu.se Wed May 25 11:43:06 2016 From: hakim.abdi at nateko.lu.se (Hakim Abdi) Date: Wed, 25 May 2016 11:43:06 +0200 Subject: [R-sig-Geo] MODIS package's runGdal() returns error: dataFormat='GTiff', format not supported In-Reply-To: References: <21dff37bfe9b4521b79fff155b555e21@UWCAS03.uw.lu.se> Message-ID: Thanks for all your help Chris, the original error has been corrected, and now there is another error when trying to run runGdal(). I removed the previous version of MODIS and installed version 0.10-34 (develop branch) as per Florian's suggestion. Everything runs fine until it gets to accessing the server and downloading the file. The same happens to my colleague who is running a 64-bit Ubuntu 14.04 machine with R 3.3.0. The issue seems to stem from the fact that in the getStruc.R file FtpDayDirs[1]==FALSE. In fact FtpDayDirs[1] is NULL, which in turn is due to the fact that getStruc.R failed to connect to e4ftl01.cr.usgs.gov (port 80: Timed out). Is anyone else having this issue? I tried accessing http://e4ftl01.cr.usgs.gov/ on my browser and it does seems to be down. Running getStruc.R and selecting LAADS instead of LPDAAC seems to work, but I don't know how to incorporate this into the runGdal() command. Cheers, Hakim Abdi 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. > remove.packages("MODIS") Removing package from ?C:/Program Files/R/R-3.2.5/library? (as ?lib? is unspecified) > install.packages("C:/Users/Hakim/Downloads/MODIS-develop", repos = NULL, type = "source") * installing *source* package 'MODIS' ... ** R ** inst ** byte-compile and prepare package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded * DONE (MODIS) > 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&t=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... 43 usable drivers detected! STORAGE: _______________ localArcPath : C:/Users/Hakim/Documents/MODIS_ARC/ outDirPath : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ DOWNLOAD: _______________ MODISserverOrder : LPDAAC, LAADS dlmethod : auto stubbornness : 5 PROCESSING: _______________ GDAL : GDAL 2.0.2, released 2016/01/26 MRT : Version 4.1 (March 2011) pixelSize : asIn outProj : GEOGRAPHIC resamplingType : NN dataFormat : GTiff DEPENDENCIES: _______________ > dates <- as.POSIXct( as.Date(c("01/04/2016","15/04/2016"),format = "%d/%m/%Y") ) # specify your beginning and end dates > dates <- transDate(dates[1],dates[2]) # transform them into a readable format > product <- "MOD13Q1" # MODIS vegetation indices > bands <- "010" # here I select the 2nd (EVI) > h = c("22") # your tile horizontal value > v = c("07","08") # your tile vertical value > 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-8, (SVN revision 616) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 2.0.1, released 2015/09/15 Path to GDAL shared files: C:/Program Files/R/R-3.2.5/library/rgdal/gdal GDAL does not use iconv for recoding strings. Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491] Path to PROJ.4 shared files: C:/Program Files/R/R-3.2.5/library/rgdal/proj Linking to sp version: 1.2-3 Loading required package: rgeos rgeos version: 0.3-19, (SVN revision 524) GEOS runtime version: 3.5.0-CAPI-1.9.0 r4084 Linking to sp version: 1.2-3 Polygon checking: TRUE ######################## outProj = +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 pixelSize = asIn resamplingType = near Output directory = C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED//MOD13Q1.005_20160525102653 (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* On Wed, May 25, 2016 at 12:34 AM, chris english < englishchristophera at gmail.com> wrote: > 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.2 Rcpp_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&t=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 > wrote: > > 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 TRUE FALSE > > > > 51 HDF4Image HDF4 Dataset TRUE FALSE FALSE > > > > 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 > > 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 > >> 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 > >>> wrote: > >>>> > >>>> > ?MODISoptions > >>>> > MODIS:::checkTools("GDAL") > >>>> Checking availabillity of GDAL: > >>>> OK, GDAL 2.1.0dev, released 2015/99/99 found! > >>>> > getOption("MODIS_gdalOutDriver") > >>>> [1] name description 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 > > >>>> wrote: > >>>>> > >>>>> Same here. Loading rgdal didn't make a difference. > >>>>> > >>>>> On Tue, May 17, 2016 at 9:05 AM, chris english > >>>>> 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 > >>>>>> 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.2 Rcpp_0.12.4 > >>>>>>> grid_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 > >>>>>>> > > >>>>>>> Hmmmm. 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&t=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 : C:/Users/Hakim/Documents/MODIS_ARC/PROCESSED/ > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > DOWNLOAD: > >>>>>>>>> > _______________ > >>>>>>>>> > MODISserverOrder : LPDAAC, LAADS > >>>>>>>>> > dlmethod : auto > >>>>>>>>> > stubbornness : 5 > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > PROCESSING: > >>>>>>>>> > _______________ > >>>>>>>>> > GDAL : GDAL 2.0.2, released 2016/01/26 > >>>>>>>>> > MRT : Version 4.1 (March 2011) > >>>>>>>>> > pixelSize : asIn > >>>>>>>>> > outProj : GEOGRAPHIC > >>>>>>>>> > resamplingType : NN > >>>>>>>>> > dataFormat : GTiff > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > DEPENDENCIES: > >>>>>>>>> > _______________ > >>>>>>>>> > > >>>>>>>>> >> 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* > >>>>>>>>> >> sessionInfo() > >>>>>>>>> > R version 3.2.5 (2016-04-14) > >>>>>>>>> > 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] MODIS_0.10-34 raster_2.5-2 sp_1.2-3 > >>>>>>>>> > > >>>>>>>>> > loaded via a namespace (and not attached): > >>>>>>>>> > [1] tools_3.2.5 Rcpp_0.12.4 grid_3.2.5 > >>>>>>>>> > lattice_0.20-33 > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > __________________________________________________ > >>>>>>>>> > > >>>>>>>>> > Hakim Abdi | PhD Candidate > >>>>>>>>> > Center for Geobiosphere Science > >>>>>>>>> > > >>>>>>>>> > Department of Physical Geography and Ecosystem Science > >>>>>>>>> > Lund University, S?lvegatan 12, SE-223 62 Lund, Sweden > >>>>>>>>> > > >>>>>>>>> > [[alternative HTML version deleted]] > >>>>>>>>> > > >>>>>>>>> > _______________________________________________ > >>>>>>>>> > R-sig-Geo mailing list > >>>>>>>>> > R-sig-Geo at r-project.org > >>>>>>>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > >>>>>>>>> > > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> R-sig-Geo mailing list > >>>>>>>> R-sig-Geo at r-project.org > >>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > [[alternative HTML version deleted]] From markpayneatwork at gmail.com Wed May 25 11:58:54 2016 From: markpayneatwork at gmail.com (Mark R Payne) Date: Wed, 25 May 2016 11:58:54 +0200 Subject: [R-sig-Geo] Raster: Can't read raster-created NCDF back in Message-ID: Hi, I have a rasterBrick object that I have created through a series of manipulations and written to disk using writeRaster(x,format="CDF"). In another, independent script, I then need to read that netcdf file back in. The following commands work: > b <- brick("Bluefin_OISST_clim.nc") > plot(b) but these don't: > crop(b,extent(320,340,55,60)) Error in ncvar_get_inner(ncid2use, varid2use, nc$var[[li]]$missval, addOffset, : Error: variable has 2 dims, but start has 3 entries. They must match! > readAll(b) Error in ncvar_get_inner(ncid2use, varid2use, nc$var[[li]]$missval, addOffset, : Error: variable has 2 dims, but start has 3 entries. They must match! > which is just strange. Does anyone have any ideas what might be going on here? The file is available here (its 60kb) http://bit.ly/1TDEJHZ The netcdf header and my session info follow. Cheers, Mark netcdf Bluefin_OISST_clim { dimensions: longitude = 176 ; latitude = 80 ; variables: double longitude(longitude) ; longitude:units = "degrees_east" ; longitude:long_name = "longitude" ; double latitude(latitude) ; latitude:units = "degrees_north" ; latitude:long_name = "latitude" ; float SST(latitude, longitude) ; SST:_FillValue = -3.4e+38 ; SST:missing_value = -3.4e+38 ; SST:long_name = "SST" ; SST:projection = "+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0" ; SST:projection_format = "PROJ.4" ; SST:min = 0.331762666431522 ; SST:max = 16.0566702570234 ; // global attributes: :Conventions = "CF-1.4" ; :created_by = "R, packages ncdf4 and raster (version 2.5-2)" ; :date = "2016-05-25 11:47:53" ; data: longitude = 308.125, 308.375, 308.625, 308.875, 309.125, 309.375, 309.625, 309.875, 310.125, 310.375, 310.625, 310.875, 311.125, 311.375, 311.625, 311.875, 312.125, 312.375, 312.625, 312.875, 313.125, 313.375, 313.625, 313.875, 314.125, 314.375, 314.625, 314.875, 315.125, 315.375, 315.625, 315.875, 316.125, 316.375, 316.625, 316.875, 317.125, 317.375, 317.625, 317.875, 318.125, 318.375, 318.625, 318.875, 319.125, 319.375, 319.625, 319.875, 320.125, 320.375, 320.625, 320.875, 321.125, 321.375, 321.625, 321.875, 322.125, 322.375, 322.625, 322.875, 323.125, 323.375, 323.625, 323.875, 324.125, 324.375, 324.625, 324.875, 325.125, 325.375, 325.625, 325.875, 326.125, 326.375, 326.625, 326.875, 327.125, 327.375, 327.625, 327.875, 328.125, 328.375, 328.625, 328.875, 329.125, 329.375, 329.625, 329.875, 330.125, 330.375, 330.625, 330.875, 331.125, 331.375, 331.625, 331.875, 332.125, 332.375, 332.625, 332.875, 333.125, 333.375, 333.625, 333.875, 334.125, 334.375, 334.625, 334.875, 335.125, 335.375, 335.625, 335.875, 336.125, 336.375, 336.625, 336.875, 337.125, 337.375, 337.625, 337.875, 338.125, 338.375, 338.625, 338.875, 339.125, 339.375, 339.625, 339.875, 340.125, 340.375, 340.625, 340.875, 341.125, 341.375, 341.625, 341.875, 342.125, 342.375, 342.625, 342.875, 343.125, 343.375, 343.625, 343.875, 344.125, 344.375, 344.625, 344.875, 345.125, 345.375, 345.625, 345.875, 346.125, 346.375, 346.625, 346.875, 347.125, 347.375, 347.625, 347.875, 348.125, 348.375, 348.625, 348.875, 349.125, 349.375, 349.625, 349.875, 350.125, 350.375, 350.625, 350.875, 351.125, 351.375, 351.625, 351.875 ; latitude = 71.875, 71.625, 71.375, 71.125, 70.875, 70.625, 70.375, 70.125, 69.875, 69.625, 69.375, 69.125, 68.875, 68.625, 68.375, 68.125, 67.875, 67.625, 67.375, 67.125, 66.875, 66.625, 66.375, 66.125, 65.875, 65.625, 65.375, 65.125, 64.875, 64.625, 64.375, 64.125, 63.875, 63.625, 63.375, 63.125, 62.875, 62.625, 62.375, 62.125, 61.875, 61.625, 61.375, 61.125, 60.875, 60.625, 60.375, 60.125, 59.875, 59.625, 59.375, 59.125, 58.875, 58.625, 58.375, 58.125, 57.875, 57.625, 57.375, 57.125, 56.875, 56.625, 56.375, 56.125, 55.875, 55.625, 55.375, 55.125, 54.875, 54.625, 54.375, 54.125, 53.875, 53.625, 53.375, 53.125, 52.875, 52.625, 52.375, 52.125 ; } > sessionInfo() R version 3.2.2 (2015-08-14) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.1 LTS locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_NZ.UTF-8 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C LC_ADDRESS=C [10] LC_TELEPHONE=C LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] lubridate_1.5.6 stringr_1.0.0 raster_2.5-2 sp_1.2-1 loaded via a namespace (and not attached): [1] magrittr_1.5 rgdal_1.1-1 rsconnect_0.4.1.11 parallel_3.2.2 [5] tools_3.2.2 Rcpp_0.12.2 stringi_1.0-1 ncdf4_1.15 [9] grid_3.2.2 lattice_0.20-33 > [[alternative HTML version deleted]] From mdsumner at gmail.com Wed May 25 12:15:21 2016 From: mdsumner at gmail.com (Michael Sumner) Date: Wed, 25 May 2016 10:15:21 +0000 Subject: [R-sig-Geo] Raster: Can't read raster-created NCDF back in In-Reply-To: References: Message-ID: On Wed, 25 May 2016 at 19:59 Mark R Payne wrote: > Hi, > > I have a rasterBrick object that I have created through a series of > manipulations and written to disk using writeRaster(x,format="CDF"). In > another, independent script, I then need to read that netcdf file back in. > The following commands work: > > > b <- brick("Bluefin_OISST_clim.nc") > > plot(b) > > but these don't: > > > > crop(b,extent(320,340,55,60)) > Error in ncvar_get_inner(ncid2use, varid2use, nc$var[[li]]$missval, > addOffset, : > Error: variable has 2 dims, but start has 3 entries. They must match! > > readAll(b) > Error in ncvar_get_inner(ncid2use, varid2use, nc$var[[li]]$missval, > addOffset, : > Error: variable has 2 dims, but start has 3 entries. They must match! > > > > I don't know the proper fix, but it works if you use a RasterLayer rather than a 1-layer RasterBrick: crop(b[[1]],extent(320,340,55,60)) It's straightforwardly a bug IMO, due to the logic of a 1-layer degenerate dimension - and one for the the raster maintainer. If you can look at the source of raster:::.readRowsBrickNetCDF you'll probably find it if for a suggested fix or patch. Cheers, Mike. > which is just strange. Does anyone have any ideas what might be going on > here? > > The file is available here (its 60kb) > http://bit.ly/1TDEJHZ > > The netcdf header and my session info follow. > > Cheers, > > Mark > > > > > netcdf Bluefin_OISST_clim { > dimensions: > longitude = 176 ; > latitude = 80 ; > variables: > double longitude(longitude) ; > longitude:units = "degrees_east" ; > longitude:long_name = "longitude" ; > double latitude(latitude) ; > latitude:units = "degrees_north" ; > latitude:long_name = "latitude" ; > float SST(latitude, longitude) ; > SST:_FillValue = -3.4e+38 ; > SST:missing_value = -3.4e+38 ; > SST:long_name = "SST" ; > SST:projection = "+proj=longlat +datum=WGS84 +ellps=WGS84 > +towgs84=0,0,0" ; > SST:projection_format = "PROJ.4" ; > SST:min = 0.331762666431522 ; > SST:max = 16.0566702570234 ; > > // global attributes: > :Conventions = "CF-1.4" ; > :created_by = "R, packages ncdf4 and raster (version 2.5-2)" ; > :date = "2016-05-25 11:47:53" ; > data: > > longitude = 308.125, 308.375, 308.625, 308.875, 309.125, 309.375, 309.625, > 309.875, 310.125, 310.375, 310.625, 310.875, 311.125, 311.375, 311.625, > 311.875, 312.125, 312.375, 312.625, 312.875, 313.125, 313.375, 313.625, > 313.875, 314.125, 314.375, 314.625, 314.875, 315.125, 315.375, 315.625, > 315.875, 316.125, 316.375, 316.625, 316.875, 317.125, 317.375, 317.625, > 317.875, 318.125, 318.375, 318.625, 318.875, 319.125, 319.375, 319.625, > 319.875, 320.125, 320.375, 320.625, 320.875, 321.125, 321.375, 321.625, > 321.875, 322.125, 322.375, 322.625, 322.875, 323.125, 323.375, 323.625, > 323.875, 324.125, 324.375, 324.625, 324.875, 325.125, 325.375, 325.625, > 325.875, 326.125, 326.375, 326.625, 326.875, 327.125, 327.375, 327.625, > 327.875, 328.125, 328.375, 328.625, 328.875, 329.125, 329.375, 329.625, > 329.875, 330.125, 330.375, 330.625, 330.875, 331.125, 331.375, 331.625, > 331.875, 332.125, 332.375, 332.625, 332.875, 333.125, 333.375, 333.625, > 333.875, 334.125, 334.375, 334.625, 334.875, 335.125, 335.375, 335.625, > 335.875, 336.125, 336.375, 336.625, 336.875, 337.125, 337.375, 337.625, > 337.875, 338.125, 338.375, 338.625, 338.875, 339.125, 339.375, 339.625, > 339.875, 340.125, 340.375, 340.625, 340.875, 341.125, 341.375, 341.625, > 341.875, 342.125, 342.375, 342.625, 342.875, 343.125, 343.375, 343.625, > 343.875, 344.125, 344.375, 344.625, 344.875, 345.125, 345.375, 345.625, > 345.875, 346.125, 346.375, 346.625, 346.875, 347.125, 347.375, 347.625, > 347.875, 348.125, 348.375, 348.625, 348.875, 349.125, 349.375, 349.625, > 349.875, 350.125, 350.375, 350.625, 350.875, 351.125, 351.375, 351.625, > 351.875 ; > > latitude = 71.875, 71.625, 71.375, 71.125, 70.875, 70.625, 70.375, 70.125, > 69.875, 69.625, 69.375, 69.125, 68.875, 68.625, 68.375, 68.125, 67.875, > 67.625, 67.375, 67.125, 66.875, 66.625, 66.375, 66.125, 65.875, 65.625, > 65.375, 65.125, 64.875, 64.625, 64.375, 64.125, 63.875, 63.625, 63.375, > 63.125, 62.875, 62.625, 62.375, 62.125, 61.875, 61.625, 61.375, 61.125, > 60.875, 60.625, 60.375, 60.125, 59.875, 59.625, 59.375, 59.125, 58.875, > 58.625, 58.375, 58.125, 57.875, 57.625, 57.375, 57.125, 56.875, 56.625, > 56.375, 56.125, 55.875, 55.625, 55.375, 55.125, 54.875, 54.625, 54.375, > 54.125, 53.875, 53.625, 53.375, 53.125, 52.875, 52.625, 52.375, 52.125 > ; > } > > > sessionInfo() > R version 3.2.2 (2015-08-14) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 14.04.1 LTS > > locale: > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > LC_TIME=en_NZ.UTF-8 > [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_NZ.UTF-8 > LC_MESSAGES=en_US.UTF-8 > [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C > LC_ADDRESS=C > [10] LC_TELEPHONE=C LC_MEASUREMENT=en_NZ.UTF-8 > LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] lubridate_1.5.6 stringr_1.0.0 raster_2.5-2 sp_1.2-1 > > loaded via a namespace (and not attached): > [1] magrittr_1.5 rgdal_1.1-1 rsconnect_0.4.1.11 > parallel_3.2.2 > [5] tools_3.2.2 Rcpp_0.12.2 stringi_1.0-1 > ncdf4_1.15 > [9] grid_3.2.2 lattice_0.20-33 > > > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Dr. Michael Sumner Software and Database Engineer Australian Antarctic Division 203 Channel Highway Kingston Tasmania 7050 Australia [[alternative HTML version deleted]] From alexandresantosbr at yahoo.com.br Wed May 25 14:23:59 2016 From: alexandresantosbr at yahoo.com.br (ASANTOS) Date: Wed, 25 May 2016 08:23:59 -0400 Subject: [R-sig-Geo] [FORGED] Calculate each polygon percentage inside a circles In-Reply-To: <332c038d-5a96-4396-d3f5-d7664e3f0c0b@auckland.ac.nz> References: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> <332c038d-5a96-4396-d3f5-d7664e3f0c0b@auckland.ac.nz> Message-ID: <9cfea508-cd7a-a223-df92-389b095f0571@yahoo.com.br> Dear Rolf Turner, It's much better a clean code with a minimum packages, thank you very much for your answer. But "pct" object give me a total polygon percentage around each point and I need too an identification (in columns) of individual contribution of each polygon. In my simulation, I find 50.38001% for the point 1, but this is a total percentage of polygons and I'd like to know a percentage contribution for each polygon (e.g. ID1 = 0.00000 + ID1 = 10.00000 + ID3 = 0.00000 + ID4 = 40.38001 = 50.38001 total), this is possible? Thanks again, Best wishes, Alexandre #================================================================================== library(spatstat) bdry <- list(cbind(c(180114, 180553, 181127, 181477, 181294, 181007, 180409, 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, 332618, 332413, 332349)), cbind(rev(c(180042, 180545, 180553, 180314, 179955, 179142, 179437, 179524, 179979, 180042)), rev(c(332373, 332026, 331426, 330889, 330683, 331133, 331623, 332152, 332357, 332373))), cbind(rev(c(179110, 179907, 180433, 180712, 180752, 180329, 179875, 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110)), rev(c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, 329783, 329665, 329720, 329933, 330478, 331062, 331086))), cbind(c(180304, 180403,179632,179420,180304), c(332791, 333204, 333635, 333058, 332791))) W <- owin(poly=bdry) set.seed(42) X <- rpoispp(28/area.owin(W),win=W) plot(X,cols="blue") for(i in 1:npoints(X)) plot(disc(radius=600,centre=c(X$x[i],X$y[i])), add=TRUE,col=rgb(1,0.5,0,alpha=0.4),border=NA) # To be fair, calculate the area of the discs using area.owin() # rather than as pi*600^2. AD <- area.owin(disc(radius=600)) pct <- numeric(npoints(X)) for(i in 1:npoints(X)) { Di <- disc(radius=600,centre=c(X$x[i],X$y[i])) pct[i] <- 100*area.owin(intersect.owin(Di,W))/AD } #================================================================================== -- ====================================================================== Alexandre dos Santos Prote??o Florestal IFMT - Instituto Federal de Educa??o, Ci?ncia e Tecnologia de Mato Grosso Campus C?ceres Caixa Postal 244 Avenida dos Ramires, s/n Bairro: Distrito Industrial C?ceres - MT CEP: 78.200-000 Fone: (+55) 65 8132-8112 (TIM) (+55) 65 9686-6970 (VIVO) alexandre.santos at cas.ifmt.edu.br Lattes: http://lattes.cnpq.br/1360403201088680 OrcID: orcid.org/0000-0001-8232-6722 Researchgate: https://www.researchgate.net/profile/Alexandre_Santos10 LinkedIn: https://br.linkedin.com/in/alexandre-dos-santos-87961635 ====================================================================== Em 24/05/2016 23:55, Rolf Turner escreveu: > > Dear Alexandre, > > Your tasks can all be done very simply in spatstat. The code follows. > Note that I had to reverse the point order for sr2 and sr3 because > spatstat requires that the vertices of (exterior) boundaries of > polygonal windows be given in anticlockwise order. > > I commented out the plotting of the discs centred at each point of the > simulated pattern since I found the plot to be unenlightening and > messy looking. > > The resulting percentages that you are after are in "pct". > > If you want more precision for the disc areas, set npoly equal to a > large number than the default 128 (e.g.1024 or 2048) in the calls to > disc(). > > cheers, > > Rolf Turner > [[alternative HTML version deleted]] From gwennael.bataille at uclouvain.be Wed May 25 15:53:47 2016 From: gwennael.bataille at uclouvain.be (=?ISO-8859-1?Q?Gwenna=EBl_Bataille?=) Date: Wed, 25 May 2016 15:53:47 +0200 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines Message-ID: <5745AE6B.3070208@uclouvain.be> Dear all, I can't find a solution for the following problem: When I first intersect a line with 2 polygons (splitting it into 2 segments) and then use an overlay to get for each segment the attribute of the overlapping polygon, I sometimes get too answers (i.e. a small point overlapping one polygon, the rest of the segment overlapping another). The functions I use for this are: rgeos::gIntersection and sp::over Do you have any idea how I could get the attribute of the polygon the segments are "mostly overlapping"? Below is a reproductible example. Thank you very much in advance for any hint on this. Best regards, Gwenna?l Reproductible example: matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, 104030, 103733, 103733)) matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, 104030, 103733, 103733)) P1 <- Polygon (matrix1) P2 <- Polygon (matrix2) Ps1 <- Polygons (list(P1), 1 ) Ps2 <- Polygons (list(P2), 2 ) Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat +datum=WGS84")) data <- data.frame( Attribute = c("1black", "2red") ) PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) plot(PolyD, col = PolyD$Attribute) matrix3 <- cbind(x= c(250300, 250666), y= c(103900, 103900)) L <- Line(matrix3) Ls <- Lines(list(L), "1") Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat +datum=WGS84") ) Inter <- rgeos::gIntersection(Line,PolyD, byid=T) lines( Inter[1], col = "green", lwd = 3 ) lines( Inter[2], col = "blue", lwd = 3 ) over(Inter[1], PolyD, byid=T) 'Attribute 11black' # The green (1st) segment intersects with the black (1st) polygon => good over(Inter[2], PolyD, byid=T) 'Attribute 11black' # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK over(Inter[2], PolyD, byid=T, returnList = TRUE) '[[1]] Attribute 11black 22red' # The blue(2nd) segment appears to intersect the two polygons (I guess one point in common with the first polygon; the rest of the segment overlapping the other polygon) -- Gwenna?l BATAILLE, PhD student - Teaching assistant Earth and Life Institute Universit? Catholique de Louvain SST/ELI/ELIB B?timent Carnoy, c.145 Croix du sud 4-5, bte L7.07.04 1348 Louvain-la-Neuve BELGIUM [[alternative HTML version deleted]] From eduardodiez at gmx.com Wed May 25 21:09:37 2016 From: eduardodiez at gmx.com (Eduardo Diez) Date: Wed, 25 May 2016 16:09:37 -0300 Subject: [R-sig-Geo] Bearing angle of UTM projected SpatialLines In-Reply-To: References: Message-ID: Here are some details and example: > sessionInfo() R version 3.2.5 (2016-04-14) 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] RPyGeo_0.9-3 RSAGA_0.94-5 plyr_1.8.3 gstat_1.1-3 [5] shapefiles_0.7 foreign_0.8-66 rgdal_1.1-8 maptools_0.8-39 [9] geosphere_1.5-1 ggplot2_2.1.0 raster_2.5-2 rgeos_0.3-19 [13] sp_1.2-3 RevoUtilsMath_3.2.5 loaded via a namespace (and not attached): [1] Rcpp_0.12.4 maps_3.1.0 munsell_0.4.3 colorspace_1.2-6 lattice_0.20-33 [6] FNN_1.1 xts_0.9-7 tools_3.2.5 parallel_3.2.5 grid_3.2.5 [11] gtable_0.2.0 intervals_0.15.1 digest_0.6.9 mapproj_1.2-4 labeling_0.3 [16] scales_0.4.0 spacetime_1.1-5 zoo_1.7-12 Spatial line: l1 > str(l1) Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots ..@ data :'data.frame': 1 obs. of 2 variables: .. ..$ OBJECTID : int 1 .. ..$ SHAPE_Leng: num 1043 .. ..- attr(*, "data_types")= chr [1:2] "N" "F" ..@ lines :List of 1 .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots .. .. .. ..@ Lines:List of 1 .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] 642236 643006 6197243 6197948 .. .. .. ..@ ID : chr "0" ..@ bbox : num [1:2, 1:2] 642236 6197243 643006 6197948 .. ..- attr(*, "dimnames")=List of 2 .. .. ..$ : chr [1:2] "x" "y" .. .. ..$ : chr [1:2] "min" "max" ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot .. .. ..@ projargs: chr "+proj=utm +zone=20 +south +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0" Spatial line in geographic coordinates: l1.geo > str(l1.geo) Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots ..@ data :'data.frame': 1 obs. of 2 variables: .. ..$ OBJECTID : int 1 .. ..$ SHAPE_Leng: num 1043 .. ..- attr(*, "data_types")= chr [1:2] "N" "F" ..@ lines :List of 1 .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots .. .. .. ..@ Lines:List of 1 .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] -61.5 -61.4 -34.4 -34.3 .. .. .. ..@ ID : chr "0" ..@ bbox : num [1:2, 1:2] -61.5 -34.4 -61.4 -34.3 .. ..- attr(*, "dimnames")=List of 2 .. .. ..$ : chr [1:2] "x" "y" .. .. ..$ : chr [1:2] "min" "max" ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot .. .. ..@ projargs: chr "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0" Run of maptools::gzAzimuth: > gzAzimuth(from = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], + to = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) [1] 46.52677 Run of geosphere::bearing: bearing(p1 = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], + p2 = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) [1] 46.65786 Angle given by Linear Directional Mean for l1: 47.53076 For l1.geo (in Lat/Lon) the ArcGIS' tool gives a warning that it it should be projected but calculates this angle: WARNING 000916: The input feature class does not appear to contain projected data. 51.94714 I can provide further information or files but i think this can be enough for now. Thanks, Regards 2016-05-25 4:32 GMT-03:00 Roger Bivand : > On Wed, 25 May 2016, Eduardo Diez wrote: > > Dear everyone, >> I'm used to calculating the compass angles (clockwise from due North) of >> line features projected in UTM using the tool Linear Directional Mean >> < >> http://resources.esri.com/help/9.3/arcgisengine/java/gp_toolref/spatial_statistics_tools/how_linear_directional_mean_spatial_statistics_works.htm >> > >> from ArcGIS. >> I could find functions for performing a similar task but taking Origin -> >> Destination points and only in Lat/Lon (geographic coordinates) namely: >> geosphere::bearing and maptools::gzAzimuth. (Somehow they give different >> results for the same set of points: around 0.05 degrees, maybe because of >> the trigonometry) >> Because of the nature of my work it has to be in UTM. >> > > Interesting question. Could you please provide a test set of pairs of > coordinates with the fully qualified UTM projection (which datum in > particular, and if WGS84, which version - there are several), the output > from ArcGIS (which version), and the geographical coordinates you see in > ArcGIS (to remove the possibility that it is a projection issue on the R > side). They don't need to mean anything, only that they can show us what > the problem is in code and numeric terms. A link to an R file and an RDS > file would be helpful. > > Roger > > Perhaps someone skillfull in trigonometry can figure it out but i'm not the >> case. >> Is there a way to do this in R? >> >> Thanks, >> Eduardo >> >> [[alternative HTML version deleted]] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at 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.Bivand at nhh.no > http://orcid.org/0000-0003-2392-6140 > https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en > http://depsy.org/person/434412 > [[alternative HTML version deleted]] From eduardodiez at gmx.com Wed May 25 21:16:34 2016 From: eduardodiez at gmx.com (Eduardo Diez) Date: Wed, 25 May 2016 16:16:34 -0300 Subject: [R-sig-Geo] Bearing angle of UTM projected SpatialLines In-Reply-To: References: Message-ID: I forgot to add the complete coordinates for the line: > l1 at lines[[1]]@Lines[[1]]@coords [,1] [,2] [1,] 642236.2 6197243 [2,] 643005.6 6197948 > l1.geo at lines[[1]]@Lines[[1]]@coords [,1] [,2] [1,] -61.45336 -34.35639 [2,] -61.44511 -34.34994 Thanks 2016-05-25 16:09 GMT-03:00 Eduardo Diez : > Here are some details and example: > > > sessionInfo() > R version 3.2.5 (2016-04-14) > 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] RPyGeo_0.9-3 RSAGA_0.94-5 plyr_1.8.3 > gstat_1.1-3 > [5] shapefiles_0.7 foreign_0.8-66 rgdal_1.1-8 > maptools_0.8-39 > [9] geosphere_1.5-1 ggplot2_2.1.0 raster_2.5-2 > rgeos_0.3-19 > [13] sp_1.2-3 RevoUtilsMath_3.2.5 > > loaded via a namespace (and not attached): > [1] Rcpp_0.12.4 maps_3.1.0 munsell_0.4.3 colorspace_1.2-6 > lattice_0.20-33 > [6] FNN_1.1 xts_0.9-7 tools_3.2.5 parallel_3.2.5 > grid_3.2.5 > [11] gtable_0.2.0 intervals_0.15.1 digest_0.6.9 mapproj_1.2-4 > labeling_0.3 > [16] scales_0.4.0 spacetime_1.1-5 zoo_1.7-12 > > Spatial line: l1 > > str(l1) > Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots > ..@ data :'data.frame': 1 obs. of 2 variables: > .. ..$ OBJECTID : int 1 > .. ..$ SHAPE_Leng: num 1043 > .. ..- attr(*, "data_types")= chr [1:2] "N" "F" > ..@ lines :List of 1 > .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots > .. .. .. ..@ Lines:List of 1 > .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot > .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] 642236 643006 6197243 > 6197948 > .. .. .. ..@ ID : chr "0" > ..@ bbox : num [1:2, 1:2] 642236 6197243 643006 6197948 > .. ..- attr(*, "dimnames")=List of 2 > .. .. ..$ : chr [1:2] "x" "y" > .. .. ..$ : chr [1:2] "min" "max" > ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot > .. .. ..@ projargs: chr "+proj=utm +zone=20 +south +datum=WGS84 +units=m > +no_defs +ellps=WGS84 +towgs84=0,0,0" > > Spatial line in geographic coordinates: l1.geo > > str(l1.geo) > Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots > ..@ data :'data.frame': 1 obs. of 2 variables: > .. ..$ OBJECTID : int 1 > .. ..$ SHAPE_Leng: num 1043 > .. ..- attr(*, "data_types")= chr [1:2] "N" "F" > ..@ lines :List of 1 > .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots > .. .. .. ..@ Lines:List of 1 > .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot > .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] -61.5 -61.4 -34.4 -34.3 > .. .. .. ..@ ID : chr "0" > ..@ bbox : num [1:2, 1:2] -61.5 -34.4 -61.4 -34.3 > .. ..- attr(*, "dimnames")=List of 2 > .. .. ..$ : chr [1:2] "x" "y" > .. .. ..$ : chr [1:2] "min" "max" > ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot > .. .. ..@ projargs: chr "+proj=longlat +datum=WGS84 +no_defs > +ellps=WGS84 +towgs84=0,0,0" > > Run of maptools::gzAzimuth: > > gzAzimuth(from = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], > + to = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) > [1] 46.52677 > > Run of geosphere::bearing: > bearing(p1 = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], > + p2 = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) > [1] 46.65786 > > Angle given by Linear Directional Mean for l1: > 47.53076 > > For l1.geo (in Lat/Lon) the ArcGIS' tool gives a warning that it it should > be projected but calculates this angle: > WARNING 000916: The input feature class does not appear to contain > projected data. > 51.94714 > > I can provide further information or files but i think this can be enough > for now. > Thanks, > Regards > > 2016-05-25 4:32 GMT-03:00 Roger Bivand : > >> On Wed, 25 May 2016, Eduardo Diez wrote: >> >> Dear everyone, >>> I'm used to calculating the compass angles (clockwise from due North) of >>> line features projected in UTM using the tool Linear Directional Mean >>> < >>> http://resources.esri.com/help/9.3/arcgisengine/java/gp_toolref/spatial_statistics_tools/how_linear_directional_mean_spatial_statistics_works.htm >>> > >>> from ArcGIS. >>> I could find functions for performing a similar task but taking Origin -> >>> Destination points and only in Lat/Lon (geographic coordinates) namely: >>> geosphere::bearing and maptools::gzAzimuth. (Somehow they give different >>> results for the same set of points: around 0.05 degrees, maybe because of >>> the trigonometry) >>> Because of the nature of my work it has to be in UTM. >>> >> >> Interesting question. Could you please provide a test set of pairs of >> coordinates with the fully qualified UTM projection (which datum in >> particular, and if WGS84, which version - there are several), the output >> from ArcGIS (which version), and the geographical coordinates you see in >> ArcGIS (to remove the possibility that it is a projection issue on the R >> side). They don't need to mean anything, only that they can show us what >> the problem is in code and numeric terms. A link to an R file and an RDS >> file would be helpful. >> >> Roger >> >> Perhaps someone skillfull in trigonometry can figure it out but i'm not >>> the >>> case. >>> Is there a way to do this in R? >>> >>> Thanks, >>> Eduardo >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at 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.Bivand at nhh.no >> http://orcid.org/0000-0003-2392-6140 >> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en >> http://depsy.org/person/434412 >> > > [[alternative HTML version deleted]] From r.turner at auckland.ac.nz Thu May 26 00:09:04 2016 From: r.turner at auckland.ac.nz (Rolf Turner) Date: Thu, 26 May 2016 10:09:04 +1200 Subject: [R-sig-Geo] [FORGED] Calculate each polygon percentage inside a circles In-Reply-To: <9cfea508-cd7a-a223-df92-389b095f0571@yahoo.com.br> References: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> <332c038d-5a96-4396-d3f5-d7664e3f0c0b@auckland.ac.nz> <9cfea508-cd7a-a223-df92-389b095f0571@yahoo.com.br> Message-ID: On 26/05/16 00:23, ASANTOS wrote: > Dear Rolf Turner, > > It's much better a clean code with a minimum packages, thank > you very much for your answer. But "pct" object give me a total polygon > percentage around each point and I need too an identification (in > columns) of individual contribution of each polygon. In my simulation, I > find 50.38001% for the point 1, but this is a total percentage of > polygons and I'd like to know a percentage contribution for each polygon > (e.g. ID1 = 0.00000 + ID1 = 10.00000 + ID3 = 0.00000 + ID4 = 40.38001 = > 50.38001 total), this is possible? Of course it's possible! This is R. :-) You just need to look at the component polygons as separate window objects and do the same thing to them that I did to the overall "W". There is a small gotcha that has to be coped with when the intersection of the disc with a polygon is empty (as often occurs). (See below.) There is a number of different ways to write the code for this. One way is as follows: ========================================================================== library(spatstat) sr1 <- owin(poly=cbind(c(180114, 180553, 181127, 181477, 181294, 181007, 180409, 180162, 180114), c(332349, 332057, 332342, 333250, 333558, 333676, 332618, 332413, 332349))) sr2 <- owin(poly=cbind(rev(c(180042, 180545, 180553, 180314, 179955, 179142, 179437, 179524, 179979, 180042)), rev(c(332373, 332026, 331426, 330889, 330683, 331133, 331623, 332152, 332357, 332373)))) sr3 <- owin(poly=cbind(rev(c(179110, 179907, 180433, 180712, 180752, 180329, 179875, 179668, 179572, 179269, 178879, 178600, 178544, 179046, 179110)), rev(c(331086, 330620, 330494, 330265, 330075, 330233, 330336, 330004, 329783, 329665, 329720, 329933, 330478, 331062, 331086)))) sr4 <- owin(poly=cbind(c(180304, 180403,179632,179420,180304), c(332791, 333204, 333635, 333058, 332791))) wins <- solist(sr1,sr2,sr3,sr4) W <- union.owin(wins) set.seed(42) X <- rpoispp(28/area.owin(W),win=W) N <- npoints(X) plot(X,cols="blue") AD <- area.owin(disc(radius=600)) pct <- matrix(nrow=N,ncol=4) rownames(pct) <- paste("point",1:N,sep=".") colnames(pct) <- paste("sr",1:4,sep=".") for(i in 1:npoints(X)) { Di <- disc(radius=600,centre=c(X$x[i],X$y[i])) for(j in 1:4) { Aij <- intersect.owin(Di,wins[[j]],fatal=FALSE) pct[i,j] <- if(is.null(Aij)) 0 else 100*area.owin(Aij)/AD } } ========================================================================== HTH cheers, Rolf Turner -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 From Roger.Bivand at nhh.no Thu May 26 12:28:04 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Thu, 26 May 2016 12:28:04 +0200 Subject: [R-sig-Geo] Bearing angle of UTM projected SpatialLines In-Reply-To: References: Message-ID: On Wed, 25 May 2016, Eduardo Diez wrote: > I forgot to add the complete coordinates for the line: > >> l1 at lines[[1]]@Lines[[1]]@coords > [,1] [,2] > [1,] 642236.2 6197243 > [2,] 643005.6 6197948 > >> l1.geo at lines[[1]]@Lines[[1]]@coords > [,1] [,2] > [1,] -61.45336 -34.35639 > [2,] -61.44511 -34.34994 #This was: library(sp) l1c <- cbind(c(642236.2, 643005.6), c(6197243, 6197948)) lgc <- cbind(c(-61.45336, -61.44511), c(-34.35639, -34.34994)) l1 <- SpatialLines(list(Lines(list(Line(l1c)), "1")), proj4string=CRS("+proj=utm +zone=20 +south +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0")) l1.geo <- SpatialLines(list(Lines(list(Line(lgc)), "1")), proj4string=CRS("+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0")) #but the lack of precision (I asked for binary) in the coordinates means #that Arc's: #Angle given by Linear Directional Mean for l1: #47.53076 #becomes: ds <- apply(coordinates(l1)[[1]][[1]], 2, diff) atan2(ds[1], ds[2])*180/pi atan2(ds[1], ds[2]-0.7343)*180/pi #because the rounded difference in Northings is off by 0.7m. #The spherical/ellipsoidal calculations are: library(maptools) gzAzimuth(from = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], to = l1.geo at lines[[1]]@Lines[[1]]@coords[2,], type="snyder_sphere") library(geosphere) bearing(p1 = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], p2 = l1.geo at lines[[1]]@Lines[[1]]@coords[2,], sphere=TRUE) #equal as spherical, with this differeing a little depending where you are #on the globe: bearing(p1 = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], p2 = l1.geo at lines[[1]]@Lines[[1]]@coords[2,], sphere=FALSE) #obviously one is spherical, the other ellipsoidal. Neither are planar, so #are not the same thing anyway. If anyone feels like contributing a function to accept objects rather than raw coordinates for gzAzimuth, and restricting to geographical coordinates, adding a planar direction function, and an LDM function for Lines and SpatialLines objects, or any of these, I'd be grateful. Hope this clarifies, Roger > > Thanks > > 2016-05-25 16:09 GMT-03:00 Eduardo Diez : > >> Here are some details and example: >> >>> sessionInfo() >> R version 3.2.5 (2016-04-14) >> 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] RPyGeo_0.9-3 RSAGA_0.94-5 plyr_1.8.3 >> gstat_1.1-3 >> [5] shapefiles_0.7 foreign_0.8-66 rgdal_1.1-8 >> maptools_0.8-39 >> [9] geosphere_1.5-1 ggplot2_2.1.0 raster_2.5-2 >> rgeos_0.3-19 >> [13] sp_1.2-3 RevoUtilsMath_3.2.5 >> >> loaded via a namespace (and not attached): >> [1] Rcpp_0.12.4 maps_3.1.0 munsell_0.4.3 colorspace_1.2-6 >> lattice_0.20-33 >> [6] FNN_1.1 xts_0.9-7 tools_3.2.5 parallel_3.2.5 >> grid_3.2.5 >> [11] gtable_0.2.0 intervals_0.15.1 digest_0.6.9 mapproj_1.2-4 >> labeling_0.3 >> [16] scales_0.4.0 spacetime_1.1-5 zoo_1.7-12 >> >> Spatial line: l1 >>> str(l1) >> Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots >> ..@ data :'data.frame': 1 obs. of 2 variables: >> .. ..$ OBJECTID : int 1 >> .. ..$ SHAPE_Leng: num 1043 >> .. ..- attr(*, "data_types")= chr [1:2] "N" "F" >> ..@ lines :List of 1 >> .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots >> .. .. .. ..@ Lines:List of 1 >> .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot >> .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] 642236 643006 6197243 >> 6197948 >> .. .. .. ..@ ID : chr "0" >> ..@ bbox : num [1:2, 1:2] 642236 6197243 643006 6197948 >> .. ..- attr(*, "dimnames")=List of 2 >> .. .. ..$ : chr [1:2] "x" "y" >> .. .. ..$ : chr [1:2] "min" "max" >> ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot >> .. .. ..@ projargs: chr "+proj=utm +zone=20 +south +datum=WGS84 +units=m >> +no_defs +ellps=WGS84 +towgs84=0,0,0" >> >> Spatial line in geographic coordinates: l1.geo >>> str(l1.geo) >> Formal class 'SpatialLinesDataFrame' [package "sp"] with 4 slots >> ..@ data :'data.frame': 1 obs. of 2 variables: >> .. ..$ OBJECTID : int 1 >> .. ..$ SHAPE_Leng: num 1043 >> .. ..- attr(*, "data_types")= chr [1:2] "N" "F" >> ..@ lines :List of 1 >> .. ..$ :Formal class 'Lines' [package "sp"] with 2 slots >> .. .. .. ..@ Lines:List of 1 >> .. .. .. .. ..$ :Formal class 'Line' [package "sp"] with 1 slot >> .. .. .. .. .. .. ..@ coords: num [1:2, 1:2] -61.5 -61.4 -34.4 -34.3 >> .. .. .. ..@ ID : chr "0" >> ..@ bbox : num [1:2, 1:2] -61.5 -34.4 -61.4 -34.3 >> .. ..- attr(*, "dimnames")=List of 2 >> .. .. ..$ : chr [1:2] "x" "y" >> .. .. ..$ : chr [1:2] "min" "max" >> ..@ proj4string:Formal class 'CRS' [package "sp"] with 1 slot >> .. .. ..@ projargs: chr "+proj=longlat +datum=WGS84 +no_defs >> +ellps=WGS84 +towgs84=0,0,0" >> >> Run of maptools::gzAzimuth: >>> gzAzimuth(from = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], >> + to = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) >> [1] 46.52677 >> >> Run of geosphere::bearing: >> bearing(p1 = l1.geo at lines[[1]]@Lines[[1]]@coords[1,], >> + p2 = l1.geo at lines[[1]]@Lines[[1]]@coords[2,]) >> [1] 46.65786 >> >> Angle given by Linear Directional Mean for l1: >> 47.53076 >> >> For l1.geo (in Lat/Lon) the ArcGIS' tool gives a warning that it it should >> be projected but calculates this angle: >> WARNING 000916: The input feature class does not appear to contain >> projected data. >> 51.94714 >> >> I can provide further information or files but i think this can be enough >> for now. >> Thanks, >> Regards >> >> 2016-05-25 4:32 GMT-03:00 Roger Bivand : >> >>> On Wed, 25 May 2016, Eduardo Diez wrote: >>> >>> Dear everyone, >>>> I'm used to calculating the compass angles (clockwise from due North) of >>>> line features projected in UTM using the tool Linear Directional Mean >>>> < >>>> http://resources.esri.com/help/9.3/arcgisengine/java/gp_toolref/spatial_statistics_tools/how_linear_directional_mean_spatial_statistics_works.htm >>>>> >>>> from ArcGIS. >>>> I could find functions for performing a similar task but taking Origin -> >>>> Destination points and only in Lat/Lon (geographic coordinates) namely: >>>> geosphere::bearing and maptools::gzAzimuth. (Somehow they give different >>>> results for the same set of points: around 0.05 degrees, maybe because of >>>> the trigonometry) >>>> Because of the nature of my work it has to be in UTM. >>>> >>> >>> Interesting question. Could you please provide a test set of pairs of >>> coordinates with the fully qualified UTM projection (which datum in >>> particular, and if WGS84, which version - there are several), the output >>> from ArcGIS (which version), and the geographical coordinates you see in >>> ArcGIS (to remove the possibility that it is a projection issue on the R >>> side). They don't need to mean anything, only that they can show us what >>> the problem is in code and numeric terms. A link to an R file and an RDS >>> file would be helpful. >>> >>> Roger >>> >>> Perhaps someone skillfull in trigonometry can figure it out but i'm not >>>> the >>>> case. >>>> Is there a way to do this in R? >>>> >>>> Thanks, >>>> Eduardo >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at 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.Bivand at nhh.no >>> http://orcid.org/0000-0003-2392-6140 >>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en >>> http://depsy.org/person/434412 >>> >> >> > -- 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From milujisb at gmail.com Thu May 26 23:31:02 2016 From: milujisb at gmail.com (Miluji Sb) Date: Thu, 26 May 2016 23:31:02 +0200 Subject: [R-sig-Geo] Match Coordinates to NUTS 2 ID Message-ID: Dear all, I have downloaded the NUTS 2 level data from library(?rgdal?) library(?RColorBrewer?) library(?classInt?) #library(?SmarterPoland?) library(fields) # Download Administrative Level data from EuroStat temp <- tempfile(fileext = ".zip") download.file(" http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip ", temp) unzip(temp) # Read data EU_NUTS <- readOGR(dsn = "./NUTS_2010_60M_SH/data", layer = "NUTS_RG_60M_2010") # Subset NUTS 2 level data map_nuts2 <- subset(EU_NUTS, STAT_LEVL_ == 2) I also have data for a variable by coordinates, which looks like this: structure(list(LON = c(-125.25, -124.75, -124.25, -124.25, -124.25, -124.25), LAT = c(49.75, 49.25, 42.75, 43.25, 48.75, 49.25), yr = c(2.91457704560515, 9.94774197180345, -2.71956412885765, -0.466213169185147, -36.6645659563374, 10.5168056769535)), .Names = c("LON", "LAT", "yr"), row.names = c(NA, 6L), class = "data.frame") I would like to match the coordinates to their corresponding NUTS 2 region - is this possible? Any help will be high appreciated. Thank you! Sincerely, Milu [[alternative HTML version deleted]] From alexandresantosbr at yahoo.com.br Fri May 27 02:09:59 2016 From: alexandresantosbr at yahoo.com.br (ASANTOS) Date: Thu, 26 May 2016 20:09:59 -0400 Subject: [R-sig-Geo] [FORGED] Calculate each polygon percentage inside a circles In-Reply-To: References: <611fc046-427e-85ce-6cf9-db049563dcda@yahoo.com.br> <332c038d-5a96-4396-d3f5-d7664e3f0c0b@auckland.ac.nz> <9cfea508-cd7a-a223-df92-389b095f0571@yahoo.com.br> Message-ID: Dear Rolf Turner, Amazing!!!!! I will never put R in doubt. My problem was solved with success, thanks very much again!!! Best wishes, Alexandre -- ====================================================================== Alexandre dos Santos Prote??o Florestal IFMT - Instituto Federal de Educa??o, Ci?ncia e Tecnologia de Mato Grosso Campus C?ceres Caixa Postal 244 Avenida dos Ramires, s/n Bairro: Distrito Industrial C?ceres - MT CEP: 78.200-000 Fone: (+55) 65 8132-8112 (TIM) (+55) 65 9686-6970 (VIVO) alexandre.santos at cas.ifmt.edu.br Lattes: http://lattes.cnpq.br/1360403201088680 OrcID: orcid.org/0000-0001-8232-6722 Researchgate: https://www.researchgate.net/profile/Alexandre_Santos10 LinkedIn: https://br.linkedin.com/in/alexandre-dos-santos-87961635 ====================================================================== Em 25/05/2016 18:09, Rolf Turner escreveu: > ========================================================================== > > library(spatstat) > > sr1 <- owin(poly=cbind(c(180114, 180553, 181127, 181477, 181294, > 181007, 180409, 180162, 180114), > c(332349, 332057, 332342, 333250, 333558, > 333676, 332618, 332413, 332349))) > > sr2 <- owin(poly=cbind(rev(c(180042, 180545, 180553, 180314, 179955, > 179142, 179437, 179524, 179979, 180042)), > rev(c(332373, 332026, 331426, 330889, 330683, > 331133, 331623, 332152, 332357, 332373)))) > > sr3 <- owin(poly=cbind(rev(c(179110, 179907, 180433, 180712, 180752, > 180329, 179875, 179668, 179572, 179269, > 178879, 178600, 178544, 179046, 179110)), > rev(c(331086, 330620, 330494, 330265, 330075, > 330233, 330336, 330004, 329783, 329665, > 329720, 329933, 330478, 331062, 331086)))) > > sr4 <- owin(poly=cbind(c(180304, 180403,179632,179420,180304), > c(332791, 333204, 333635, 333058, 332791))) > > wins <- solist(sr1,sr2,sr3,sr4) > > W <- union.owin(wins) > > set.seed(42) > X <- rpoispp(28/area.owin(W),win=W) > N <- npoints(X) > plot(X,cols="blue") > AD <- area.owin(disc(radius=600)) > > pct <- matrix(nrow=N,ncol=4) > rownames(pct) <- paste("point",1:N,sep=".") > colnames(pct) <- paste("sr",1:4,sep=".") > for(i in 1:npoints(X)) { > Di <- disc(radius=600,centre=c(X$x[i],X$y[i])) > for(j in 1:4) { > Aij <- intersect.owin(Di,wins[[j]],fatal=FALSE) > pct[i,j] <- if(is.null(Aij)) 0 else 100*area.owin(Aij)/AD > } > } > ========================================================================== [[alternative HTML version deleted]] From frtog at vestas.com Fri May 27 07:39:31 2016 From: frtog at vestas.com (=?utf-8?B?RnJlZGUgQWFrbWFubiBUw7hnZXJzZW4=?=) Date: Fri, 27 May 2016 05:39:31 +0000 Subject: [R-sig-Geo] Match Coordinates to NUTS 2 ID In-Reply-To: References: Message-ID: Hi Milu Your original point data is not within the bounding box of your map_nuts2 data: > bbox(point_data) min max LON -125.25 -124.25 LAT 42.75 49.75 > bbox(map_nuts2) min max x -61.74369 55.83663 y -21.37656 71.17308 So I changed the longitudes of your point data only for illustration. This is one way to do it. > library(?rgdal?) Loading required package: sp rgdal: version: 0.9-2, (SVN revision 526) 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: c:/Programmer/R/R-3.1.3/library/rgdal/gdal GDAL does not use iconv for recoding strings. Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491] Path to PROJ.4 shared files: c:/Programmer/R/R-3.1.3/library/rgdal/proj > ## Download Administrative Level data from EuroStat > temp <- tempfile(fileext = ".zip") > download.file("http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip", + temp) trying URL 'http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip' Content type 'application/zip' length 6187118 bytes (5.9 MB) opened URL downloaded 5.9 MB > unzip(temp) > ## Read data > EU_NUTS <- readOGR(dsn = "./NUTS_2010_60M_SH/data", layer = "NUTS_RG_60M_2010") OGR data source with driver: ESRI Shapefile Source: "./NUTS_2010_60M_SH/data", layer: "NUTS_RG_60M_2010" with 1920 features It has 4 fields > ## Subset NUTS 2 level data > map_nuts2 <- subset(EU_NUTS, STAT_LEVL_ == 2) > ## I also have data for a variable by coordinates, which looks like this: > ## edited the longitudes from original example > ## Only you know in which projection these coordinates are > point_data <- structure(list(LON = c(15.25, 16.75, 17.25, 14.25, 14.25, 13.25), + LAT = c(49.75, 49.25, 42.75, 43.25, 48.75, 49.25), + yr = c(2.91457704560515, 9.94774197180345, -2.71956412885765, + -0.466213169185147, -36.6645659563374, 10.5168056769535)), + .Names = c("LON", "LAT", "yr"), row.names = c(NA, 6L), + class = "data.frame") > ## Here is the projection for map_nuts data > proj4string(map_nuts2) [1] "+proj=longlat +ellps=GRS80 +no_defs" > ## Make a spatial points dataframe from point_data > ## Assuming the projection to be longlat on the WGS84 datum > ## First define the coordinates > coordinates(point_data) <- ~LON + LAT > ## Then the projection > proj4string(point_data) <- CRS("+proj=longlat +datum=WGS84") > ## Now transform the projection of point_data to that of map_nuts2 > point_data <- spTransform(point_data, proj4string(map_nuts2)) > ## Check the bounding boxes > bbox(map_nuts2) min max x -61.74369 55.83663 y -21.37656 71.17308 > bbox(point_data) min max LON 13.25 17.25 LAT 42.75 49.75 > ## Visualize data > ## Two points seem to be in the ocean > plot(map_nuts2) > plot(point_data, add = TRUE, col = "red", pch = 19) > ## Use the over() function to get the regions for the points > ## No regions for 2 points in the ocean > over(point_data, map_nuts2, by.id = TRUE) NUTS_ID STAT_LEVL_ SHAPE_Leng SHAPE_Area 1 CZ06 2 7.018153 1.688086 2 CZ06 2 7.018153 1.688086 3 NA NA NA 4 NA NA NA 5 CZ03 2 8.350082 2.222739 6 CZ03 2 8.350082 2.222739 > Yours sincerely / Med venlig hilsen Frede Aakmann T?gersen Specialist, M.Sc., Ph.D. Plant Performance & Modeling Technology & Service Solutions T +45 9730 5135 M +45 2547 6050 frtog at vestas.com http://www.vestas.com Company reg. name: Vestas Wind Systems A/S This e-mail is subject to our e-mail disclaimer statement. Please refer to www.vestas.com/legal/notice If you have received this e-mail in error please contact the sender. -----Original Message----- From: R-sig-Geo [mailto:r-sig-geo-bounces at r-project.org] On Behalf Of Miluji Sb Sent: 26. maj 2016 23:31 To: R-sig-geo mailing list Subject: [R-sig-Geo] Match Coordinates to NUTS 2 ID Dear all, I have downloaded the NUTS 2 level data from library(?rgdal?) library(?RColorBrewer?) library(?classInt?) #library(?SmarterPoland?) library(fields) # Download Administrative Level data from EuroStat temp <- tempfile(fileext = ".zip") download.file(" http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip ", temp) unzip(temp) # Read data EU_NUTS <- readOGR(dsn = "./NUTS_2010_60M_SH/data", layer = "NUTS_RG_60M_2010") # Subset NUTS 2 level data map_nuts2 <- subset(EU_NUTS, STAT_LEVL_ == 2) I also have data for a variable by coordinates, which looks like this: structure(list(LON = c(-125.25, -124.75, -124.25, -124.25, -124.25, -124.25), LAT = c(49.75, 49.25, 42.75, 43.25, 48.75, 49.25), yr = c(2.91457704560515, 9.94774197180345, -2.71956412885765, -0.466213169185147, -36.6645659563374, 10.5168056769535)), .Names = c("LON", "LAT", "yr"), row.names = c(NA, 6L), class = "data.frame") I would like to match the coordinates to their corresponding NUTS 2 region - is this possible? Any help will be high appreciated. Thank you! Sincerely, Milu [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo From milujisb at gmail.com Fri May 27 10:42:15 2016 From: milujisb at gmail.com (Miluji Sb) Date: Fri, 27 May 2016 10:42:15 +0200 Subject: [R-sig-Geo] Match Coordinates to NUTS 2 ID In-Reply-To: References: Message-ID: Dear Dr. T?gersen, Thank you very much for your reply. I really appreciate it - I am following your suggestions but I get "NA" after the match here: over(point_data, map_nuts2, by.id = TRUE) I am trying to find what the problem is at my end. Thanks again! Sincerely, Milu On Fri, May 27, 2016 at 7:39 AM, Frede Aakmann T?gersen wrote: > Hi Milu > > Your original point data is not within the bounding box of your map_nuts2 > data: > > > bbox(point_data) > min max > LON -125.25 -124.25 > LAT 42.75 49.75 > > bbox(map_nuts2) > min max > x -61.74369 55.83663 > y -21.37656 71.17308 > > So I changed the longitudes of your point data only for illustration. This > is one way to do it. > > > library(?rgdal?) > Loading required package: sp > rgdal: version: 0.9-2, (SVN revision 526) > 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: c:/Programmer/R/R-3.1.3/library/rgdal/gdal > GDAL does not use iconv for recoding strings. > Loaded PROJ.4 runtime: Rel. 4.9.1, 04 March 2015, [PJ_VERSION: 491] > Path to PROJ.4 shared files: c:/Programmer/R/R-3.1.3/library/rgdal/proj > > > ## Download Administrative Level data from EuroStat > > temp <- tempfile(fileext = ".zip") > > download.file(" > http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip > ", > + temp) > trying URL ' > http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip > ' > Content type 'application/zip' length 6187118 bytes (5.9 MB) > opened URL > downloaded 5.9 MB > > > unzip(temp) > > > ## Read data > > EU_NUTS <- readOGR(dsn = "./NUTS_2010_60M_SH/data", layer = > "NUTS_RG_60M_2010") > OGR data source with driver: ESRI Shapefile > Source: "./NUTS_2010_60M_SH/data", layer: "NUTS_RG_60M_2010" > with 1920 features > It has 4 fields > > > ## Subset NUTS 2 level data > > map_nuts2 <- subset(EU_NUTS, STAT_LEVL_ == 2) > > > ## I also have data for a variable by coordinates, which looks like this: > > ## edited the longitudes from original example > > ## Only you know in which projection these coordinates are > > point_data <- structure(list(LON = c(15.25, 16.75, 17.25, 14.25, 14.25, > 13.25), > + LAT = c(49.75, 49.25, 42.75, 43.25, 48.75, > 49.25), > + yr = c(2.91457704560515, 9.94774197180345, > -2.71956412885765, > + -0.466213169185147, -36.6645659563374, > 10.5168056769535)), > + .Names = c("LON", "LAT", "yr"), row.names = > c(NA, 6L), > + class = "data.frame") > > > ## Here is the projection for map_nuts data > > proj4string(map_nuts2) > [1] "+proj=longlat +ellps=GRS80 +no_defs" > > > ## Make a spatial points dataframe from point_data > > ## Assuming the projection to be longlat on the WGS84 datum > > ## First define the coordinates > > coordinates(point_data) <- ~LON + LAT > > ## Then the projection > > proj4string(point_data) <- CRS("+proj=longlat +datum=WGS84") > > > ## Now transform the projection of point_data to that of map_nuts2 > > point_data <- spTransform(point_data, proj4string(map_nuts2)) > > > ## Check the bounding boxes > > bbox(map_nuts2) > min max > x -61.74369 55.83663 > y -21.37656 71.17308 > > bbox(point_data) > min max > LON 13.25 17.25 > LAT 42.75 49.75 > > > ## Visualize data > > ## Two points seem to be in the ocean > > plot(map_nuts2) > > plot(point_data, add = TRUE, col = "red", pch = 19) > > > ## Use the over() function to get the regions for the points > > ## No regions for 2 points in the ocean > > over(point_data, map_nuts2, by.id = TRUE) > NUTS_ID STAT_LEVL_ SHAPE_Leng SHAPE_Area > 1 CZ06 2 7.018153 1.688086 > 2 CZ06 2 7.018153 1.688086 > 3 NA NA NA > 4 NA NA NA > 5 CZ03 2 8.350082 2.222739 > 6 CZ03 2 8.350082 2.222739 > > > > Yours sincerely / Med venlig hilsen > > Frede Aakmann T?gersen > Specialist, M.Sc., Ph.D. > Plant Performance & Modeling > > Technology & Service Solutions > T +45 9730 5135 > M +45 2547 6050 > frtog at vestas.com > http://www.vestas.com > > Company reg. name: Vestas Wind Systems A/S > This e-mail is subject to our e-mail disclaimer statement. > Please refer to www.vestas.com/legal/notice > If you have received this e-mail in error please contact the sender. > > > > -----Original Message----- > From: R-sig-Geo [mailto:r-sig-geo-bounces at r-project.org] On Behalf Of > Miluji Sb > Sent: 26. maj 2016 23:31 > To: R-sig-geo mailing list > Subject: [R-sig-Geo] Match Coordinates to NUTS 2 ID > > Dear all, > > > I have downloaded the NUTS 2 level data from > library(?rgdal?) > library(?RColorBrewer?) > library(?classInt?) > #library(?SmarterPoland?) > library(fields) > > # Download Administrative Level data from EuroStat > temp <- tempfile(fileext = ".zip") > download.file(" > http://ec.europa.eu/eurostat/cache/GISCO/geodatafiles/NUTS_2010_60M_SH.zip > ", > temp) > unzip(temp) > > # Read data > EU_NUTS <- readOGR(dsn = "./NUTS_2010_60M_SH/data", layer = > "NUTS_RG_60M_2010") > > # Subset NUTS 2 level data > map_nuts2 <- subset(EU_NUTS, STAT_LEVL_ == 2) > > I also have data for a variable by coordinates, which looks like this: > > structure(list(LON = c(-125.25, -124.75, -124.25, -124.25, -124.25, > -124.25), LAT = c(49.75, 49.25, 42.75, 43.25, 48.75, 49.25), > yr = c(2.91457704560515, 9.94774197180345, -2.71956412885765, > -0.466213169185147, -36.6645659563374, 10.5168056769535)), .Names = > c("LON", > "LAT", "yr"), row.names = c(NA, 6L), class = "data.frame") > > I would like to match the coordinates to their corresponding NUTS 2 region > - is this possible? Any help will be high appreciated. Thank you! > > Sincerely, > > Milu > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > [[alternative HTML version deleted]] From didier.leibovici at nottingham.ac.uk Fri May 27 13:51:22 2016 From: didier.leibovici at nottingham.ac.uk (Dr Didier G. Leibovici) Date: Fri, 27 May 2016 12:51:22 +0100 Subject: [R-sig-Geo] R on Mac building up memory usage Message-ID: <4dc12b38-7cfb-5533-0470-ff048f70b83a@nottingham.ac.uk> Hi, I guess this may be not a specificity of r-sig-geo but as I am using library(rgdal) library(rgeos) in this script so it may be the reason? (perhaps I should try running something else to check). So basically I am running some code reading 61288 features and other things ... if I run it once I got in gc(): > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1833926 98.0 5103933 272.6 9968622 532.4 Vcells 2437534 18.6 7056348 53.9 11036325 84.3 and on the monitor it says R is using 3.3Go. Then I remove everything rm(list=ls()) and run it again trying different sets of parameters for example. Second run similar gc() but R is using 6.4Go > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1834325 98.0 6323353 337.8 9968622 532.4 Vcells 2439267 18.7 7572947 57.8 11832730 90.3 After a while and few other computation I get R is using 10Go and gc() gives > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 1863272 99.6 5944937 317.5 9968622 532.4 Vcells 2503503 19.2 8462995 64.6 100858653 769.5 rm(list=ls()) > ls() character(0) >gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 608451 32.5 4755949 254.0 9968622 532.4 Vcells 760517 5.9 6770396 51.7 100858653 769.5 but still 10Go for R in the monitor. I had experienced a building up to 50Go then my system tells me to close some apps, all that doing the same running one set, then rm(list=ls()) ... So at the moment I just have to close and re-start R? Didier -- Dr Didier G. Leibovici d-d'ye ley-bow-v-c Senior Research Fellow Geocomputational Modelling & Geospatial Statistics Nottingham Geospatial Institute University of Nottingham, UK +44 (0)115 84 13924 http://www.nottingham.ac.uk/ngi/people/didier.leibovici Google+ didier.leibovici at gmail.com Skype didierleibovici [[alternative HTML version deleted]] From nell.redu at hotmail.fr Fri May 27 19:05:33 2016 From: nell.redu at hotmail.fr (Nelly Reduan) Date: Fri, 27 May 2016 17:05:33 +0000 Subject: [R-sig-Geo] Building a prediction raster when the statistical model was built from sampling units of different sizes Message-ID: Hello, I would like to build a predictive map of capture success from a GAM. To build the GAM, I used data of capture success (dependent variable in the model) and proportions of land cover types (independent variables in the model) that were estimated within 50 trapping sites (thus, sample size = 50 observations). The size of trapping sites is ranged from 24 km? to 236 km? (mean = 133 km?). I tested whether or not the capture success varied between the trapping sites and the capture success didn't vary between the sites. Is it statistically correct to create a prediction raster map with cells of equal size given that the trapping sites are of different sizes? If it's correct, should I use raster cells of 5 km x 5 km based on the minimum size of trapping sizes or 16 km x 16 km based on the maximum size or 12 km x km based on the mean size ? If it's not correct, what should I do? Instead of calculating proportions of land cover types within trapping sites, should I calculate the proportions within a buffer around the centroid of trapping sites? Thank you very much for your time. Have nice day. Nell [[alternative HTML version deleted]] From Roger.Bivand at nhh.no Fri May 27 20:20:07 2016 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Fri, 27 May 2016 20:20:07 +0200 Subject: [R-sig-Geo] R on Mac building up memory usage In-Reply-To: <4dc12b38-7cfb-5533-0470-ff048f70b83a@nottingham.ac.uk> References: <4dc12b38-7cfb-5533-0470-ff048f70b83a@nottingham.ac.uk> Message-ID: On Fri, 27 May 2016, Dr Didier G. Leibovici wrote: > Hi, > > I guess this may be not a specificity of r-sig-geo but as I am using > library(rgdal) > library(rgeos) > > in this script so it may be the reason? (perhaps I should try running > something else to check). > Hi Didier, Trying a bare bones script may be sensible. There shouldn't be anything in those packages that creates these effects as such. How many cores are running R simultaneously? There shouldn't be anything OSX-specific either, though memory management varies across platforms (there was a recent discussion on R-devel about this). So if you could share such a bare-bones script and simulated data setup, others might be able to contribute. Best wishes, Roger > > So basically I am running some code reading 61288 features and other > things ... if I run it once I got in gc(): > > gc() > used (Mb) gc trigger (Mb) max used (Mb) > Ncells 1833926 98.0 5103933 272.6 9968622 532.4 > Vcells 2437534 18.6 7056348 53.9 11036325 84.3 > > and on the monitor it says R is using 3.3Go. > > Then I remove everything rm(list=ls()) and run it again trying different > sets of parameters for example. > Second run similar gc() but R is using 6.4Go > > gc() > used (Mb) gc trigger (Mb) max used (Mb) > Ncells 1834325 98.0 6323353 337.8 9968622 532.4 > Vcells 2439267 18.7 7572947 57.8 11832730 90.3 > > > After a while and few other computation I get R is using 10Go > and gc() gives > > gc() > used (Mb) gc trigger (Mb) max used (Mb) > Ncells 1863272 99.6 5944937 317.5 9968622 532.4 > Vcells 2503503 19.2 8462995 64.6 100858653 769.5 > rm(list=ls()) > > ls() > character(0) > >gc() > used (Mb) gc trigger (Mb) max used (Mb) > Ncells 608451 32.5 4755949 254.0 9968622 532.4 > Vcells 760517 5.9 6770396 51.7 100858653 769.5 > > but still 10Go for R in the monitor. > I had experienced a building up to 50Go then my system tells me to close > some apps, all that doing the same running one set, then rm(list=ls()) > ... So at the moment I just have to close and re-start R? > > Didier > > -- 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.Bivand at nhh.no http://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en http://depsy.org/person/434412 From bfalevlist at gmail.com Fri May 27 22:06:37 2016 From: bfalevlist at gmail.com (=?UTF-8?Q?Bede-Fazekas_=c3=81kos?=) Date: Fri, 27 May 2016 22:06:37 +0200 Subject: [R-sig-Geo] R on Mac building up memory usage In-Reply-To: References: <4dc12b38-7cfb-5533-0470-ff048f70b83a@nottingham.ac.uk> Message-ID: <26e9e94c-984e-63f4-bd15-8678533aa384@gmail.com> Hello Didier, only restarting R can really free up memory. This is a typical issue on some operating systems. "Why is R apparently not releasing memory? [...] This is an artifact of the way the operating system (OS) allocates memory. In general it is common that the OS is not capable of releasing all unused memory. In extreme cases it is possible that even if R frees almost all its memory, the OS can not release any of it due to its design and thus tools such as ps or top will report substantial amount of resident RAM used by the R process even though R has released all that memory. [...] The short answer is that this is a limitation of the memory allocator in the operating system and there is nothing R can do about it." See details here: http://www.hep.by/gnu/r-patched/r-faq/R-FAQ_93.html Best wishes, ?kos 2016.05.27. 20:20 keltez?ssel, Roger Bivand ?rta: > On Fri, 27 May 2016, Dr Didier G. Leibovici wrote: > >> Hi, >> >> I guess this may be not a specificity of r-sig-geo but as I am using >> library(rgdal) >> library(rgeos) >> >> in this script so it may be the reason? (perhaps I should try running >> something else to check). >> > > Hi Didier, > > Trying a bare bones script may be sensible. There shouldn't be > anything in those packages that creates these effects as such. How > many cores are running R simultaneously? There shouldn't be anything > OSX-specific either, though memory management varies across platforms > (there was a recent discussion on R-devel about this). > > So if you could share such a bare-bones script and simulated data > setup, others might be able to contribute. > > Best wishes, > > Roger > >> >> So basically I am running some code reading 61288 features and other >> things ... if I run it once I got in gc(): >> > gc() >> used (Mb) gc trigger (Mb) max used (Mb) >> Ncells 1833926 98.0 5103933 272.6 9968622 532.4 >> Vcells 2437534 18.6 7056348 53.9 11036325 84.3 >> >> and on the monitor it says R is using 3.3Go. >> >> Then I remove everything rm(list=ls()) and run it again trying different >> sets of parameters for example. >> Second run similar gc() but R is using 6.4Go >> > gc() >> used (Mb) gc trigger (Mb) max used (Mb) >> Ncells 1834325 98.0 6323353 337.8 9968622 532.4 >> Vcells 2439267 18.7 7572947 57.8 11832730 90.3 >> >> >> After a while and few other computation I get R is using 10Go >> and gc() gives >> > gc() >> used (Mb) gc trigger (Mb) max used (Mb) >> Ncells 1863272 99.6 5944937 317.5 9968622 532.4 >> Vcells 2503503 19.2 8462995 64.6 100858653 769.5 >> rm(list=ls()) >> > ls() >> character(0) >> >gc() >> used (Mb) gc trigger (Mb) max used (Mb) >> Ncells 608451 32.5 4755949 254.0 9968622 532.4 >> Vcells 760517 5.9 6770396 51.7 100858653 769.5 >> >> but still 10Go for R in the monitor. >> I had experienced a building up to 50Go then my system tells me to close >> some apps, all that doing the same running one set, then rm(list=ls()) >> ... So at the moment I just have to close and re-start R? >> >> Didier >> >> > [[alternative HTML version deleted]] From edzer.pebesma at uni-muenster.de Fri May 27 23:33:56 2016 From: edzer.pebesma at uni-muenster.de (Edzer Pebesma) Date: Fri, 27 May 2016 23:33:56 +0200 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines In-Reply-To: <5745AE6B.3070208@uclouvain.be> References: <5745AE6B.3070208@uclouvain.be> Message-ID: <5748BD44.1080507@uni-muenster.de> Thanks for the clear example. I can reproduce this, but don't know how to solve it. If I create a similar example on the unit square, things work fine. The different outputs of geos::gRelate() indicate the problem (script below): > rgeos::gRelate(Inter, PolyD, byid = TRUE) # your example: 1 1 1 2 1 "1FF00F212" "1010F0212" 2 "FF1FF0212" "101F00212" > rgeos::gRelate(Inter2, PolyD2, byid = TRUE) # simplified numbers: 1 1 1 2 1 "1FFF0F212" "FF1F00212" 2 "FF1F00212" "1FFF0F212" Is it possible that this relates to the scale factor of GEOS? # script: library(sp) matrix1 <- cbind(x= c(0, 1, 1, 0), y= c(2, 2, 0, 0)) # Simplified! matrix2 <- cbind(x= c(1, 2, 2, 1), y= c(2, 2, 0, 0)) par(mfrow = c(2,1)) P1 <- Polygon (matrix1) P2 <- Polygon (matrix2) Ps1 <- Polygons (list(P1), 1 ) Ps2 <- Polygons (list(P2), 2 ) Poly <- SpatialPolygons (list (Ps1, Ps2)) data <- data.frame( Attribute = c("1black", "2red") ) PolyD2 <- SpatialPolygonsDataFrame(Poly , data = data ) matrix3 <- cbind(x= c(0, 2), y= c(0.5, 0.5)) L <- Line(matrix3) Ls <- Lines(list(L), "1") Line <- SpatialLines( list(Ls)) Inter2 <- rgeos::gIntersection(Line,PolyD2, byid=T) plot(PolyD2, col = PolyD2$Attribute, axes =TRUE) lines( Inter2[1], col = "green", lwd = 3 ) lines( Inter2[2], col = "blue", lwd = 3 ) over(Inter2[1], PolyD2, byid=T) # The green (1st) segment intersects with the black (1st) polygon => good over(Inter2[2], PolyD2, byid=T) # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, 104030, 103733, 103733)) matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, 104030, 103733, 103733)) P1 <- Polygon (matrix1) P2 <- Polygon (matrix2) Ps1 <- Polygons (list(P1), 1 ) Ps2 <- Polygons (list(P2), 2 ) Poly <- SpatialPolygons (list (Ps1, Ps2)) data <- data.frame( Attribute = c("1black", "2red") ) PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) plot(PolyD, col = PolyD$Attribute, axes =TRUE) matrix3 <- cbind(x= c(250300, 250666), y= c(103900, 103900)) L <- Line(matrix3) Ls <- Lines(list(L), "1") Line <- SpatialLines( list(Ls)) Inter <- rgeos::gIntersection(Line,PolyD, byid=T) lines( Inter[1], col = "green", lwd = 3 ) lines( Inter[2], col = "blue", lwd = 3 ) over(Inter[1], PolyD, byid=T) # The green (1st) segment intersects with the black (1st) polygon => good over(Inter[2], PolyD, byid=T) # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK over(Inter[2], PolyD, byid=T, returnList = TRUE) # illustrate the problem: rgeos::gRelate(Inter, PolyD, byid = TRUE) rgeos::gRelate(Inter2, PolyD2, byid = TRUE) There's also an in-line comment below: On 25/05/16 15:53, Gwenna?l Bataille wrote: > Dear all, > > I can't find a solution for the following problem: > > When I first intersect a line with 2 polygons (splitting it into 2 > segments) and then use an overlay to get for each segment the attribute > of the overlapping polygon, I sometimes get too answers (i.e. a small > point overlapping one polygon, the rest of the segment overlapping another). > > The functions I use for this are: > > rgeos::gIntersection > > and sp::over > > Do you have any idea how I could get the attribute of the polygon the > segments are "mostly overlapping"? > > Below is a reproductible example. > > Thank you very much in advance for any hint on this. > > Best regards, > > Gwenna?l > > > > Reproductible example: > > matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), > > y= c(104030, 104030, 103733, 103733)) > > matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), > > y= c(104030, 104030, 103733, 103733)) > > P1 <- Polygon (matrix1) > > P2 <- Polygon (matrix2) > > Ps1 <- Polygons (list(P1), 1 ) > > Ps2 <- Polygons (list(P2), 2 ) > > Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat > +datum=WGS84")) this proj4string doesn't make sense for such coordinates. > > data <- data.frame( Attribute = c("1black", "2red") ) > > PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) > > plot(PolyD, col = PolyD$Attribute) > > matrix3 <- cbind(x= c(250300, 250666), > > y= c(103900, 103900)) > > L <- Line(matrix3) > > Ls <- Lines(list(L), "1") > > Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat > +datum=WGS84") ) > > Inter <- rgeos::gIntersection(Line,PolyD, byid=T) > > lines( Inter[1], col = "green", lwd = 3 ) > > lines( Inter[2], col = "blue", lwd = 3 ) > > over(Inter[1], PolyD, byid=T) > > 'Attribute > > 11black' > > # The green (1st) segment intersects with the black (1st) polygon => good > > over(Inter[2], PolyD, byid=T) > > 'Attribute > > 11black' > > # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! > > over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK > > over(Inter[2], PolyD, byid=T, returnList = TRUE) > > '[[1]] > > Attribute > > 11black > > 22red' > > # The blue(2nd) segment appears to intersect the two polygons (I guess > one point in common with the first polygon; the rest of the segment > overlapping the other polygon) > > > > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From vijaylulla at gmail.com Sat May 28 00:21:42 2016 From: vijaylulla at gmail.com (Vijay Lulla) Date: Fri, 27 May 2016 18:21:42 -0400 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines In-Reply-To: <5748BD44.1080507@uni-muenster.de> References: <5745AE6B.3070208@uclouvain.be> <5748BD44.1080507@uni-muenster.de> Message-ID: Edzer, I'm having trouble replicating what you state. Below is from my R session. ### Start R session interaction > over(Inter2[1], PolyD2, byid=T) Attribute 1 1black > # The green (1st) segment intersects with the black (1st) polygon => good > over(Inter2[2], PolyD2, byid=T) # Still not ok! Attribute 1 1black > # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! > over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! [[1]] Attribute 1 1black > over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! [[1]] Attribute 2 2red > over(Inter2[1], PolyD2, byid=T, returnList=TRUE) > > > over(Inter2[1], PolyD2, byid=T, returnList=TRUE) [[1]] Attribute 1 1black 2 2red > over(Inter2[2], PolyD2, byid=T, returnList=TRUE) [[1]] Attribute 1 1black 2 2red ### End R session By the way, what is the minDimension argument in `over` function? Why do we need it? Also, where can I read about it? I cannot find it in ?over. Thanks, Vijay. On Fri, May 27, 2016 at 5:33 PM, Edzer Pebesma wrote: > Thanks for the clear example. I can reproduce this, but don't know how > to solve it. If I create a similar example on the unit square, things > work fine. The different outputs of geos::gRelate() indicate the problem > (script below): > >> rgeos::gRelate(Inter, PolyD, byid = TRUE) # your example: > 1 1 1 2 > 1 "1FF00F212" "1010F0212" > 2 "FF1FF0212" "101F00212" > >> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) # simplified numbers: > 1 1 1 2 > 1 "1FFF0F212" "FF1F00212" > 2 "FF1F00212" "1FFF0F212" > > Is it possible that this relates to the scale factor of GEOS? > > # script: > library(sp) > matrix1 <- cbind(x= c(0, 1, 1, 0), y= c(2, 2, 0, 0)) # Simplified! > matrix2 <- cbind(x= c(1, 2, 2, 1), y= c(2, 2, 0, 0)) > > par(mfrow = c(2,1)) > > P1 <- Polygon (matrix1) > P2 <- Polygon (matrix2) > Ps1 <- Polygons (list(P1), 1 ) > Ps2 <- Polygons (list(P2), 2 ) > Poly <- SpatialPolygons (list (Ps1, Ps2)) > data <- data.frame( Attribute = c("1black", "2red") ) > PolyD2 <- SpatialPolygonsDataFrame(Poly , data = data ) > matrix3 <- cbind(x= c(0, 2), y= c(0.5, 0.5)) > L <- Line(matrix3) > Ls <- Lines(list(L), "1") > Line <- SpatialLines( list(Ls)) > Inter2 <- rgeos::gIntersection(Line,PolyD2, byid=T) > plot(PolyD2, col = PolyD2$Attribute, axes =TRUE) > lines( Inter2[1], col = "green", lwd = 3 ) > lines( Inter2[2], col = "blue", lwd = 3 ) > over(Inter2[1], PolyD2, byid=T) > # The green (1st) segment intersects with the black (1st) polygon => good > over(Inter2[2], PolyD2, byid=T) > # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! > over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! > over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! > > matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, > 104030, 103733, 103733)) > matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, > 104030, 103733, 103733)) > P1 <- Polygon (matrix1) > P2 <- Polygon (matrix2) > Ps1 <- Polygons (list(P1), 1 ) > Ps2 <- Polygons (list(P2), 2 ) > Poly <- SpatialPolygons (list (Ps1, Ps2)) > data <- data.frame( Attribute = c("1black", "2red") ) > PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) > plot(PolyD, col = PolyD$Attribute, axes =TRUE) > matrix3 <- cbind(x= c(250300, 250666), > y= c(103900, 103900)) > L <- Line(matrix3) > Ls <- Lines(list(L), "1") > Line <- SpatialLines( list(Ls)) > Inter <- rgeos::gIntersection(Line,PolyD, byid=T) > lines( Inter[1], col = "green", lwd = 3 ) > lines( Inter[2], col = "blue", lwd = 3 ) > over(Inter[1], PolyD, byid=T) > # The green (1st) segment intersects with the black (1st) polygon => good > over(Inter[2], PolyD, byid=T) > # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! > over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK > over(Inter[2], PolyD, byid=T, returnList = TRUE) > > # illustrate the problem: > rgeos::gRelate(Inter, PolyD, byid = TRUE) > rgeos::gRelate(Inter2, PolyD2, byid = TRUE) > > > There's also an in-line comment below: > > > On 25/05/16 15:53, Gwenna?l Bataille wrote: >> Dear all, >> >> I can't find a solution for the following problem: >> >> When I first intersect a line with 2 polygons (splitting it into 2 >> segments) and then use an overlay to get for each segment the attribute >> of the overlapping polygon, I sometimes get too answers (i.e. a small >> point overlapping one polygon, the rest of the segment overlapping another). >> >> The functions I use for this are: >> >> rgeos::gIntersection >> >> and sp::over >> >> Do you have any idea how I could get the attribute of the polygon the >> segments are "mostly overlapping"? >> >> Below is a reproductible example. >> >> Thank you very much in advance for any hint on this. >> >> Best regards, >> >> Gwenna?l >> >> >> >> Reproductible example: >> >> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), >> >> y= c(104030, 104030, 103733, 103733)) >> >> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), >> >> y= c(104030, 104030, 103733, 103733)) >> >> P1 <- Polygon (matrix1) >> >> P2 <- Polygon (matrix2) >> >> Ps1 <- Polygons (list(P1), 1 ) >> >> Ps2 <- Polygons (list(P2), 2 ) >> >> Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat >> +datum=WGS84")) > > this proj4string doesn't make sense for such coordinates. > >> >> data <- data.frame( Attribute = c("1black", "2red") ) >> >> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >> >> plot(PolyD, col = PolyD$Attribute) >> >> matrix3 <- cbind(x= c(250300, 250666), >> >> y= c(103900, 103900)) >> >> L <- Line(matrix3) >> >> Ls <- Lines(list(L), "1") >> >> Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat >> +datum=WGS84") ) >> >> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >> >> lines( Inter[1], col = "green", lwd = 3 ) >> >> lines( Inter[2], col = "blue", lwd = 3 ) >> >> over(Inter[1], PolyD, byid=T) >> >> 'Attribute >> >> 11black' >> >> # The green (1st) segment intersects with the black (1st) polygon => good >> >> over(Inter[2], PolyD, byid=T) >> >> 'Attribute >> >> 11black' >> >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >> >> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >> >> over(Inter[2], PolyD, byid=T, returnList = TRUE) >> >> '[[1]] >> >> Attribute >> >> 11black >> >> 22red' >> >> # The blue(2nd) segment appears to intersect the two polygons (I guess >> one point in common with the first polygon; the rest of the segment >> overlapping the other polygon) >> >> >> >> >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at 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 > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo From edzer.pebesma at uni-muenster.de Sat May 28 12:15:44 2016 From: edzer.pebesma at uni-muenster.de (Edzer Pebesma) Date: Sat, 28 May 2016 12:15:44 +0200 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines In-Reply-To: References: <5745AE6B.3070208@uclouvain.be> <5748BD44.1080507@uni-muenster.de> Message-ID: <57496FD0.4090005@uni-muenster.de> On 28/05/16 00:21, Vijay Lulla wrote: > Edzer, > I'm having trouble replicating what you state. Below is from my R session. I don't see what it is you have trouble with (except lacking documentation) > > ### Start R session interaction > >> over(Inter2[1], PolyD2, byid=T) > Attribute > 1 1black >> # The green (1st) segment intersects with the black (1st) polygon => good >> over(Inter2[2], PolyD2, byid=T) # Still not ok! > Attribute > 1 1black >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! > # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! > [[1]] > Attribute > 1 1black > >> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! > [[1]] > Attribute > 2 2red > >> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) >> >> >> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) > [[1]] > Attribute > 1 1black > 2 2red > >> over(Inter2[2], PolyD2, byid=T, returnList=TRUE) > [[1]] > Attribute > 1 1black > 2 2red > > ### End R session > > By the way, what is the minDimension argument in `over` function? Why > do we need it? Also, where can I read about it? I cannot find it in > ?over. Sorry, my mistake. You'll find details in vignette("over") over() finds intersections without ordering them, so if a line overlaps polygon A but touches polygon B, it might as well return polygon B as your match, where you were hoping for polygon A. With minDimension = 1 the dimensionality of the intersection (read the help of rgeos::gRelate) needs to be at least one, so touching (a point: 0-dimensional) is ignored, and polygon A would be returned. minDimension is now 0 by default; other values might make more sense, depending on the geometries at hand. A problem is that this increases the computational burden quite a bit (requiring gRelate instead of gIntersects). > > Thanks, > Vijay. > > On Fri, May 27, 2016 at 5:33 PM, Edzer Pebesma > wrote: >> Thanks for the clear example. I can reproduce this, but don't know how >> to solve it. If I create a similar example on the unit square, things >> work fine. The different outputs of geos::gRelate() indicate the problem >> (script below): >> >>> rgeos::gRelate(Inter, PolyD, byid = TRUE) # your example: >> 1 1 1 2 >> 1 "1FF00F212" "1010F0212" >> 2 "FF1FF0212" "101F00212" >> >>> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) # simplified numbers: >> 1 1 1 2 >> 1 "1FFF0F212" "FF1F00212" >> 2 "FF1F00212" "1FFF0F212" >> >> Is it possible that this relates to the scale factor of GEOS? >> >> # script: >> library(sp) >> matrix1 <- cbind(x= c(0, 1, 1, 0), y= c(2, 2, 0, 0)) # Simplified! >> matrix2 <- cbind(x= c(1, 2, 2, 1), y= c(2, 2, 0, 0)) >> >> par(mfrow = c(2,1)) >> >> P1 <- Polygon (matrix1) >> P2 <- Polygon (matrix2) >> Ps1 <- Polygons (list(P1), 1 ) >> Ps2 <- Polygons (list(P2), 2 ) >> Poly <- SpatialPolygons (list (Ps1, Ps2)) >> data <- data.frame( Attribute = c("1black", "2red") ) >> PolyD2 <- SpatialPolygonsDataFrame(Poly , data = data ) >> matrix3 <- cbind(x= c(0, 2), y= c(0.5, 0.5)) >> L <- Line(matrix3) >> Ls <- Lines(list(L), "1") >> Line <- SpatialLines( list(Ls)) >> Inter2 <- rgeos::gIntersection(Line,PolyD2, byid=T) >> plot(PolyD2, col = PolyD2$Attribute, axes =TRUE) >> lines( Inter2[1], col = "green", lwd = 3 ) >> lines( Inter2[2], col = "blue", lwd = 3 ) >> over(Inter2[1], PolyD2, byid=T) >> # The green (1st) segment intersects with the black (1st) polygon => good >> over(Inter2[2], PolyD2, byid=T) >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> >> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, >> 104030, 103733, 103733)) >> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, >> 104030, 103733, 103733)) >> P1 <- Polygon (matrix1) >> P2 <- Polygon (matrix2) >> Ps1 <- Polygons (list(P1), 1 ) >> Ps2 <- Polygons (list(P2), 2 ) >> Poly <- SpatialPolygons (list (Ps1, Ps2)) >> data <- data.frame( Attribute = c("1black", "2red") ) >> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >> plot(PolyD, col = PolyD$Attribute, axes =TRUE) >> matrix3 <- cbind(x= c(250300, 250666), >> y= c(103900, 103900)) >> L <- Line(matrix3) >> Ls <- Lines(list(L), "1") >> Line <- SpatialLines( list(Ls)) >> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >> lines( Inter[1], col = "green", lwd = 3 ) >> lines( Inter[2], col = "blue", lwd = 3 ) >> over(Inter[1], PolyD, byid=T) >> # The green (1st) segment intersects with the black (1st) polygon => good >> over(Inter[2], PolyD, byid=T) >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >> over(Inter[2], PolyD, byid=T, returnList = TRUE) >> >> # illustrate the problem: >> rgeos::gRelate(Inter, PolyD, byid = TRUE) >> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) >> >> >> There's also an in-line comment below: >> >> >> On 25/05/16 15:53, Gwenna?l Bataille wrote: >>> Dear all, >>> >>> I can't find a solution for the following problem: >>> >>> When I first intersect a line with 2 polygons (splitting it into 2 >>> segments) and then use an overlay to get for each segment the attribute >>> of the overlapping polygon, I sometimes get too answers (i.e. a small >>> point overlapping one polygon, the rest of the segment overlapping another). >>> >>> The functions I use for this are: >>> >>> rgeos::gIntersection >>> >>> and sp::over >>> >>> Do you have any idea how I could get the attribute of the polygon the >>> segments are "mostly overlapping"? >>> >>> Below is a reproductible example. >>> >>> Thank you very much in advance for any hint on this. >>> >>> Best regards, >>> >>> Gwenna?l >>> >>> >>> >>> Reproductible example: >>> >>> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), >>> >>> y= c(104030, 104030, 103733, 103733)) >>> >>> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), >>> >>> y= c(104030, 104030, 103733, 103733)) >>> >>> P1 <- Polygon (matrix1) >>> >>> P2 <- Polygon (matrix2) >>> >>> Ps1 <- Polygons (list(P1), 1 ) >>> >>> Ps2 <- Polygons (list(P2), 2 ) >>> >>> Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat >>> +datum=WGS84")) >> >> this proj4string doesn't make sense for such coordinates. >> >>> >>> data <- data.frame( Attribute = c("1black", "2red") ) >>> >>> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >>> >>> plot(PolyD, col = PolyD$Attribute) >>> >>> matrix3 <- cbind(x= c(250300, 250666), >>> >>> y= c(103900, 103900)) >>> >>> L <- Line(matrix3) >>> >>> Ls <- Lines(list(L), "1") >>> >>> Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat >>> +datum=WGS84") ) >>> >>> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >>> >>> lines( Inter[1], col = "green", lwd = 3 ) >>> >>> lines( Inter[2], col = "blue", lwd = 3 ) >>> >>> over(Inter[1], PolyD, byid=T) >>> >>> 'Attribute >>> >>> 11black' >>> >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> >>> over(Inter[2], PolyD, byid=T) >>> >>> 'Attribute >>> >>> 11black' >>> >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >>> >>> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >>> >>> over(Inter[2], PolyD, byid=T, returnList = TRUE) >>> >>> '[[1]] >>> >>> Attribute >>> >>> 11black >>> >>> 22red' >>> >>> # The blue(2nd) segment appears to intersect the two polygons (I guess >>> one point in common with the first polygon; the rest of the segment >>> overlapping the other polygon) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at 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 >> >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From vijaylulla at gmail.com Sat May 28 20:01:30 2016 From: vijaylulla at gmail.com (Vijay Lulla) Date: Sat, 28 May 2016 14:01:30 -0400 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines In-Reply-To: <57496FD0.4090005@uni-muenster.de> References: <5745AE6B.3070208@uclouvain.be> <5748BD44.1080507@uni-muenster.de> <57496FD0.4090005@uni-muenster.de> Message-ID: Thanks for the explanation. On Sat, May 28, 2016 at 6:15 AM, Edzer Pebesma wrote: > > > On 28/05/16 00:21, Vijay Lulla wrote: >> Edzer, >> I'm having trouble replicating what you state. Below is from my R session. > > I don't see what it is you have trouble with (except lacking documentation) > >> >> ### Start R session interaction >> >>> over(Inter2[1], PolyD2, byid=T) >> Attribute >> 1 1black >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter2[2], PolyD2, byid=T) # Still not ok! >> Attribute >> 1 1black >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >>> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> [[1]] >> Attribute >> 1 1black >> >>> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> [[1]] >> Attribute >> 2 2red >> >>> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) >>> >>> >>> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) >> [[1]] >> Attribute >> 1 1black >> 2 2red >> >>> over(Inter2[2], PolyD2, byid=T, returnList=TRUE) >> [[1]] >> Attribute >> 1 1black >> 2 2red >> >> ### End R session >> >> By the way, what is the minDimension argument in `over` function? Why >> do we need it? Also, where can I read about it? I cannot find it in >> ?over. > > Sorry, my mistake. You'll find details in vignette("over") > > over() finds intersections without ordering them, so if a line overlaps > polygon A but touches polygon B, it might as well return polygon B as > your match, where you were hoping for polygon A. > > With minDimension = 1 the dimensionality of the intersection (read the > help of rgeos::gRelate) needs to be at least one, so touching (a point: > 0-dimensional) is ignored, and polygon A would be returned. > > minDimension is now 0 by default; other values might make more sense, > depending on the geometries at hand. A problem is that this increases > the computational burden quite a bit (requiring gRelate instead of > gIntersects). > >> >> Thanks, >> Vijay. >> >> On Fri, May 27, 2016 at 5:33 PM, Edzer Pebesma >> wrote: >>> Thanks for the clear example. I can reproduce this, but don't know how >>> to solve it. If I create a similar example on the unit square, things >>> work fine. The different outputs of geos::gRelate() indicate the problem >>> (script below): >>> >>>> rgeos::gRelate(Inter, PolyD, byid = TRUE) # your example: >>> 1 1 1 2 >>> 1 "1FF00F212" "1010F0212" >>> 2 "FF1FF0212" "101F00212" >>> >>>> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) # simplified numbers: >>> 1 1 1 2 >>> 1 "1FFF0F212" "FF1F00212" >>> 2 "FF1F00212" "1FFF0F212" >>> >>> Is it possible that this relates to the scale factor of GEOS? >>> >>> # script: >>> library(sp) >>> matrix1 <- cbind(x= c(0, 1, 1, 0), y= c(2, 2, 0, 0)) # Simplified! >>> matrix2 <- cbind(x= c(1, 2, 2, 1), y= c(2, 2, 0, 0)) >>> >>> par(mfrow = c(2,1)) >>> >>> P1 <- Polygon (matrix1) >>> P2 <- Polygon (matrix2) >>> Ps1 <- Polygons (list(P1), 1 ) >>> Ps2 <- Polygons (list(P2), 2 ) >>> Poly <- SpatialPolygons (list (Ps1, Ps2)) >>> data <- data.frame( Attribute = c("1black", "2red") ) >>> PolyD2 <- SpatialPolygonsDataFrame(Poly , data = data ) >>> matrix3 <- cbind(x= c(0, 2), y= c(0.5, 0.5)) >>> L <- Line(matrix3) >>> Ls <- Lines(list(L), "1") >>> Line <- SpatialLines( list(Ls)) >>> Inter2 <- rgeos::gIntersection(Line,PolyD2, byid=T) >>> plot(PolyD2, col = PolyD2$Attribute, axes =TRUE) >>> lines( Inter2[1], col = "green", lwd = 3 ) >>> lines( Inter2[2], col = "blue", lwd = 3 ) >>> over(Inter2[1], PolyD2, byid=T) >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter2[2], PolyD2, byid=T) >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >>> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >>> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >>> >>> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, >>> 104030, 103733, 103733)) >>> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, >>> 104030, 103733, 103733)) >>> P1 <- Polygon (matrix1) >>> P2 <- Polygon (matrix2) >>> Ps1 <- Polygons (list(P1), 1 ) >>> Ps2 <- Polygons (list(P2), 2 ) >>> Poly <- SpatialPolygons (list (Ps1, Ps2)) >>> data <- data.frame( Attribute = c("1black", "2red") ) >>> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >>> plot(PolyD, col = PolyD$Attribute, axes =TRUE) >>> matrix3 <- cbind(x= c(250300, 250666), >>> y= c(103900, 103900)) >>> L <- Line(matrix3) >>> Ls <- Lines(list(L), "1") >>> Line <- SpatialLines( list(Ls)) >>> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >>> lines( Inter[1], col = "green", lwd = 3 ) >>> lines( Inter[2], col = "blue", lwd = 3 ) >>> over(Inter[1], PolyD, byid=T) >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter[2], PolyD, byid=T) >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >>> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >>> over(Inter[2], PolyD, byid=T, returnList = TRUE) >>> >>> # illustrate the problem: >>> rgeos::gRelate(Inter, PolyD, byid = TRUE) >>> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) >>> >>> >>> There's also an in-line comment below: >>> >>> >>> On 25/05/16 15:53, Gwenna?l Bataille wrote: >>>> Dear all, >>>> >>>> I can't find a solution for the following problem: >>>> >>>> When I first intersect a line with 2 polygons (splitting it into 2 >>>> segments) and then use an overlay to get for each segment the attribute >>>> of the overlapping polygon, I sometimes get too answers (i.e. a small >>>> point overlapping one polygon, the rest of the segment overlapping another). >>>> >>>> The functions I use for this are: >>>> >>>> rgeos::gIntersection >>>> >>>> and sp::over >>>> >>>> Do you have any idea how I could get the attribute of the polygon the >>>> segments are "mostly overlapping"? >>>> >>>> Below is a reproductible example. >>>> >>>> Thank you very much in advance for any hint on this. >>>> >>>> Best regards, >>>> >>>> Gwenna?l >>>> >>>> >>>> >>>> Reproductible example: >>>> >>>> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), >>>> >>>> y= c(104030, 104030, 103733, 103733)) >>>> >>>> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), >>>> >>>> y= c(104030, 104030, 103733, 103733)) >>>> >>>> P1 <- Polygon (matrix1) >>>> >>>> P2 <- Polygon (matrix2) >>>> >>>> Ps1 <- Polygons (list(P1), 1 ) >>>> >>>> Ps2 <- Polygons (list(P2), 2 ) >>>> >>>> Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat >>>> +datum=WGS84")) >>> >>> this proj4string doesn't make sense for such coordinates. >>> >>>> >>>> data <- data.frame( Attribute = c("1black", "2red") ) >>>> >>>> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >>>> >>>> plot(PolyD, col = PolyD$Attribute) >>>> >>>> matrix3 <- cbind(x= c(250300, 250666), >>>> >>>> y= c(103900, 103900)) >>>> >>>> L <- Line(matrix3) >>>> >>>> Ls <- Lines(list(L), "1") >>>> >>>> Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat >>>> +datum=WGS84") ) >>>> >>>> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >>>> >>>> lines( Inter[1], col = "green", lwd = 3 ) >>>> >>>> lines( Inter[2], col = "blue", lwd = 3 ) >>>> >>>> over(Inter[1], PolyD, byid=T) >>>> >>>> 'Attribute >>>> >>>> 11black' >>>> >>>> # The green (1st) segment intersects with the black (1st) polygon => good >>>> >>>> over(Inter[2], PolyD, byid=T) >>>> >>>> 'Attribute >>>> >>>> 11black' >>>> >>>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >>>> >>>> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >>>> >>>> over(Inter[2], PolyD, byid=T, returnList = TRUE) >>>> >>>> '[[1]] >>>> >>>> Attribute >>>> >>>> 11black >>>> >>>> 22red' >>>> >>>> # The blue(2nd) segment appears to intersect the two polygons (I guess >>>> one point in common with the first polygon; the rest of the segment >>>> overlapping the other polygon) >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at 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 >>> >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at 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 > From gwennael.bataille at uclouvain.be Mon May 30 16:01:19 2016 From: gwennael.bataille at uclouvain.be (=?ISO-8859-1?Q?Gwenna=EBl_Bataille?=) Date: Mon, 30 May 2016 16:01:19 +0200 Subject: [R-sig-Geo] Overlay between polygons and their intersecting lines In-Reply-To: <57496FD0.4090005@uni-muenster.de> References: <5745AE6B.3070208@uclouvain.be> <5748BD44.1080507@uni-muenster.de> <57496FD0.4090005@uni-muenster.de> Message-ID: <574C47AF.1070902@uclouvain.be> Thank you very much for your answers! rgeos::gRelate(Inter[1], PolyD, byid = TRUE) # From what I undestand of the "Dimensionally Extended nine-Intersection Model" ( https://en.wikipedia.org/wiki/DE-9IM ), # It looks like the green segment is in fact a bit shorter and the blue one starts a bit before the separation between the two polygons # Then it makes sense (e.g. the intersection between the boundary of the green segment and the interior of the black polygon is the end point, # there is no intersection between the boundaries of the green segment and the red polygon, ...) "Is it possible that this relates to the scale factor of GEOS?" # It seems so; thanks for the hint! # Changing the scale before gIntersection() changes the outcome. # Alternatively, we can change it before over(). Strangely, I only found one "good scale" for this, though I don't know how to generalize the result (which scale to apply when). # Only "scale = 0.01" leads to the good result: setScale( scale=0.01 ) #Inter1b <- gDifference( Inter[1], gBoundary(Inter[1]) ) #Inter2b <- gDifference( Inter[2], gBoundary(Inter[2]) ) over(Inter[1], PolyD, byid=T, returnList = TRUE, minDimension = 1) # OK [[1]] Attribute 1 1black over(Inter[2], PolyD, byid=T, returnList = TRUE, minDimension = 1) # OK [[1]] Attribute 2 2red # Wrong scales for the over() output: setScale( scale=0.01 / 10 ) over(Inter[1], PolyD, byid=T, returnList = TRUE, minDimension = 1) # nothing over(Inter[2], PolyD, byid=T, returnList = TRUE, minDimension = 1) # 2 overlaps setScale( scale=1 ) over(Inter[1], PolyD, byid=T, returnList = TRUE, minDimension = 1) # 2 overlaps over(Inter[2], PolyD, byid=T, returnList = TRUE, minDimension = 1) # OK setScale( scale=10 ) over(Inter[1], PolyD, byid=T, returnList = TRUE, minDimension = 1) # OK over(Inter[2], PolyD, byid=T, returnList = TRUE, minDimension = 1) # 2 overlaps All the best, Gwennael Le 28/05/2016 12:15, Edzer Pebesma a ?crit : > > On 28/05/16 00:21, Vijay Lulla wrote: >> Edzer, >> I'm having trouble replicating what you state. Below is from my R session. > I don't see what it is you have trouble with (except lacking documentation) > >> ### Start R session interaction >> >>> over(Inter2[1], PolyD2, byid=T) >> Attribute >> 1 1black >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter2[2], PolyD2, byid=T) # Still not ok! >> Attribute >> 1 1black >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >>> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> [[1]] >> Attribute >> 1 1black >> >>> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >> [[1]] >> Attribute >> 2 2red >> >>> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) >>> >>> >>> over(Inter2[1], PolyD2, byid=T, returnList=TRUE) >> [[1]] >> Attribute >> 1 1black >> 2 2red >> >>> over(Inter2[2], PolyD2, byid=T, returnList=TRUE) >> [[1]] >> Attribute >> 1 1black >> 2 2red >> >> ### End R session >> >> By the way, what is the minDimension argument in `over` function? Why >> do we need it? Also, where can I read about it? I cannot find it in >> ?over. > Sorry, my mistake. You'll find details in vignette("over") > > over() finds intersections without ordering them, so if a line overlaps > polygon A but touches polygon B, it might as well return polygon B as > your match, where you were hoping for polygon A. > > With minDimension = 1 the dimensionality of the intersection (read the > help of rgeos::gRelate) needs to be at least one, so touching (a point: > 0-dimensional) is ignored, and polygon A would be returned. > > minDimension is now 0 by default; other values might make more sense, > depending on the geometries at hand. A problem is that this increases > the computational burden quite a bit (requiring gRelate instead of > gIntersects). > >> Thanks, >> Vijay. >> >> On Fri, May 27, 2016 at 5:33 PM, Edzer Pebesma >> wrote: >>> Thanks for the clear example. I can reproduce this, but don't know how >>> to solve it. If I create a similar example on the unit square, things >>> work fine. The different outputs of geos::gRelate() indicate the problem >>> (script below): >>> >>>> rgeos::gRelate(Inter, PolyD, byid = TRUE) # your example: >>> 1 1 1 2 >>> 1 "1FF00F212" "1010F0212" >>> 2 "FF1FF0212" "101F00212" >>> >>>> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) # simplified numbers: >>> 1 1 1 2 >>> 1 "1FFF0F212" "FF1F00212" >>> 2 "FF1F00212" "1FFF0F212" >>> >>> Is it possible that this relates to the scale factor of GEOS? >>> >>> # script: >>> library(sp) >>> matrix1 <- cbind(x= c(0, 1, 1, 0), y= c(2, 2, 0, 0)) # Simplified! >>> matrix2 <- cbind(x= c(1, 2, 2, 1), y= c(2, 2, 0, 0)) >>> >>> par(mfrow = c(2,1)) >>> >>> P1 <- Polygon (matrix1) >>> P2 <- Polygon (matrix2) >>> Ps1 <- Polygons (list(P1), 1 ) >>> Ps2 <- Polygons (list(P2), 2 ) >>> Poly <- SpatialPolygons (list (Ps1, Ps2)) >>> data <- data.frame( Attribute = c("1black", "2red") ) >>> PolyD2 <- SpatialPolygonsDataFrame(Poly , data = data ) >>> matrix3 <- cbind(x= c(0, 2), y= c(0.5, 0.5)) >>> L <- Line(matrix3) >>> Ls <- Lines(list(L), "1") >>> Line <- SpatialLines( list(Ls)) >>> Inter2 <- rgeos::gIntersection(Line,PolyD2, byid=T) >>> plot(PolyD2, col = PolyD2$Attribute, axes =TRUE) >>> lines( Inter2[1], col = "green", lwd = 3 ) >>> lines( Inter2[2], col = "blue", lwd = 3 ) >>> over(Inter2[1], PolyD2, byid=T) >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter2[2], PolyD2, byid=T) >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOW GOOD ! >>> over(Inter2[1], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >>> over(Inter2[2], PolyD2, byid=T, returnList = TRUE, minDimension = 1) # OK! >>> >>> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), y= c(104030, >>> 104030, 103733, 103733)) >>> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), y= c(104030, >>> 104030, 103733, 103733)) >>> P1 <- Polygon (matrix1) >>> P2 <- Polygon (matrix2) >>> Ps1 <- Polygons (list(P1), 1 ) >>> Ps2 <- Polygons (list(P2), 2 ) >>> Poly <- SpatialPolygons (list (Ps1, Ps2)) >>> data <- data.frame( Attribute = c("1black", "2red") ) >>> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >>> plot(PolyD, col = PolyD$Attribute, axes =TRUE) >>> matrix3 <- cbind(x= c(250300, 250666), >>> y= c(103900, 103900)) >>> L <- Line(matrix3) >>> Ls <- Lines(list(L), "1") >>> Line <- SpatialLines( list(Ls)) >>> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >>> lines( Inter[1], col = "green", lwd = 3 ) >>> lines( Inter[2], col = "blue", lwd = 3 ) >>> over(Inter[1], PolyD, byid=T) >>> # The green (1st) segment intersects with the black (1st) polygon => good >>> over(Inter[2], PolyD, byid=T) >>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >>> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >>> over(Inter[2], PolyD, byid=T, returnList = TRUE) >>> >>> # illustrate the problem: >>> rgeos::gRelate(Inter, PolyD, byid = TRUE) >>> rgeos::gRelate(Inter2, PolyD2, byid = TRUE) >>> >>> >>> There's also an in-line comment below: >>> >>> >>> On 25/05/16 15:53, Gwenna?l Bataille wrote: >>>> Dear all, >>>> >>>> I can't find a solution for the following problem: >>>> >>>> When I first intersect a line with 2 polygons (splitting it into 2 >>>> segments) and then use an overlay to get for each segment the attribute >>>> of the overlapping polygon, I sometimes get too answers (i.e. a small >>>> point overlapping one polygon, the rest of the segment overlapping another). >>>> >>>> The functions I use for this are: >>>> >>>> rgeos::gIntersection >>>> >>>> and sp::over >>>> >>>> Do you have any idea how I could get the attribute of the polygon the >>>> segments are "mostly overlapping"? >>>> >>>> Below is a reproductible example. >>>> >>>> Thank you very much in advance for any hint on this. >>>> >>>> Best regards, >>>> >>>> Gwenna?l >>>> >>>> >>>> >>>> Reproductible example: >>>> >>>> matrix1 <- cbind(x= c(250300, 250451, 250494, 250300), >>>> >>>> y= c(104030, 104030, 103733, 103733)) >>>> >>>> matrix2 <- cbind(x= c(250451, 250666, 250666, 250494), >>>> >>>> y= c(104030, 104030, 103733, 103733)) >>>> >>>> P1 <- Polygon (matrix1) >>>> >>>> P2 <- Polygon (matrix2) >>>> >>>> Ps1 <- Polygons (list(P1), 1 ) >>>> >>>> Ps2 <- Polygons (list(P2), 2 ) >>>> >>>> Poly <- SpatialPolygons (list (Ps1, Ps2), proj4string=CRS("+proj=longlat >>>> +datum=WGS84")) >>> this proj4string doesn't make sense for such coordinates. >>> >>>> data <- data.frame( Attribute = c("1black", "2red") ) >>>> >>>> PolyD <- SpatialPolygonsDataFrame(Poly , data = data ) >>>> >>>> plot(PolyD, col = PolyD$Attribute) >>>> >>>> matrix3 <- cbind(x= c(250300, 250666), >>>> >>>> y= c(103900, 103900)) >>>> >>>> L <- Line(matrix3) >>>> >>>> Ls <- Lines(list(L), "1") >>>> >>>> Line <- SpatialLines( list(Ls), proj4string = CRS("+proj=longlat >>>> +datum=WGS84") ) >>>> >>>> Inter <- rgeos::gIntersection(Line,PolyD, byid=T) >>>> >>>> lines( Inter[1], col = "green", lwd = 3 ) >>>> >>>> lines( Inter[2], col = "blue", lwd = 3 ) >>>> >>>> over(Inter[1], PolyD, byid=T) >>>> >>>> 'Attribute >>>> >>>> 11black' >>>> >>>> # The green (1st) segment intersects with the black (1st) polygon => good >>>> >>>> over(Inter[2], PolyD, byid=T) >>>> >>>> 'Attribute >>>> >>>> 11black' >>>> >>>> # The blue(2nd) segment intersects with the red(2nd) polygon => NOT GOOD ! >>>> >>>> over(Inter[1], PolyD, byid=T, returnList = TRUE) # OK >>>> >>>> over(Inter[2], PolyD, byid=T, returnList = TRUE) >>>> >>>> '[[1]] >>>> >>>> Attribute >>>> >>>> 11black >>>> >>>> 22red' >>>> >>>> # The blue(2nd) segment appears to intersect the two polygons (I guess >>>> one point in common with the first polygon; the rest of the segment >>>> overlapping the other polygon) >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> R-sig-Geo mailing list >>>> R-sig-Geo at 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 >>> >>> >>> _______________________________________________ >>> R-sig-Geo mailing list >>> R-sig-Geo at r-project.org >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo > > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Gwenna?l BATAILLE, PhD student - Teaching assistant Earth and Life Institute Universit? Catholique de Louvain SST/ELI/ELIB B?timent Carnoy, c.145 Croix du sud 4-5, bte L7.07.04 1348 Louvain-la-Neuve BELGIUM [[alternative HTML version deleted]]