[gdal-dev] gdalbuildvrt problem with heterogenous bandcharacteristics
Nicolas Simon
nicolas.simon at spw.wallonie.be
Thu Aug 16 08:24:55 PDT 2012
Hello,
The problem comes from the data type: Int16 for the first file, Float32 for the second file.
Nicolas
-----Message d'origine-----
De : gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org]De la part de Margherita Di Leo
Envoyé : jeudi 16 août 2012 17:15
À : Even Rouault
Cc : gdal-dev at lists.osgeo.org
Objet : Re: [gdal-dev] gdalbuildvrt problem with heterogenous bandcharacteristics
On Thu, Aug 16, 2012 at 4:32 PM, Even Rouault < even.rouault at mines-paris.org> wrote:
Selon Margherita Di Leo < diregola at gmail.com>:
> Hi All,
>
> On Mon, Jul 30, 2012 at 7:31 PM, Casper Børgesen (CABO) < CABO at niras.dk>wrote:
>
> > Hi! ****
> >
> > ** **
> >
> > I’m trying to create a VRT file from 4 GeoTIFFs using gdalbuildvrt. Three
> > of the GeoTIFFs are created using OrthoVista and the last one created with
> > an earlier version of the same program. When I run gdalbuildvrt I get the
> > following error message when I try to add the file created by the early
> > version: ****
> >
> > ** **
> >
> > Warning 6: gdalbuildvrt does not support heterogenous band
> > characteristics. Skipping...****
> >
> > ** **
> >
> > I get the same error message, so may be related... I've tried to make a
> virtual mosaic, using SRTM DEMs,
>
> gdalbuildvrt -input_file_list list.txt STM_CP-DEMS_EU_mosaic.vrt
>
> and got:
>
> 0...Warning 6: gdalbuildvrt does not support heterogenous band
> characteristics. Skipping STM_CP-DEMS_2500015000.tif
> 10.Warning 6: gdalbuildvrt does not support heterogenous band
> characteristics. Skipping STM_CP-DEMS_2500025000.tif
> ..Warning 6: gdalbuildvrt does not support heterogenous band
> characteristics. Skipping STM_CP-DEMS_2500035000.tif
> [....]
>
> Hence, I made my mosaic using:
> gdalwarp --optfile list.txt STM_CP-DEMS_EU_mosaic.tif
> It took a bit more time obviously, but it didn't complain.
>
> So.. Could it be a bug of gdalbuildvrt, or.. ?
I don't think it is a bug. gdalbuildvrt is a "lightweight" but restrictive
mosaicing solution, whereas gdalwarp is "heavier" but more capable.
gdalbuildvrt makes various checks to ensure that the tiles to be mosaiced are
very similar. Perhaps some of the tests are too restrictive. You should try to
compare the output of gdalinfo between a file that is integrated into the VRT
and one that is skipped to see which differences there are (band data type,
presence/absence of color table, color interpretation, etc...)
Even, thank you for replying. Actually the files are all skipped, except the first one of course. About this file, gdalinfo says:
gdalinfo STM_CP-DEMS_1790010475.tif
Driver: GTiff/GeoTIFF
Files: STM_CP-DEMS_1790010475.tif
Size is 5000, 2250
Coordinate System is:
PROJCS["ETRS89 / LAEA Europe",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221000027,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",52],
PARAMETER["longitude_of_center",10],
PARAMETER["false_easting",4321000],
PARAMETER["false_northing",3210000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","3035"]]
Origin = (1540000.000000000000000,1160000.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_DATETIME=2010:08:09 09:37:53
TIFFTAG_DOCUMENTNAME=STM_CP-DEMS_1790010475.tif
TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
TIFFTAG_SOFTWARE=IDL 7.1.1, ITT Visual Information Solutions
TIFFTAG_XRESOLUTION=100
TIFFTAG_YRESOLUTION=100
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 1540000.000, 1160000.000) ( 18d35'52.39"W, 28d46'34.65"N)
Lower Left ( 1540000.000, 935000.000) ( 17d57'14.30"W, 26d50'46.78"N)
Upper Right ( 2040000.000, 1160000.000) ( 13d41'27.23"W, 30d17'11.28"N)
Lower Right ( 2040000.000, 935000.000) ( 13d 8'11.03"W, 28d19' 3.39"N)
Center ( 1790000.000, 1047500.000) ( 15d51'19.76"W, 28d35'33.72"N)
Band 1 Block=5000x1 Type=Int16, ColorInterp=Gray
So I take a skipped file for comparison:
gdalinfo STM_CP-DEMS_2500015000.tif
Driver: GTiff/GeoTIFF
Files: STM_CP-DEMS_2500015000.tif
Size is 10000, 10000
Coordinate System is:
PROJCS["ETRS89 / LAEA Europe",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221000027,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",52],
PARAMETER["longitude_of_center",10],
PARAMETER["false_easting",4321000],
PARAMETER["false_northing",3210000],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","3035"]]
Origin = (2000000.000000000000000,2000000.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_DATETIME=2010:08:06 10:58:28
TIFFTAG_DOCUMENTNAME=STM_CP-DEMS_2500015000.tif
TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
TIFFTAG_SOFTWARE=IDL 7.1.1, ITT Visual Information Solutions
TIFFTAG_XRESOLUTION=100
TIFFTAG_YRESOLUTION=100
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 2000000.000, 2000000.000) ( 16d36'13.25"W, 37d23'21.20"N)
Lower Left ( 2000000.000, 1000000.000) ( 13d41' 3.88"W, 28d46'45.49"N)
Upper Right ( 3000000.000, 2000000.000) ( 5d28'46.07"W, 39d52'33.70"N)
Lower Right ( 3000000.000, 1000000.000) ( 3d40'26.43"W, 30d56'55.67"N)
Center ( 2500000.000, 1500000.000) ( 9d49'34.83"W, 34d25'40.17"N)
Band 1 Block=10000x1 Type=Float32, ColorInterp=Gray
I can't see anything obvious why these two files can't be mosaiced..
Thanks,
--
Dr. Margherita Di Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120816/2c72c3ef/attachment.html>
More information about the gdal-dev
mailing list