In QGIS, you can use the iterator of the clip tool to iterate over the polygon shapefile, and it will clip the GeoTiff raster based on each polygon inside the polygon shapefile.
For example, the following image shows a DEM raster and a polygon shapefile overlaying the raster file. This shapefile is composed of several grid polygons:
Using Clip raster by ...
gdal_translate needs the coordinates of the corners - I don't know where your " 729000 528000" come from - I guess the width/height? No, it should be the coordinates:
gdal_translate -a_srs "+proj=gnom +lat_0=50.008 +lon_0=14.447" -a_ullr -301500 +217500 427500 -310500 QQNDR.png located.tiff
Another change I've made is to name the output .tiff since its a ...
In other words, you want to create a World file from the coordinates of the 4 corners and the width and height of the image
1) You get the width and height of the image with osgeo.gdal, rasterio or any other libraries to open image files as Pillow and others.
dataset = rasterio.open('satel.tif')
rasterx = dataset.width
rastery = dataset.height
2) you ...
From the GDAL doc:
The driver does support creating new files, but the input data must be exactly formatted as a SRTM-3 or SRTM-1 cell. That is the size, and bounds must be appropriate for a cell.
The output of yourgdal_translate command is pretty clear. Your data needs to be in WGS84 (epsg 4326), be 1201x1201 (cellsize=0.00083333333) or 3601x3601 (...
Your existing data is compressed. You're getting an increase in file-size because the default is uncompressed and you aren't specifying a compression option (-co compress=LZW).
However, it's a longstanding issue that gdalwarp doesn't deal with compression well. The solution is to gdalwarp without compression then gdal_translate with compression.
To avoid ...
Read https://www.gdal.org/gdalwarp.html carefully
-te xmin ymin xmax ymax:
set georeferenced extents of output file to be created (in target SRS by default, or in the SRS specified with -te_srs)
What is wrong that you have given xmin=51.50386 and xmax=-0.4333941. This should work better
-te 51.50386 -0.4333941 51.50391 -0.4333865
However, if you ...
gdalinfo on your data returned below:
Warning 1: Recode from UTF-8 to CP_ACP failed with the error: "Invalid argument".
Driver: netCDF/Network Common Data Format
Size is 5000, 3000
Coordinate System is:
If your first image is in EPSG:3857, it is a square. Therefore:
gdal_translate -of Gtiff -co "tfw=yes" -a_ullr -20037508.3427892 20037508.3427892 20037508.3427892 -20037508.3427892 -a_srs "EPSG:3857" "/espg-3857.tiff" "tfw.tiff"
Because 85.0511 is the result of an approximation (20037508.3427892 is also an approximation, but it is the GDAL's ...
The division in gdal is an integer division by default. You can change this behaviour by dividing with a float. In you case, simply replace 10000 by 10000.0
gdal_calc.py --type=Float32 -A C:\z\input.tif --outfile=C:\z\output.tif --calc="A/10000.0"
Note that storing in 16bit integer is more efficient than float 32, so I should think twice before running ...
Your 1st step is wrong, as the initial raster is in EPSG:4326 it should be:
gdal_translate -a_srs EPSG:4326 -a_ullr -104.7 30.8 -103.8 29.8 MRMS_RALA_LATEST.tiff projected.tiff
Then your 2nd step will correctly reproject the raster to epsg:3857 for web mercator.
We can do one error at a time:
Warning: The target file has a 'nc' extension, which is normally used by the GMT, netCDF drivers, but the requested output driver is GTiff. Is it really what you want?
If you don't want a geotiff output, which is the default. You need to set a format so add:
It might be a vector file as well as suggested in the ...
A raster is a set of cells that form a grid; each cell has a value. When you reproject a raster, you are re-drawing the grid to be aligned with a new projection. So, in the below figure, your original raster grid is shown in blue, and the reprojected grid is shown in red.
Right away you can see a problem--the grids do not align. So, for example, in the ...
Thank you very much for posting your workflow, this helped me with a similar issue I was having. In case this might be useful to somebody else, I used different python functions for my raster mosaic. In my case, the no data value for the VRT was 255 and because my data only goes from 0 to 100, I masked all the values in my VRTs greater than 100 before ...
The following approach worked pretty well.
First I build virtual raster.
gdalbuildvrt raster.vrt -srcnodata 0 -input_file_list paths.txt
paths.txt is file with following content:
Then I add a pixel function to it, as showed here https://lists.osgeo.org/pipermail/gdal-dev/2016-September/045134.html.
Pixel function is written using numpy, ...
Gdalwarp stumbles over the nodata values in the latitude and longitude bands of the netcdf file. The related bug issue is fixed in GDAL 2.4.2: https://github.com/OSGeo/gdal/issues/1451
As a workaround, I did this:
Extract the desired band to a vrt:
gdal_translate -of VRT HDF5:"input.nc"://geophysical_data/Rrs_655 -a_nodata -32767 input.vrt
Open the file ...
Here is a bit of bash script that takes an GML/JP2 image file from Sentinel-2B Level-2 10m resolution product and corrects its header. First it extracts the existing corner-coordinates using gdalinfo (twice); then it adds 10m to the two latitude values; then it writes the new corner coordinates back into the original image header using gdal_edit.py
The image ...
You can warp the image using the RPCs directly with GDAL, e.g.
gdalwarp -r cubic -to RPC_DEM=my_dem.tif -rpc -t_srs epsg:4326 my_DIMAP_file.XML my_dimap_file_warped.tif
In order to get a good result it is advisable to use a high resolution DEM.
You can do the same programmatically if you prefer by using gdal.Warp()
You could try running gdal_sieve.py to remove the zeros within your data islands; replacing them with nearby values. You will have to experiment with the parameters to get the result you want. The zero values in the resulting file become your nodata mask. You can then try stacking the mask and your original raster with gdal_merge.py -separate. Finally you ...
Importing Fiona can set some GDAL library paths, so you may want to run your subprocess using a copy of your original environment before the Fiona import changes anything.
import subprocess, os
my_env = os.environ.copy()
# do your thing
Thank you @AndreJ. This is indeed the problem and Mike from that post was helping me with this problem in a separate forum (http://r-sig-geo.2731867.n2.nabble.com/Reproject-MODIS-data-using-R-results-in-NAs-or-no-spatial-extent-td7592500.html).
The problem is that the metadata is incorrect. The MODIS GLASS product is in the cylindrical equidistant ...
This is expected. There have been several changes of behaviour between
the 2 versions. The main difference is now that the alpha channel is
returned on 16 bit unless 8 bit (unless you specify -wo
DST_ALPHA_MAX=255 , see
Assuming the bin/save files are a generic flat binary format, you don't have to do much. Just save the header to a separate *.hdr file, you may have to specify pixel type to match the binary data type.
See the GDAL EHdr format:
EHdr -- ESRI .hdr Labelled
GDAL supports reading and writing the ESRI
.hdr labeling format, often referred to as ESRI ...
I have found an efficient solution using a combination of rasterio and rasterstats. At this point it removes all georeferences (which is not required for our purposes), but these shouldn't be hard to add back in.
import numpy as np
from rasterstats.io import Raster
from PIL import Image
tif_filename = '...
The following example demonstrates how you can replicate this functionality from the command-line (which might be even more efficient).
Let us assume that you have a set of polygons (e.g. poly_extents.shp), which is located within your raster (input_image.tif). Each polygon would also have a unique field called id numbered from 1:5 (see image below).
@Shubham_geo’s approach will work, but will set this environment variable either for all users or at least your user. If you work with multiple conda environments, each of which may have a different version of gdal, it may be a better idea to have these environment variables set when you activate your conda environment. That way it will not create conflicts ...
Here is a solution that works for the Sentinel 3 Land Surface Temperature (LST) product, and it should work for the other products as well (you might need to account for different pixel steps in the lat/lon grid, though). It has been implemented in R, but it should work in any other language that can interface to GDAL.