Oops, that has been fixed on r-forge, but not CRAN. Please try to
install from here (you need the latest version of R for that) like
this:
install.packages(raster, repos=http://R-Forge.R-project.org;)
I will update to CRAN this week.
Robert
On Tue, Nov 30, 2010 at 12:32 PM, Fernando Santo
,
Advait
On Mon, Nov 29, 2010 at 1:14 PM, Robert J. Hijmans r.hijm...@gmail.com
wrote:
Advait,
I do not think I can help you further unless you send me your file;
but this suggests that it is either not following the CF standards, or
something is wrong with the file, or that there is something
Michael,
Thanks for sending an good self-contained example. If you use
stackApply with layers=1:nlayers you are requesting that the function
should be applied to each layer separately. That is OK for the first
case (set.NA) although 'calc' would be more direct. But it does not
for fill.NA,
Isabelle,
If you use a factor that is represented by numbers on a grid you can
just fit the model (with the factor variable as factor), and the
predict function will then make a factor from the predictor layers
(i.e. there is nothing else you need to do). Where this can go wrong
is if you have
and max values are not being
displayed for either of these rasters. Is that the source of the problem
in
the stack function?
Thanks,
Advait
On Tue, Nov 30, 2010 at 5:18 PM, Robert J. Hijmans
r.hijm...@gmail.comwrote:
Advait,
The is an error in the file, I think, see below
This is the work around:
layerNames(rcmraster) - layerNames(rcmraster)
On Thu, Dec 2, 2010 at 10:43 AM, Robert J. Hijmans r.hijm...@gmail.com wrote:
The question marks indicate that the min and max values are not known
to the object (because the file type does not store them, and it is
too
, Dec 5, 2010 at 5:29 PM, Robert J. Hijmans r.hijm...@gmail.com
wrote:
If so, should I use a for loop instead?
No, that is the point of the calc function, that you do not do that.
Internally, calc uses apply as in
apply(values, 1, fun)
On Sat, Dec 4, 2010 at 1:50 PM, Advait Godbole
a lot.
Isabelle.
2010/12/3 Robert J. Hijmans r.hijm...@gmail.com
Dear Isabelle,
Thanks for the detailed report. So it is a bug after all. This is
probably fixed in raster 1.7-8 (on CRAN for win and lin now).
At least the below works for me (model with 2 variables, one is a
factor).
Robert
Dear Gianni,
perimeter is a function in the geosphere package.
You found a bug in the test whether this is a closed polygon. (It
should be if (isTRUE(all.equal(x[1, ], x[nrow(x), ]))) rather than
if (all.equal(x[1, ], x[nrow(x), ])) ). Thanks for reporting it, it
is fixed in version 1.2-16.
operation,
perhaps you could consider a simpler syntax in the future, i,e:
r = as.brick(x)
where x would be a 3D array?
Agus
2010/12/16 Robert J. Hijmans r.hijm...@gmail.com:
Christian,
Could be quicker if you make a matrix out of the array (or, if
possible, avoid the array in the first
('array has wrong dimensions')
}
b - brick(xmn=xmn, xmx=xmx, ymn=ymn, ymx=ymx, crs=crs)
dim(b) - dm
setValues(b, matrix(as.vector(x), ncol=dm[3]))
}
)
On Sun, Dec 19, 2010 at 8:06 AM, Robert J. Hijmans r.hijm...@gmail.com wrote:
Agus
https://stat.ethz.ch/pipermail/r-sig-geo/2010-December/010426.html
On Tue, Dec 21, 2010 at 1:09 PM, Axs Seven axs.se...@gmail.com wrote:
Hi
I would like to replicate the map of airline routes in R (such as
http://openflights.org/demo/openflights-routedb-2048.png) , but I haven't
managed to
Christian,
You should also be able to do this:
out - setValues(x, xx)
(where x is a RasterBrick and xx a matching 3 dimensional array)
Robert
On Wed, Dec 22, 2010 at 3:06 AM, Christian Kamenik
christian.kame...@giub.unibe.ch wrote:
Dear all,
I replaced my layer-by-layer approach
for (l
Hi Nick,
Could you first update the raster package? It seems that you are using
a relatively old version; perhaps this is something that has been
fixed now. But who knows? List members, please supply the results of
sessionInfo() whenever you report something that might be a bug.
You should be
, Robert J. Hijmans r.hijm...@gmail.com
wrote:
Dear Advait,
What I dont understand is:
1) How can each slope be the same (values of x1)
Apparently the values in these cells are all the same (not that you
only use the first 8 time steps, not all 120)
Here is an example with random values
setValues is being used here.
In this case you compute the values yourself. With setValues you
assign these to a Raster* object.
Best, Robert
Thanks,
Advait
On Wed, Dec 22, 2010 at 7:26 PM, Robert J. Hijmans r.hijm...@gmail.com
wrote:
Advait,
When asking for help, please provide a self
$clc)
[1] 3 5 4 6 7 1 2
Levels: 1 2 3 4 5 6 7
unique(subset(regionalStack, 7))
[1] 1 2 3 4 5 6 7
Any idea?
2010/12/8 Robert J. Hijmans r.hijm...@gmail.com
Isabelle, I think I fixed this in raster 1.7-11. Robert
On Wed, Dec 8, 2010 at 8:55 AM, isabelle boulangeat
isabelle.boulang
Gianni,
# make a list of file names, perhaps like this:
f -list.files(pattern = .asc)
# turn these into a list of RasterLayer objects
r - lapply(f, raster)
# as you have the arguments as a list call 'merge' with 'do.call'
x - do.call(merge, r)
Best, Robert
On Fri, Dec 24, 2010 at 7:23 AM,
Hi Agus,
It would be useful to see
extent(calibf2)
Apparently it does not overlap with SGRGBF40 (see
intersectExtent(calibf2, SGRGBF40) )
because the polys did not plot on top of the raster.
Perhaps QGIS does some on-the-fly projection trick or other such that
the coordinates from your
the CRS for the raster in R.
intersectExtent(calibf2, SGRGBF40)
Error in intersectExtent(calibf2, SGRGBF40) : Invalid extent
which is in agreement with the rest of results, but still in
contradiction with what we see in QGIS
Agus
2011/3/24 Robert J. Hijmans r.hijm...@gmail.com:
Hi Agus
Babak,
I looked at the original paper,
http://onlinelibrary.wiley.com/doi/10./j.1538-4632.1995.tb00338.x/abstract,
and the spdep manual, and other places, but they all seemed to be
saying somewhat different on the local moran statistic. I followed the
logic of the spdep::localmoran function,
)
}
-Original Message-
From: Roger Bivand [mailto:roger.biv...@nhh.no]
Sent: Wednesday, April 13, 2011 11:15 PM
To: Robert J. Hijmans
Cc: Babak Naimi; r-sig-geo@r-project.org
Subject: Re: [R-sig-Geo] Local Moran'I for raster focalFilter
On Wed, 13 Apr 2011, Robert J. Hijmans wrote
statistics :)
Robert
Robert
On Thu, Apr 14, 2011 at 12:27 PM, Nick Hamm n...@hamm.org wrote:
Dear all
Replies below
On 14 April 2011 19:19, Robert J. Hijmans r.hijm...@gmail.com wrote:
Hi Babak,
I would propose the below for the local Moran with a RasterLayer
because it deals with NA
On Tue, Apr 19, 2011 at 12:19 PM, Lyndon Estes les...@princeton.edu wrote:
Dear Robert,
Thanks for your response on this (sorry for my slow feedback, I had
another project intervene).
Hi Lyndon,
likewise :); sorry about that.
I have gone through the subs code now:
Using my raster ltq.g:
Hello Agus,
The NaN suggests that there are only NA values for that polygon/layer.
To investigate this I would do
v - extract(SGRGBF40, calibf2, nl=3)
# i.e. do not use a function and then inspect
v[[7]]
All functions must accept an na.rm argument (even if they choose to
ignore it. So for
This was caused by raster incorrectly interpreting the highest
possible INT2U value (65530) as NA. Now fixed (version 1.8-16), at
least for this case. Thanks for reporting, Robert
On Wed, Apr 27, 2011 at 8:52 AM, Robert J. Hijmans r.hijm...@gmail.com wrote:
Hello Agus,
The NaN suggests
Hi Agus,
The problem is that you raster is rotated (GeoTransform[3] and [5] are not zero)
GeoTransform =
445548.7745816645, -0.109570548549058, 0.216912817625298
4628418.279379116, 0.216912817625298, 0.109570548549058
raster ignored the rotation. I have fixed that (in version 1-8-19) by
tremendously, if you have a multi-core machine
b - brick('SDIM0114.tif')
br - rectify(b, progress='window')
plotRGB(br)
Robert
On Mon, May 9, 2011 at 11:17 AM, Robert J. Hijmans r.hijm...@gmail.com wrote:
Hi Agus,
Thanks for the suggestions. I'll make it a (stern) warning. I am also
going to store
Thanks Tim,
This happened when using gam writing to file na.rm = FALSE (which
in the case of GAM is the same as na.rm=TRUE). The problem was that
gam.predict returns an array where raster::predict expected a matrix
or a vector. This is now fixed (version 1.8-22).
Robert
On Thu, May 12, 2011 at
Hi Agus,
That happens because I defined Arith functions for Raster* objects and
numeric values, but not for Raster* objects and logical values. NA is
a logical value, see class(NA). I will add that.
Here are two more work arounds:
r - D10N2009[[1]] * as.numeric(NA)
r - calc(D10N2009[[1]],
Hi Agus,
I have implemented a similar function in raster version 1.8-31, such
that you can coerce from grf to Raster* objects
library(geoR)
library(raster)
sim - grf(441, grid=reg, cov.pars=c(1, .25), nsim=4)
b - brick(sim)
# or
x - as(b, 'RasterBrick')
# and
r - raster(sim)
r - raster(sim, 2)
Byman,
I suspect that raster cell sizes are large relative to some of the
polygons (small island states), and that not all polygons cover at
least one raster cell. You can check that with:
um - unique(msk)
length(um)
# what you are doing can be done more directly, I think, like this:
Hi Thiago,
You are not saying _what_ goes wrong. That makes it difficult to help.
I am guessing that you are missing some of the steps below. You do:
cane_sa[cane_sa0]-16
# I do not know your exact objectives but it seems strange to use 0 here,
# as even a cell that is covered for 1/600 of its
Agus,
You can do:
foo4 - raster(nrows=20, ncols=20,crs=NA,extent(0,20,0,20))
#which is the same as
foo4 - raster(x=extent(0,20,0,20), nrows=20, ncols=20, crs=NA )
#or
foo4 - raster(nrows=20, ncols=20,crs=NA, xmn=0, xmx=20, ymn=0, ymx=20)
What I will add to the package is the ability to do
value is greater than...?
Best wishes,
Thiago Veloso.
--- On Sat, 11/6/11, Robert J. Hijmans r.hijm...@gmail.com wrote:
From: Robert J. Hijmans r.hijm...@gmail.com
Subject: Re: [R-sig-Geo] Methodology to compare crop maps
To: Thiago Veloso thi_vel...@yahoo.com.br
Cc: r-sig-geo@r
For those places (valley bottoms, mountain tops), a spline interpolation do
better ((and even better when using stream information like in Hutchinson's
algorithm that was (is?) implemented in Arc/INFO.)) You mentioned the akima
package, here is an example with fields.
library(raster)
IDW was indeed a poor choice, but I'd say that splines should generally work
OK. Robert
On Fri, Jul 8, 2011 at 8:09 AM, Roger Bivand roger.biv...@nhh.no wrote:
On Fri, 8 Jul 2011, Barry Rowlingson wrote:
On Fri, Jul 8, 2011 at 2:26 PM, Robert Hijmans r.hijm...@gmail.com
wrote:
# now
Agus, That is indeed because of an unintended difference between the
released version (Barry's) and the development version on R-Forge (yours). I
have fixed the development version. Thanks for pointing this out. Robert
On Fri, Jul 15, 2011 at 12:12 PM, Agustin Lobo alobolis...@gmail.comwrote:
Agus,
This problem arises because you are combing what are (for calc anyway)
different types of functions. The second part is called with apply, the
first part not. I think you can fix that using my 'fun3' (see below).
r1 - r2 - raster(nc=10, nr=10)
r1[] - round(runif(ncell(r1))) * 248
r2[] -
of matrix that calc
gets: s1[1:3]
instead of
fun3(s1, s2)
?
Because fun3 may not know what to do with a RasterStack.
Agus
Hth, Robert
2011/7/27 Robert J. Hijmans r.hijm...@gmail.com:
Agus,
This problem arises because you are combing what are (for calc anyway)
different types
After seeing Carsten's script it became clear that the problem was caused by
using a model that returns a character type factor that has levels such
as SAND. The raster::predict function uses as.integer(as.character(x)) to
convert factor levels and therefore all factors became NA. raster::predict
Carsten,
I am re-implementing plot(raster), using the rasterImage function. I'll fix
the problems with 'zlim' and 'at'. For now, you can use the old version of
the plot function by using the argument 'oldstyle=T'
plot(x, zlim=c(10,40), oldstyle=T)
Robert
On Wed, Jul 27, 2011 at 5:28 PM,
- function(x){
t( u %*% t(x) )
}
a - calc(s1, fun=funortho(x,u))
Best, Robert
Thanks!
Agus
2011/7/27 Robert J. Hijmans r.hijm...@gmail.com:
On Wed, Jul 27, 2011 at 2:23 PM, Agustin Lobo alobolis...@gmail.com
wrote:
I think the problem is that I do not quite understand
Simon,
Perhaps the below function works or can get you started.
Best, Robert
library(raster)
library(bigmemory)
raster2bm - function(x, filename) {
filename - trim(filename)
z - filebacked.big.matrix(ncell(x), nlayers(x),
backingfile=filename,descriptorfile=extension(filename, '.desc'))
tr -
Fred,
Perhaps you can use the Hovmoller function in the rasterVis package.
Robert
On Wed, Aug 17, 2011 at 12:20 AM, Jianyun Wu jianyun.fred...@gmail.comwrote:
Hi Roger,
It seems really helpful, I will go through Vignettes of spacetime package
to see how it goes.
Thanks and Regards
Fred
Giulia,
What is the best statistics to quantify this difference?
I think you already have it (the map of differences). You could add the
means, or perhaps quantiles and/or boxplot or scatterplot and slope of
regression line. Depending on what you see and why you care, that may be as
much as
thing the Region Group does is to count the number of cells in
each contiguous area can I also acheive this in Raster?
On 7/09/2011 10:48 AM, Robert J. Hijmans wrote:
Nevil,
The function 'clump' in 'raster' does this for a single value and perhaps
you can use it in a loop over all values
Luca,
The below expands a bit on Matthew's response to get a working example:
library(raster)
# trmm template
trmm - raster(xmn=0, xmx=360, ymn=-50, ymx=50, ncol=1440, nrow=400)
filename - '3B42_daily.2010.01.02.6.bin'
# read values
trmm[] - readBin(filename, 'double', n=576000, size = 4,
Tony,
On Wed, Sep 14, 2011 at 2:36 PM, Anthony Fischbach afischb...@usgs.govwrote:
I am producing plots of spatialPolygons over a spatialPixelDataFrame
and wish to convert the spatialPolygons object to a spatialLines object
as a work around of two plotting problems.
if x is a
arrows?
?arrows !
On Thu, Sep 15, 2011 at 6:17 PM, Jonathan Greenberg
greenb...@ucdavis.eduwrote:
R-sig-geo'ers:
Given an aspect raster (GDAL-readable), is there a way to plot the
aspect image using arrows representing each cell's direction? I'm
assuming I have to convert the raster to a
Tara, I think you need to 'rasterize' function
library(raster)
r - raster(ncol=10, nrow=10)
x - c(-25, -148, 46, 23, 0, -69)
y - c(-45, 30, 20, -10, 50, -7)
value - c(1, 2, 3, 4, 5, 6)
# you can do this:
r1 - rasterize(cbind(x, y), r, value)
plot(r1)
# or
sp -
Arnaud,
You can (directly) do the same with Raster* objects what Roger did with sp
objects:
library(raster)
t-raster(ncol = 10, nrow = 10)
t[1:2,] - seq(1,10,1)
t[3:5,1:5] - seq(1,5,1)
t[6:8,6:10] - seq(6,10,1)
t[9:10,] - seq(1,10,1)
plot(t)
library(classInt)
zClass - classIntervals(values(t),
Nice problem:
library(raster)
cds1 - rbind(c(-100,91), c(-140,15), c(-10, 40), c(-140,-91))
lines - SpatialLines(list(Lines(list(Line(cds1)), 1)))
r - raster(ncols=50, nrows=45, xmx=10)
r - rasterize(lines, r)
rc - rowColFromCell(r, cellFromXY(r, rasterToPoints(r)))
west - tapply(rc[,2], rc[,1],
Ariel, if you have 23 stacks, you could, in principle, combine these into a
single stack and then extract the values. But because your stack are already
very large (90,000 layers each), you might be better off considering an
alternative option: to determine the weights once, and then re-use them
Jonathan,
I think you can do something like this:
# remove unit from the list of arguments
# and make it a global variable instead
circ.mean.na.rm = function(x, na.rm=TRUE) {
if(unit==degrees) { x=rad(x)}
etc.
}
unit - 'degrees'
azimuth_raster_agg =
Or better still, provide a self contained example as below:
r1 - raster(ncol=25, nrow=25, xmn=-50, xmx=50, ymn=-50, ymx=50)
r2 - raster(ncol=25, nrow=25, xmn=-3.5, xmx=20, ymn=-3.5, ymx=20)
r1[] - 1:ncell(r1)
r2[] - 1:ncell(r2)
plot(r1)
plot(rasterToPolygons(r2), add=T)
# one approach
x -
Tara,
raster_ct- rasterize(coord.plus.value_sp, r,
fun=function(value) {length(unique(na.omit(value)))})
This is wrong on two accounts. You do not use the ... argument and you do
not pass the vector value to rasterize (instead, you redefine it inside
fun)
It should be:
library(raster)
r -
Hi Agus,
You can use the index argument for that (but I admit that the function
should detect this automatically). If you expect two numbers for each cell,
you can do
predict(object=PCAtoMedian_6yrs,model=srndpc2lda, index=1:2)
Robert
On Sat, Sep 24, 2011 at 2:48 AM, Agustin Lobo
I have seen the same problem with those very same files on R 64 bits in
windows 7, but have not had time to follow up. I found that I was able to
read the file with R 32 bits.
I will make the file available to the maintainer of the ncdf package (and
copy you).
Robert
On Mon, Oct 3, 2011 at 6:57
Arnaud,
With raster objects you can do
plot(x, fun=log)
But in the current version the legend is not affected, and hence wrong --
fixed in the release.
Robert
On Thu, Oct 6, 2011 at 1:54 AM, Paul Hiemstra paul.hiems...@knmi.nl wrote:
Hi,
You could use ggplot:
library(gstat)
Anthony, Looks close, but would be better without some of the loops. Perhaps
like this, for one file: ?
library(raster)
# I do not know the coordinates, but you can fix these:
r - raster(nrow=448, ncol=304, xmn=0, xmx=10, ymn=0, ymx=10)
# projection(r) - ''
filename -
Steven,
In principle you could give merge all tiles (e.g. make a list of RasterLayer
objects and use do.call ) but merge is quite slow (something that can easily
be be improved; and I expect it will be over the coming months).
What I would do is use run gdalbuildvrt (that comes with the
Here is one approach:
rgeo - projectRaster(rr, crs=+proj=longlat +datum=WGS84)
KML(rgeo, file.kml)
Best, Robert
On Wed, Oct 19, 2011 at 10:00 AM, Anthony Fischbach afischb...@usgs.govwrote:
In my previous post I happily handled the binary National Snow and Ice Data
Center sea ice imagery
Not sure what's going on here, I need to investigate. But this work-around,
which replicates the essence of projectRaster works for me:
library(rgdal)
x - raster(ymn=60)
res(x) - 0.25
xy - coordinates(x, sp=T)
xypole - spTransform(xy, projection(r, asText=F))
x[] - extract(r, xypole,
version
will be available in raster = 1.9-29. Thanks for reporting this problem.
Robert
On Wed, Oct 19, 2011 at 11:43 AM, Robert J. Hijmans r.hijm...@gmail.comwrote:
Not sure what's going on here, I need to investigate. But this work-around,
which replicates the essence of projectRaster works
Tony,
On Wed, Oct 19, 2011 at 1:13 PM, Anthony Fischbach afischb...@usgs.govwrote:
This works beautifully.
Is there a trick to applying an intuitive color ramp to the png file
You can provide a list of colors such as that generated by
Hi Ben,
This is obviously a rJava problem as library(rJava) does not work. In fact
it seems to be a java related problem:
call: stop(No CurrentVersion entry in ', key, '! Try re-installing Java
and make sure R and Java have matching architectures.)
Which version of java you are using (if
I
asc2ras_off - function(filename, offset=6) {
splitasc - function(s) {
s - trim(s)
spl - unlist(strsplit(s, ''))
pos - which(spl==' ')[1]
first - substr(s, 1, (pos-1))
second - substr(s, (pos+1), nchar(s))
return(trim(c(first, second)))
}
filename - trim(filename)
if
, 2011 at 10:15 AM, Robert J. Hijmans r.hijm...@gmail.comwrote:
I
asc2ras_off - function(filename, offset=6) {
splitasc - function(s) {
s - trim(s)
spl - unlist(strsplit(s, ''))
pos - which(spl==' ')[1]
first - substr(s, 1, (pos-1))
second - substr(s, (pos+1), nchar(s))
return(trim(c
)
}
On Fri, Oct 21, 2011 at 10:18 AM, Robert J. Hijmans r.hijm...@gmail.comwrote:
Matthias,
To finish my message to slipped away:
If you are done batting, you can use the function below, slight adjustment
of what 'raster' does, adjusting the offset value (and library(raster) ).
In future
Yes, shorter still:
newRaster - Which(randomRaster %in% c(2, 4, 6))
On Sun, Oct 30, 2011 at 7:19 PM, steven mosher mosherste...@gmail.comwrote:
?Which
On Sun, Oct 30, 2011 at 6:55 PM, pgalpern pgalp...@gmail.com wrote:
Hello!
Wondering if there is an efficient raster package approved
- Which(randomRaster %in% c(2,4,6))
So am guessing that %in% and match still need to be implemented.
Best,
Paul
On 30/10/2011 10:29 PM, Robert J. Hijmans wrote:
Yes, shorter still:
newRaster - Which(randomRaster %in% c(2, 4, 6))
On Sun, Oct 30, 2011 at 7:19 PM, steven mosher
I think the point I wanted to make was, if a function aggregates, can it
be made into a method instance that has the name aggregate.
I think it is a good idea, and I think it can be done, by letting the code
fork based on the arguments that are supplied to aggregate. It could be
interesting to
] sp_0.9-91 foreign_0.8-46
loaded via a namespace (and not attached):
[1] grid_2.13.2
On Mon, Oct 31, 2011 at 9:49 AM, Robert J. Hijmans r.hijm...@gmail.comwrote:
Swen, That is interesting, can you share some more information about your
grids (how many columns and rows)? And some info on your
Ortiz-Bobea
aortizbo...@arec.umd.eduwrote:
Hello everyone,
I have about 90,000 individual grid files in GRIB format I'm importing and
converting to raster format in R.
Some of the calculations I need to do (clipping with polygons... thanks
Robert J. Hijmans for valuable advice
Benjamin,
You can do:
x - rasterize(r, ref, 'lc')
If that is too slow you may try (with the current version of raster):
x - raster:::.p3r(r, ref, 'lc')
(this is a function under development that is not well tested and will
disappear in the future, to replace rasterize)
Robert
On Mon, Nov 7,
Paul,
That is a bug; seems to occur only for patches that are two cells from the
bottom of the raster. I'll look into it, thanks for reporting.
Robert
On Mon, Nov 7, 2011 at 9:35 AM, pgalpern pgalp...@gmail.com wrote:
Hello!
Perhaps I am doing something wrong, here, but in the following case
Maria,
You can do this:
library(raster)
china - getData('GADM', country='CHN', level=1)
plot(china)
text(coordinates(china), as.character(china$NAME_1), cex=0.5)
you can use 'paste' to combine the NAME field with other values, and cex
can be a vector the scale the labels for each province.
Els,
To add to what Carsten says: in that case you can use 'reclass' or 'subs'
or (at least in current versions) replacement: ndvi.stack[ndvi.stack ==
-0.3] - NA
Robert
On Tue, Nov 8, 2011 at 4:14 AM, Carsten Neumann carste...@aol.com wrote:
Am 08.11.2011 09:18, schrieb Els Ducheyne:
Leni,
If you have raster data in Arc and export as GRID it will create a database
(folder, including a parallel folder called info) that you can treat like a
file and open in R. Alternatively you can export to tif, img (erdas) and
other formats (avoid ascii) that raster can read (most of them via
Or this:
library(rgeos)
library(raster)
esp - getData(GADM, country=ESP, level=0)
plot(esp)
res - gIntersection(esp, as(drawExtent(), 'SpatialPolygons'))
# now click on the map for the two corners of the extent you want
plot(res)
Robert
On Sun, Nov 13, 2011 at 12:15 PM, Edzer Pebesma
Benjamin,
This is a bug I recently introduced (my efforts to speed things up have
these nasty side effects; sorry about that).
I fixed it yesterday, and the fixed version, 1.9-44, is on CRAN now (for
linux, other OSes will follow shortly).
Thanks, Robert
On Fri, Nov 18, 2011 at 9:19 AM, Benjamin
Chris, Yes, I think it is a projection issue, as Google maps are in
Mercator projection. Here is an example (dismo::gmap is based on
RGoogleMaps but returns a RasterLayer, which makes things easier).
library(dismo)
e - extent(c(-122.308247, -122.224433, 47.495551, 47.582025))
r - raster(e,
Alexandre,
I am not entirely sure what the question is, but I take it that the goal is
to count points by grid cell, in which case you can do:
library(sp)
x - runif(n=500,min=0, max=20)
y - runif(n=500,min=0, max=20)
xy-cbind(x,y)
limx-c(2.5,2.5,18,18,2.5)
limy-c(2.5,18,18,2.5,2.5)
Lyndon,
The reason might be that the large rasters trigger raster to processing by
chunk (writing to disk) whereas the smaller file is considered small enough
for processing in RAM. That may not be the case, and the OS may start
swapping memory (using disk as RAM) which is slow. If this happens,
Gianni,
Would you be able to create a reproducible example that shows this?
This is what I get:
library(raster)
Loading required package: sp
raster version 1.9-45 (22-November-2011)
library(rgdal)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime:
Dear Gianni,
You are using R version 2.11.1 (2010-05-31) and raster_1.8-12.
Please update to the current versions first.
Robert
On Wed, Nov 23, 2011 at 5:59 PM, gianni lavaredo
gianni.lavar...@gmail.comwrote:
Dear Prof. Robert J. Hijmans,
I hope this can help. Probaly the problem
.
-Steve
From: Robert J. Hijmans [*mailto:r.hijm...@gmail.com*r.hijm...@gmail.com]
Sent: Wednesday, November 23, 2011 6:58 PM
To: VanWilgenburg,Steve [Sas]
Cc: r-sig-geo@r-project.org
Subject: Re: [R-sig-Geo] Finding a way to select upper portion
- function(x) {
... ?
... ?
}
res - fun(d)
Then the next step is to do (perhaps after a few changes)
x - calc(s, fun)
Hope this gets you closer,
Robert
-Steve
From: Robert J. Hijmans [mailto:r.hijm...@gmail.com]
Sent: Thursday, November 24, 2011 1:38 PM
I would do:
#r - raster(nrows=733, ncols=732, xmn=-158, xmx=-121, ymn=-28.3, ymx=8.35,
crs=NA)
# there is reason to do do r[] - 0
#p - read.table(09_16_B.txt, sep=\t, dec=., header=F)
#p - p[,-3]
# replacing above with simulated data, to make a self contained example:
r - raster(ncols=5,
Jan,
It seems to me that:
Plate-Carrée with a Geographic Lat/Lon representation (GCTP_GEO)
WGS 84 (R= Spherical Radius= Equatorial Radius=Re= 6378,14km)
translates to this:
+proj=longlat +datum=WGS84
The reported extent does not make sense in that case, perhaps it can be
fixed by doing:
Matthias,
I have tried with the raster package (merge function), but it seems you
can only read 1 variable at the time (when reading .nc file with
raster())?
Correct, because raster() returns a RasterLayer object. But you can use
brick() instead to get a multulayer RasterBrick object
these 4 files (quandrants) could be
merged to 1 large spatial file, so that all variable dimensions and
values are merged as well. And yes, some variables do not have a spatial
reference (e.g. the 1D variable).
Hope this is clear now?
Regards,
Matthias
On 07/12/11 18:06, Robert J. Hijmans
Ray,
It is probably Teale-Albers (the commonly used projection used in
California) with NAD83 or NAD27 datum.
+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0 +y_0=-400
+ellps=GRS80 +units=m +datum=NAD83
or
+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
And I am sure someone can do this even shorter...
fls = list.files('foldername')
s - stack(fls)
Robert
On Tue, Dec 13, 2011 at 5:24 AM, jon.sko...@jrc.ec.europa.eu wrote:
Hi Sajid,
You should be able to do something like this:
setwd( name of folder)
fls = list.files() # you can add a
Byman,
I think this happens because all values in
pr_a2_20c3m_1_cgcm3.1_t47_1961_2000.nc are NA.
Robert
On Tue, Dec 13, 2011 at 3:52 PM, Byman bym...@gmail.com wrote:
*I am sorry if this has been answered before but I searched and found
no solution
*
*I have a problem plotting maps using
Alfreda,
It appears that you are comparing entire populations (all cells in each
AREA), not samples. If that is the case there is no difference between the
(true) population mean and the (estimated) sample mean. That makes doing a
statistical test is irrelevant: all differences should be
Agus,
I think you were on the right track with 'area'. I would suggest:
library(dismo)
?maxent
...
r - predict(me, predictors, progress='window')
# and now:
a - area(r)
threshold - 0.5
x - a * (r threshold)
cellStats(x, 'sum')
Best, Robert
On Tue, Dec 20, 2011 at 10:35 PM, agus
Satish,
Here are some suggestions:
library(rgeos)
library(raster)
# you need the latests versions of the above packages
library(rgdal)
grid - readOGR(c:/satish, Gaussian_Poylgon_ExtendedCONUS)
clim - readOGR(c:/satish, US344ClimateDivisions)
# climag has several polygons with the same
Tony,
That is odd. .hasSlot is a function in the methods package (which on my
system is loaded by default). Do you have an uncommon installation of R, or
did you tweak it to not load the methods package? Can you send your
sessionInfo() as below?
Robert
.hasSlot
function (object, name)
1 - 100 of 507 matches
Mail list logo
