You can first convert all tif input as a single vrt, then run the gdal.Warp
from pathlib import Path
from osgeo import gdal
tifs = [str(p) for p in Path('.').glob('*.tiff')]
my_vrt = gdal.BuildVRT(vrt_name, tifs)
my_vrt = None
ds_input = gdal.OpenEx(vrt_name, gdal.OF_RASTER)
ds = gdal.Warp('output.tif', ds_input, options="-...
You most probably do not want to compress DEM data with JPEG, that would be lossy and introduce weird steps in the data.
Instead I recommend the DEFLATE compression. To improve the size savings you can also use a predictor for the compressor. See https://gdal.org/drivers/raster/gtiff.html for details and more options.
for %i in (*.tif) do gdal_translate -of ...
GDAL virtual filesystems have a path so you can refer to them just like you would a regular file on disk. They're distinguished by the /vsi*/ prefix. This allows you to access less standard types of files, such as in-memory files, compressed files (.zip, .gz, .tar, .tar.gz archives), encrypted files, files stored on the network without modifying your code ...
From your code it appears that you're trying to move the image half a pixel in the x and y direction. As @mikewatt suggests above this is much easier using rasterio and affine.
The affine library is a simple wrapper around Affine transformations. This is important when you're dealing with raster data as the coordinates of raster data consist of:
The map ...
The issue was about opening implicitly with the "wrong" driver. Seen by setting CPL_DEBUG to ON. When I was trying to establish the connexion, I got
GDAL: GDALOpen(PG:host=localhost user=username dbname=mydatabase password=XXX port=5432, this=0x2972350) succeeds as PostGISRaster.
Forcing the driver to understand my data source was vector (...
gdal.Grid is expecting a GDALDataset object, not an OGRDataSource. As of GDAL 2.0 OGR is deprecated and GDAL can open raster and vector data. Use gdal.OpenEx to open your vector as a GDALDataset:
You can use the gdal.VectorTranslate function (basically the same as ogr2ogr commandline utility):
from osgeo import gdal
pbf = 'https://ahocevar.com/geoserver/gwc/service/tms/1.0.0/ne:ne_10m_admin_0_countries@EPSG:900913@pbf/3/2/4.pbf'
ds = gdal.OpenEx(pbf, gdal.OF_VECTOR) # note use of gdal.OpenEx, ogr is deprecated from gdal 2.0+
The cause: It seems to be due to a PostgreSQL change that occurred in version 12.0. Namely, the extra_float_digits parameter that is now being used for pg_dump and pg_dumpall functions (see here: https://www.postgresql.org/docs/release/12.0/ and here: https://www.postgresql.org/docs/12/runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS).
The solution: Set the ...
I am not sure if this is a GDAL issue. Perhaps it is not an issue at all but rounding errors just belong to conversions between decimal numbers and binary values that computers are using.
I stored your data into PostGIS with GDAL 3.3.0 and the geometry appears to be in the database with unaltered precision when queried this way:
You can greatly simplify the operation using gdal.VectorTranslate
from osgeo import gdal
# Open the raster tif and extract crs
t = "path/to/raster.tif"
tif = gdal.Open(t)
crs1 = tif.GetProjectionRef()
tif = None
# Input shp path
s = "path/to/shapefile.shp"
# Set name of the new shapefile
sUTM = "shapefile_UTM.shp"
You can use gdallocationinfo https://gdal.org/programs/gdallocationinfo.html but the form of the report is probably not exactly as you would like it to be.
gdallocationinfo test.tif 0 0
It's very easy using a library that's designed to handle georeferenced raster data like GDAL or rasterio (based on GDAL).
import rasterio as rio
pathhr = 'C:\\Users\\dataset\\S30W051.tif'
pathout = 'C:\\Users\\dataset\\S30W051_TEST.tif'
with rio.open(pathhr) as src:
profile = src.profile
data = src.read()
data[data < 0] = 0
It looks like you're attempting to save as JPEG files. In which case GDAL would use the JPEG raster driver. The JPEG raster driver does not have a COMPRESS= creation option. See the driver's documentation at https://gdal.org/drivers/raster/jpeg.html#raster-jpeg and scroll down to see the list of creation options.
In fact, setting a compression option to ...
This should be enough for changing the geotransformation (captured from GDAL autotests https://github.com/OSGeo/gdal/blob/master/autotest/gcore/tiff_write.py):
ds = gdal.Open('tmp/tiff57.tif', gdal.GA_Update)
ds.SetGeoTransform([100, 1, 3, 200, 3, 1])
ds = None
It's easy using a library that's designed to handle georeferenced raster data like GDAL or rasterio (based on GDAL).
Here is an example based on the docs for reprojecting with rasterio:
import numpy as np
import rasterio as rio
from rasterio.warp import calculate_default_transform, reproject, Resampling
from sklearn.impute import SimpleImputer
pathhr = 'C:\\...
If the aim is just to divide the image into two values, one for data and another for nodata and exact values are not so important, a short gdal_calc https://gdal.org/programs/gdal_calc.html command can do it.
gdal_calc -A src.tif --outfile=out.tif --type=Byte --calc="255*(A>-9999)"
The command creates a single band, 8-bit GeoTIFF because there ...
I think this was the error:
In : msk.GetGeoTransform()
In : new.GetGeoTransform()
I probably could have found this problem. But I didn't (...
After extensive testing, the problem is now solved (at least for my case, where a random value, but not a mean is desired):
As user30184 supposed, the desired behavior is the default. It appears the value assigned to the raster pixel is that of the polygon feature which was created last. The function will probably iterate through the polygon features and ...
Create a vector grid with the same extent and resolution as the raster you intend to create.
Calculate the percentage (area) each grid cell intersects with the polygons to be rasterized - see screenshot 1. Use filed calculator to create a new field with this value. To calculate the percentage, you can use this expression (replace poly with the name of your ...
Unable to reproduce the issue with the following recipe
conda create --name gdaldemo python=3.7 -y
conda activate gdaldemo
conda install -c conda-forge gdal=2.4 -y
python -m pip install gdal2tiles
# Last command to check the issue
python -c "import gdal2tiles;print(gdal2tiles.generate_tiles)"
It seems you may have a conflict between GDAL native ...
The ValueError: cannot convert float NaN to integer raised because of Pandas doesn't have the ability to store NaN values for integers. From Pandas v0.24, introduces Nullable Integer Data Types which allows integers to coexist with NaNs. This does allow integer NaNs . This is the pandas integer, instead of the numpy integer. So, use Nullable Integer Data ...
I'll add this as an answer (was originally meant as a comment). Perhaps it helps someone since there is and has been a lot of confusion about this. It expands the answers above. There is another helpful question with answers.
In short, to print the wkt comment and avoid the warnings with PROJ6 CRS objects, use sp::wkt instead of sp::proj4string: