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 ...
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 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 ...
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.
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 -...
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 ...
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
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 ...
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.
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
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.