Tag Info

Hot answers tagged

5

The issue here is that mosaic and do.call are expecting a raster object in the list and not just character names of the raster that is contained in the "rasters1" vector. You are, in effect, asking to mosaic a name in a vector and not a raster object. # Create some example data require(raster) r <- raster(ncol=100, nrow=100) r1 <- crop(r, ...


4

You need to read the rasters in in chunks instead of all at once. See the documentation for the raster package, in particular - Writing functions for large raster files.


3

What you're trying to create is known as a bivariate map. There's a couple of ways to do this, but since you've already got raster data that leans toward certain methods. The big thing is going to be your color selections, and I'm not sure exactly how to get the blending you desire. Typically this is done with two colors, one for each variable. So A 0 = ...


3

First of all, I agree with @SS_Rebelious. Your "zipcoords" object seems to represent a common data extent so, rather than creating a list object, why not just create a stack object of your rasters and extract everything at once? If common extents are a problem in the rasters, you can use the "quick=TRUE" argument in stack() to override the extent error. ...


3

This set of extracts from OSM data may be what you're looking for. In particular, this shapefile of the coastline around Helsinki.


2

For geoprocessing, I suggest to turn on-the-fly-reprojection in QGIS OFF to see whether your shapes align or not. In many cases, geoprocessing does nor work when the shapes are in different CRS. So save your polygon layer as WGS84 EPSG:4326 (do NOT use Set CRS for Layer for that!), to match with the points layer coordinates. For the NaturalEarth dataset, it ...


2

The problem was that I had run out of space to write to disk, and the map algebra commands I was using were attempting to generate and write large temporary raster files.


2

After a lot of attempts I have this solution, probably not so clean. Comments, improvements or other way to answer are much welcome! ### Preparing the SpatialPointsDataFrame spdf <- matrix(as.numeric(NA), nlevels(Poly$MatchID), 1) spdf <- as.list(spdf) ### Sample the coordinate, match it with data in spdf. It creates a list fore each factor of the ...


1

I believe what you are experiencing is more or less a copy of this question. The coordinates in the rainfall data are in longitude/latitude, but with values ranging from 0 to 360, instead of -180 to 180 (as your political boundaries are). See the GPCC spatial note here (emphasis mine): Spatial Coverage: 0.5 degree latitude x 0.5 degree ...


1

After all I found solution, but not sure if that is right and elegant. I used proj4 string that SeaWifs level 3 have: s_srs="+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" and overwrite georeferenced bounds by the values from SeaWifs hdf file a_ullr =c(-20037508.343,10018754.171,20037508.343,-10018754.171) after ...


1

Why not just sort the string? identical(sort(unlist(strsplit(sp1@proj4string@projargs, ' '))), sort(unlist(strsplit(sp2@proj4string@projargs, ' '))))


1

I thought I'd answer this myself just in case anyone else with a similar problem ever stumbles on this. Using the above advice on converting my Cartesian coordinates to polar coordinates, I've made a function which calculates a minimum enclosing circle around the x,y coordinates, and divides this circle into a user-defined number of 'grid' cells with equal ...


1

To me, the simplest approach is to probably convert your XY datapoints to the polar coordinate system that defines your circular 'arena'. Be sure to convert your XY coordinates such that the center of your circle is the origin of your Cartesian grid before converting to polar coordinates. Almost all math texts would provide these straightforward conversion ...


1

I dont think thereĀ“s a faster way to do that, but what you can do is a list in a table with the name of each multilayerraster with an identifier (column names: id & name, in this order). So you can write this: #load the table with the name of the image & id list<-read.table("Table.txt",header=T) # select "automatic" correlative id id<-id+1 ...


1

The WLmap2_polyline data is using WGS 1984 UTM zone 24N, but the data is actually in zone 20N. Denmark uses a wide-area implementation of transverse Mercator for Greenland. I checked against ArcGIS and our "complex math" version of TM doesn't improve the offset. Or the data was projected into UTM 24N using the a more standard UTM implementation and that's ...



Only top voted, non community-wiki answers of a minimum length are eligible