I haven't found any specific commandline utility that can report if a tiff is tiled or striped. At least not directly or in a grepable form like TILED=YES.
There should be enough information in gdalinfo to make that decision, however.
I have a landsat scene, each made with gdal_translate:
landsat_tiled.tif : -co TILED=YES
landsat_notiled.tif: -co TILED=...
Unless you use os/shell specific operations i.e. grep etc... there's no way that I know of to do this from the command line with gdalinfo.
A python alternative is to use the GetDefaultRAT() method and output to XML (which is what gdalinfo does):
from osgeo import gdal
import xml.etree.ElementTree as et #I much prefer the lxml library
Are you using Python for your automated workflow? Although you specify gdalinfo in your question, you can get the raster information using Python if you have the GDAL Python bindings set up.
# Open raster in ReadOnly mode
rast_src = ".../raster.tif"
rast_open = gdal.Open(rast_src, GA_ReadOnly)
# Get georeference information: this ...
Your problem comes from adressing the subdatasets wrong.
If you run gdalinfo on the complete file it will display the names of the subdatasets:
To get the information of the first subdataset you need to feed the complete name into gdalinfo
The coordinate reference system helps to georeference the raster to the earth. At the end of the PROJCS description is the linear unit of measure: "Metre". That also sets the unit for the pixel size of 60.0 (metres).
Size is the number of pixels in the easting (left-right) and northing (up-down) directions. The northing value is negative because the start ...
What you did does edit the bounds but by the same you have destroyed the georeferencing. The original image is georeferenced with 4 ground control points and if you look at the coordinates you will notice that the image was not north-up but rotated/skewed. The right thing to do is to warp the image into a north-up image with gdalwarp
gdalwarp -of GTiff -...
There are good examples in https://gdal.org/frmt_sentinel2.html but you must follow them carefully. Use the name of the subdataset literally as it is reported by gdalinfo. The name does not stop into ".xml" but also something like ":10m:EPSG_32632" is included.
You may have an XML metadata file created from a different version of your file.
If I start with just the grib file:
$ ls -l
-rw-r--r-- 1 rowlings rowlings 189591 Apr 12 11:53 snow.grb
Then the stats are okay:
$ gdalinfo -mm -stats snow.grb
Min=-0.000 Max=0.917 Computed Min/Max=-0.000,0.917
Minimum=-0.000, Maximum=0.917, Mean=0.038, ...
The issue is that your raster is rotated. gdalinfo intentionally only reports origin and pixel size for north up rasters, it will show the full geotransform for rotated rasters.
You can extract the pixel sizes from the geotransform with a little maths (see below) so I'm not sure why GDAL doesn't report the pixel size anyway. Maybe because it might be ...
As I said in previous comments to the question, this is a known issue. A simple workaround consists into uninstalling the ECW extension. Furthermore, there's a (still open) ticket on GitHub which seems to suggest a solution. Upgrading to ECW 5.0 SDK (you can find it here) effectively solves this issue, however introduces others (e.g. no create method ...
The .kap file contains GCP information. If you want gdalinfo to report the extent in real world coordinates, use gdalwarp to reproject the coordinates:
gdalwarp -t_srs epsg:4326 11425_3.kap 11425_3.tif
Upper Left ( -82.7970104, 27.6144688) ( 82d47'49.24"W, 27d36'52.09"N)
Lower Left ( -82.7970104, 27.0521030) ( 82d47'49.24"W, 27d 3' ...
The following isn't a direct GDAL solution for your question, but it might help. The Orfeo Toolbox command otbcli_ComputeImagesStatistics can be used to generate raster band statistics and output them to an XML file. For instance:
otbcli_ComputeImagesStatistics -il input_image.tif -out output.xml
Open the file [imagename.ext].aux.xml and you will see where the numbers are coming.
Use your favorite tool and make a SQL query to the "gpkg_contents" metadata table. Every GeoPackage has this table because it is mandatory. The structure of the table is defined in the standard as:
CREATE TABLE gpkg_contents (
table_name TEXT NOT NULL PRIMARY KEY,
data_type TEXT NOT NULL,
identifier TEXT UNIQUE,
description TEXT DEFAULT '',
If using rasterio >= 1.0, use the dataset.set_band_description(self, bidx, value) method and dataset.descriptions property.
Sets the description of a dataset band.
bidx : int
Index of the band (starting with 1).
A description of the band.
descriptions = [
'Band 1 Reflectance',
'Band 2 ...
The chapter about Affine GeoTransform in http://www.gdal.org/gdal_datamodel.html gives the first hint
GDAL datasets have two ways of describing the relationship between
raster positions (in pixel/line coordinates) and georeferenced
coordinates. The first, and most commonly used is the affine transform
(the other is GCPs). The affine transform ...
You can now accomplish this with rasterio. From the example at: https://rasterio.readthedocs.io/en/latest/topics/color.html
with rasterio.open('tests/data/shade.tif') as src:
shade = src.read(1)
meta = src.meta
with rasterio.open('/tmp/colormap.tif', 'w', **meta) as dst:
It don't think you'll get this out of gdalinfo, although it would be possible if you included null cells in your calculation.
Instead, I would reclassify all non-null cells to have a value of 1, and all null cells to have a value of 0, then do a sum across the entire raster, and then multiply that value by the area of one pixel.
Pixel size is (as it sounds) the size of a pixel in the units of the raster's projection. So there is nothing you can infer from just the number, 0.00027 < 0.6 might mean that the first raster is higher resolution or it may mean one is measured in feet and the other in metres (or degrees or furlongs).
Here is the gdalinfo output for a raster I have:
@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 ...
When it comes to the origin, there are two things in the play:
If srsName="http://www.opengis.net/def/crs/EPSG/0/4326" then the coordinates in WCS DescribeCoverage are expressed in order Latitude-Longitude.
In WCS the origin means the centre of the pixel while GDAL reports the origin as the top-left corner of the top left pixel which leads to half-a-pixel ...
Yes it is possible. Also, here is a great resource Geospatial PDF
These are two examples of creating metadata as provided in the resource:
Create a PDF from 2 rasters (main_raster and another_raster), such that main_raster is initially displayed, and they are exclusively displayed :
gdal_translate -of PDF main_raster.tif my.pdf -co LAYER_NAME=...
The maintainer gisinternal site (Tamas Szekeres) answered me and solved the problem. I just had to run SDKShell.bat on the command prompt before using gdalinfo or other gdal apps.
I did exactly what I regularly reproach to other people: "you didn't read instructions!". Well, I hope this may at least be useful for other people that made the same mistake.
You are trying to adress a subdataset inside a HDF container directly. There are two ways you can do that with gdalinfo:
Put the complete name of the subdataset in parantheses gdalinfo " HDF4_EOS:EOS_GRID:MYD13A2.A2015297.h16v05.005.2015314081208.hdf:MODIS_Grid_16DAY_1km_VI:1 km 16 days NDVI"
Use the subdataset option gdalinfo -sd 1 MYD13A2.A2015297.h16v05....
For Internet People in the Future:
an ubuntu upgrade had interfered with the source-built gdal install. i am unsure what exactly was being referenced wrong, but removing the repo gdal package and rebuilding gdal seems to have removed the error.