On Tue, Feb 9, 2016 at 5:01 AM, Roger Bivand <roger.biv...@nhh.no> wrote:
> On Mon, 8 Feb 2016, Roger Bivand wrote:
>
>> On Mon, 8 Feb 2016, Josh O'Brien wrote:
>>
>>> Oops. The post's title should have read "rgeos::gBuffer( , byid=TRUE)
>>> fail
Oops. The post's title should have read "rgeos::gBuffer( , byid=TRUE)
fails when...". (I inadvertently left out the `byid=TRUE` bit).
My apologies.
On Mon, Feb 8, 2016 at 9:59 AM, Josh O'Brien <joshmobr...@gmail.com> wrote:
> Hello,
>
> Not sure if this would be con
art @Polygons object in @polygons
gBuffer(x[1,], width=0.01, byid=TRUE)
## Fails with a single _multi-part_ @Polygons object in @polygons
gBuffer(x[2,], width=0.01, byid=TRUE)
Thanks (and please let me know an rgeos-specific note like this would
be better
Here is a good start, at least:
library(rgl)
## Helper functions
isLeaf <- function(x) {
length(gregexpr("(", x, fixed=TRUE)[[1]]) == 1
}
extractBranches <- function(x) {
x <- gsub("^\\(|\\)$", "", x)
pattern <- "\\(((?>[^()]+|(?R))*)\\)"
m <- gregexpr(pattern, x, perl=TRUE)
On Fri, Dec 20, 2013 at 5:38 AM, Roger Bivand roger.biv...@nhh.no wrote:
On Thu, 19 Dec 2013, Josh O'Brien wrote:
On Thu, Dec 19, 2013 at 4:23 AM, Roger Bivand roger.biv...@nhh.no
wrote:
On Wed, 18 Dec 2013, Josh O'Brien wrote:
...snip...
By the way, always avoid accessing S4 objects
On Thu, Dec 19, 2013 at 4:23 AM, Roger Bivand roger.biv...@nhh.no wrote:
On Wed, 18 Dec 2013, Josh O'Brien wrote:
...snip...
By the way, always avoid accessing S4 objects directly using @, do use
slot(obj, slotname) - the sapply should read:
area = sapply(slot(SPclus, polygons), slot, area
This is cross-posted from StackOverflow
(http://stackoverflow.com/questions/20659186/combining-polygons-and-calculating-their-area-i-e-number-of-cells-in-r),
where it has received an answer that I believe answers both questions.
--
View this message in context:
Bastien Ferland-Raymond wrote
Hello Étienne,
I'm a little disappointed nobody replied to your question, as this is
something I'm also interested in. The slot you are proposing to add
metadata to raster* object could also be useful to allow categorical
raster, something the raster package
that raster's plot does (well, I
find it hard to do - I've tried a few times to figure out where these
problems are happening).
Cheers, Mike.
On Wed, Dec 4, 2013 at 5:57 AM, Josh O'Brien joshmobr...@gmail.com
wrote:
Hi all,
Briefly, running the following code will not produce a single
Hi all,
Briefly, running the following code will not produce a single grey ring, as
would be expected. The first three raster layers all stack up neatly, but
the 4th and subsequent raster layers are all shifted/skewed to the right.
It appears that the plotting engine loses track of the fact that
Hello,
Is there a better / more official / less error-prone way than the
following to check the equivalence of two PROJ4 strings?
checkProjEquivalence - function(SP, crs1, crs2) {
cc1 - coordinates(spTransform(SP, crs1))
cc2 - coordinates(spTransform(SP, crs2))
identical(cc1, cc2)
}
Robert Hijmans wrote
Josh,
Thanks for reporting this, I will make 'crop' more conservative. The
easiest way to deal with this (I believe rare) problem is to change the
default setting of maxmemory:
rasterOptions(maxmemory=1e+07)
After that,
crop(r, E, filename=smallerRast)
will
Hi all,
The raster package function crop() can fail for certain sufficiently
large cropping extents (in terms of number of rows and columns needing
to be extracted).
The raster I'd like to crop is stored on the disk (i.e. fromDisk(r)
-- TRUE) and I'm writing the results to a file: the problem
13 matches
Mail list logo
