I would like to make a piece of code I have more efficient.
Right now I download Sentinel-2 data in jp2 format via the open acceshub. The jp2 files that I download have, for some reason, a wrong extent. Right now I correct this in the following way (in which file is the filename of the jp2):
r = raster(file)
extent(r) = new_extent
writeRaster(r, file)
This method, however, writes the entire raster (which takes ages) whereas I only changed a minor detail.
Is there a neat way using gdal or the raster package to do this more efficiently?
If I print the raster I see:
class : RasterLayer
dimensions : 1830, 1830, 3348900 (nrow, ncol, ncell)
resolution : 60, 60 (x, y)
extent : 499980, 609780, 6690240, 6800040 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=utm +zone=55 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0
data source : /home/daniel/R/farmhack/x.jp2
names : x
values : 0, 65535 (min, max)
I do not know what this extent means.
Related
I'm merging two MODIS DSR tiles using a R script that I developed, these are the products:
https://drive.google.com/drive/folders/1RG3JkXlbaotBax-h5lEMT7lEn-ObwWsD?usp=sharing
So, I open both products (tile h15v05 and tile h16v05) from same date (2019180), then I open each SDS and merge them together (00h from h15v05 with 00h from h16v05 and so on...)
Visualisation on Panoply (using the merge option) of the two products:
Purple square is the location of the division line that separates the two tiles.
With my code I obtain a plot with pixels with different resolution (and different min/max values) and I don't understand why:
I suspect that the results obtained are due to:
1- Changing from Sinusoidal CRS to longlat WGS84 CRS;
2- Using resample (method ngb) to work with mosaic.
My code is extensive, but here are some parts of it:
# Open scientific dataset as raster
SDSs <- sds(HDFfile)
SDS <- SDSs[SDSnumber]
crs(SDS) <- crs("+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181 +b=6371007.181 +units=m +no_defs")
SDSreprojected <- project(SDS, DesiredCRS)
SDSasRaster <- as(SDSreprojected, "Raster")
# Resample SDS based on a reference SDS (SDS GMT_1200_DSR of a first product), I need to do this to be able to use mosaic
SDSresampled <- resample(SDSasRaster,ResampleReference_Raster,method='ngb')
# Create mosaic of same SDS, but first convert stack to list to use mosaic
ListWith_SameSDS_OfGroupFiles <- as.list(StackWith_SameSDS_OfGroupFiles)
ListWith_SameSDS_OfGroupFiles.mosaicargs <- ListWith_SameSDS_OfGroupFiles
ListWith_SameSDS_OfGroupFiles.mosaicargs$fun <- mean
SDSmosaic <- do.call(mosaic, ListWith_SameSDS_OfGroupFiles.mosaicargs)
# Save SDSs mosaic stack to netCDF
writeRaster(StackWith_AllMosaicSDSs_OfGroupFiles, NetCDFpath, overwrite=TRUE, format="CDF", varname= "DSR", varunit="w/m2", longname="Downward Shortwave Radiation", xname="Longitude", yname="Latitude", zname="TimeGMT", zunit="GMT")
Does anyone have an idea of what could be the cause of this mismatch between results?
print(ResampleReference_Raster)
class : RasterLayer
dimensions : 1441, 897, 1292577 (nrow, ncol, ncell)
resolution : 0.01791556, 0.006942043 (x, y)
extent : -39.16222, -23.09196, 29.99652, 40 (xmin, xmax, ymin, ymax)
crs : +proj=longlat +datum=WGS84 +no_defs
source : memory
names : MCD18A1.A2019180.h15v05.061.2020343034815
values : 227.5543, 970.2346 (min, max)
print(SDSasRaster)
class : RasterLayer
dimensions : 1399, 961, 1344439 (nrow, ncol, ncell)
resolution : 0.01515284, 0.007149989 (x, y)
extent : -26.10815, -11.54627, 29.99717, 40 (xmin, xmax, ymin, ymax)
crs : +proj=longlat +datum=WGS84 +no_defs
source : memory
names : MCD18A1.A2019180.h16v05.061.2020343040755
values : 0, 0 (min, max)
print(SDSmosaic)
class : RasterLayer
dimensions : 1441, 897, 1292577 (nrow, ncol, ncell)
resolution : 0.01791556, 0.006942043 (x, y)
extent : -39.16222, -23.09196, 29.99652, 40 (xmin, xmax, ymin, ymax)
crs : +proj=longlat +datum=WGS84 +no_defs
source : memory
names : layer
values : 0, 62.7663 (min, max)
Also, some of the islands were ignored by the script (bottom right)...
sorry I didn't reply earlier. So I think you're right that this issue is extent to which you are resampling. I think you might be able to get around this by creating a dummy raster that has the extent of the raster you want to resample, but has the resolution of the raster you want to mosaic to.Try:
dummy<-raster(ext = SDSasRaster#extent, resolution=ResampledReference_Raster#res, crs=SDSasRaster#crs)
SDS2<-resample(SDSasRaster, dummy, method="ngb")
Final<-moasic(SDS2, ResampledReference_Raster, fun=mean)
I would like to identify the correct coordinate reference system for the following ASCII raster file:
class : RasterLayer
dimensions : 2160, 4320, 9331200 (nrow, ncol, ncell)
resolution : 0.0833333, 0.0833333 (x, y)
extent : -180, 179.9999, -90, 89.99993 (xmin, xmax, ymin, ymax)
coord. ref. : NA
data source : C:/popc_0AD.asc
names : popc_0AD
I tried to guess the correct projection by setting the CRS to some of the common formats and plotting it, as suggested in related posts. But I am still not sure about the correct setting. As far as I am concerned raster and related packages do not entail any function able to estimate missing CRS information. Do you have any idea what this raster file's CRS could be or how to find out?
The extent suggests coordinates are not projected. This seems to be the extent of Earth in degrees.
Then, you may want to use EPSG 4326, which is also crs="+proj=longlat +datum=WGS84 +no_defs":
library(raster)
r <- raster("0AD_lu/cropland0AD.asc")
projection(r) <- "+proj=longlat +datum=WGS84 +no_defs"
However, it is much better to use dataset correctly built with the coordinates reference system. It is never recommended to guess it... But I know that having clean metadata is not always possible...
You have
r <- raster(nrow=2160, ncol=4320, xmn=-180, xmx=179.9999, ymn=-90, ymx=89.99993, crs=NA)
Sébastien Rochette already pointed out that this is surely lon/lat and that you can set the CRS to relfect that
crs(r) <- "+proj=longlat +datum=WGS84"
It seems to me that the extent is a bit suspect. It looks like it is supposed to be a global raster, but that there has been some loss of precision. If so, you may correct that like this:
extent(r) <- c(-180, 180, -90, 90)
To get
r
#class : RasterLayer
#dimensions : 2160, 4320, 9331200 (nrow, ncol, ncell)
#resolution : 0.08333333, 0.08333333 (x, y)
#extent : -180, 180, -90, 90 (xmin, xmax, ymin, ymax)
#crs : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
I am running a Focal function in R calculating the mode within my moving window. This is being run on a large raster with a cell size of 56m (see details below).
class : RasterLayer
dimensions : 63091, 52410, 3306599310 (nrow, ncol, ncell)
resolution : 56, 56 (x, y)
extent : -1575288, 1359672, -1486356, 2046740 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=aea +lat_1=44.75 +lat_2=55.75 +lat_0=40 +lon_0=-96 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0
data source : D:dataPath\rasterFile.tif
names : int17_5001
values : 0, 500 (min, max)
This has worked great when using smaller window sizes like 29 or 15x see below. These completed after about 48hrs.
29xFocal <- focal(
myRasterInput,
w=matrix(1,nrow=29,ncol=29),
fun=modal
)
15xFocal <- focal(
myRasterInput,
w=matrix(1,nrow=15,ncol=15),
fun=modal
)
The issue is when I try and run this for larger windows.. Specifically, I need to use a window size of ~ 180x and 300x. These have been running for almost a week and have not finished.
Any suggestions for a better way to run a focal function with larger windows on these datasets?
I want to crop a raster stack using a polygon shapefile i made in ArcGIS, however I get error that extent does not overlap.
First I create the raster stack:
test1 < stack("C:/mydir/test1.tif")
define projection
myCRS <- test1#crs
then read shapefile
myExtent <- readShapePoly("C:/mydir/loc1.shp", verbose=TRUE, proj4string=myCRS)
Crop
myCrop <- crop(test1, myExtent)
Error in .local(x, y, ...) : extents do not overlap
I have searched for a solution, but i only find that projection can be the problem, however they are definetly both in the same CRS:
> test1$test1.1
class : RasterLayer
band : 1 (of 4 bands)
dimensions : 10980, 10980, 120560400 (nrow, ncol, ncell)
resolution : 10, 10 (x, y)
extent : 6e+05, 709800, 5690220, 5800020 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=utm +zone=31 +datum=WGS84 +units=m +no_defs +ellps=WGS84
+towgs84=0,0,0
data source : C:\mydir\test1.tif
names : test1.1
values : 0, 65535 (min, max)
> myExtent
class : SpatialPolygonsDataFrame
features : 1
extent : 499386.6, 517068.2, 6840730, 6857271 (xmin, xmax, ymin, ymax)
coord. ref. : +proj=utm +zone=31 +datum=WGS84 +units=m +no_defs +ellps=WGS84
+towgs84=0,0,0
variables : 2
names : Shape_Leng, Shape_Area
min values : 67444.6461177, 283926851.657
max values : 67444.6461177, 283926851.657
The message is pretty self explanatory. Your extent do not overlap... here how to check it:
library(raster)
ext.ras <- extent(6e+05, 709800, 5690220, 5800020)
ext.pol <- extent(499386.6, 517068.2, 6840730, 6857271)
plot(ext.ras, xlim = c( 499386.6,709800), ylim= c(5690220,6857271), col="red")
plot(ext.pol, add=T, col="blue")
I've created extent object from data in your question. You see one extent in the top left corner and the other in the bottom right. Have you tried reading both files in QGIS, you could probably easily see it.
If they really are suppose to overlap, than I would suspect the way you read your shapefile. Instead of
myExtent <- readShapePoly("C:/mydir/loc1.shp", verbose=TRUE, proj4string=myCRS)
use :
library(rgdal)
myExtent <- readOGR("C:/mydir","loc1.shp")
myExtent <- spTRansform(myExtent, CRS(proj4string(test1)))
library(raster)
library(ncdf)
library(rgdal)
I am facing some issues converting UTM to latlon in a rasterBrick object. My code is below:
Example file can be found here:
https://www.dropbox.com/s/yv4opmrx1v4whpt/2013_000_CaPA_continental_v2.3-analyse_final_10km_6h_APCP.nc.7z?dl=0
rasnc<- brick('file.nc', varname = "APCP_surface")
rasnc
#class : RasterBrick
#dimensions : 824, 935, 770440, 1460 (nrow, ncol, ncell, nlayers)
#resolution : 10000, 10000 (x, y)
#extent : -5000, 9345000, -5000, 8235000 (xmin, xmax, ymin, ymax)
#coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
wgs84.p4s <- "+proj=longlat +datum=NAD83 +ellps=GRS80 +no_defs"
# reprojecting
rx <- projectRaster(from=rasnc, crs=wgs84.p4s,method="ngb")
The above does not convert from UTM to latlon. I even tried to write the file to GeoTIFF and then re-project but it still did not work.
writeRaster(rasnc, file="myfil.tif", format="GTiff", overwrite=TRUE)
Basically I am trying to:
read a netCDF file.nc using brick
convert the UTM coordinates to latlon
crop the RasterBrick object to ext <- extent(-141.01807,-52.61941,41.68144.0,83.13550)
display any of the layers using levelplot function.
The time series is 6-hourly from Jan-01-2013 to dec-01-2013
It is true my use of the older raster package version was the source of the problem as suggested by #RobertH. rasnc has no coord.ref. From the webpage (http://weather.gc.ca/grib/grib2_RDPA_ps10km_e.html) of the data modellers, it is stated a polar-stereographic (PS) grid covering North America and adjacent waters with a 10 km resolution at 60 degrees north is used. How can I get the right PS for rasnc after which I will apply projectRaster to rasnc to get latlon coordinates
The problem is that rasnc reports that it has a lon/lat coordinate reference system (#coord. ref. : +proj=longlat +datum=WGS84); which looks incorrect. If you know what it should be, (you say UTM, but what is the zone?), assign it:
crs(rasnc) <- '+proj=utm +zone=??? +datum=WGS84'
and then things should work.
The question is, how did this go wrong?
I get:
library(raster)
r <- brick("2013_000_CaPA_continental_v2.3-analyse_final_10km_6h_APCP.nc")
#Loading required namespace: ncdf4
#r
#class : RasterBrick
#dimensions : 824, 935, 770440, 1460 (nrow, ncol, ncell, nlayers)
#resolution : 10000, 10000 (x, y)
#extent : -5000, 9345000, -5000, 8235000 (xmin, xmax, ymin, ymax)
#coord. ref. : NA
which is correct as this file does not provide coordinate reference system information.
First update your version of raster (you are using ncdf instead of ncdf4, so we can see it is old); and do not leave out code (if you set the coord. ref. system yourself)