3

I have a set of about 200 geotiff files over the UK for which I need to generate a .vrt. When I use gdalbuildvrt, it spits out multiple warnings (on about 25% of the files), which say:

Warning 6: gdalbuildvrt does not support heterogeneous projection: expected British National Grid (10 Figure Grid Reference), got OSGB 1936 / British National Grid. Skipping {*filename*}

The GDALInfo on one of these 'problematic' files is

Driver: GTiff/GeoTIFF
Files: M726-AIR_004_1-GSGS_geo_clip.tif
Size is 18896, 18898
Coordinate System is:
PROJCS["OSGB 1936 / British National Grid",
    GEOGCS["OSGB 1936",
        DATUM["OSGB_1936",
            SPHEROID["Airy 1830",6377563.396,299.3249612664951,
                AUTHORITY["EPSG","7001"]],
            AUTHORITY["EPSG","6277"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","27700"]]
Origin = (420000.189984170487151,1147000.544881728477776)
Pixel Size = (2.116805338468027,-2.116697291374624)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_XRESOLUTION=600
  TIFFTAG_YRESOLUTION=600
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  420000.190, 1147000.545) (  1d38'20.88"W, 60d12'26.73"N)
Lower Left  (  420000.190, 1106999.199) (  1d38'34.90"W, 59d50'53.59"N)
Upper Right (  459999.344, 1147000.545) (  0d55' 3.07"W, 60d12'12.60"N)
Lower Right (  459999.344, 1106999.199) (  0d55'45.13"W, 59d50'39.65"N)
Center      (  439999.767, 1126999.872) (  1d16'56.00"W, 60d 1'34.90"N)
Band 1 Block=18896x56 Type=Byte, ColorInterp=Red
Band 2 Block=18896x56 Type=Byte, ColorInterp=Green
Band 3 Block=18896x56 Type=Byte, ColorInterp=Blue

The GDALInfo on one of the 'normal' files is

Driver: GTiff/GeoTIFF
Files: M726-AIR_001_1-GSGS_geo_clip.tif
Size is 18896, 18898
Coordinate System is:
PROJCS["British National Grid (10 Figure Grid Reference)",
    GEOGCS["OSGB 1936",
        DATUM["OSGB_1936",
            SPHEROID["Airy 1830",6377563.396,299.3249646000043,
                AUTHORITY["EPSG","7001"]],
            TOWGS84[375,-111,431,0,0,0,0],
            AUTHORITY["EPSG","6277"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],
    PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",-100000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (429001.304246288083959,1219999.760539699811488)
Pixel Size = (2.116883494595527,-2.116617239070123)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_DATETIME=2015:11:17 12:48:48
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_SOFTWARE=Adobe Photoshop CS6 (Windows)
  TIFFTAG_XRESOLUTION=600
  TIFFTAG_YRESOLUTION=600
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  429001.304, 1219999.761) (  1d27'57.76"W, 60d51'44.43"N)
Lower Left  (  429001.304, 1179999.928) (  1d28'19.06"W, 60d30'11.49"N)
Upper Right (  469001.935, 1219999.761) (  0d43'47.01"W, 60d51'26.65"N)
Lower Right (  469001.935, 1179999.928) (  0d44'37.68"W, 60d29'53.97"N)
Center      (  449001.620, 1199999.844) (  1d 6'10.38"W, 60d40'50.95"N)
Band 1 Block=18896x4 Type=Byte, ColorInterp=Red
Band 2 Block=18896x4 Type=Byte, ColorInterp=Green
Band 3 Block=18896x4 Type=Byte, ColorInterp=Blue

I have had only occasional need to use gdal utilities in the past, so I'm not an expert. I was thinking I would use gdalwarp to 'fix' the problematic files so they match the others. But since the problematic files all list a PROJCS authority (AUTHORITY["EPSG","27700"]) but the 'normal' ones don't list an authority for the PROJCS, should I instead warp all the 'normal' ones to match the 'problematic' ones? The visible differences (that stand out to me) are the very slight differences in the flattening parameter and the presence of a TOWGS84 parameter in the 'normal' GEOGCS[DATUM[]].

Edited to add: When I tried using gdalwarp to apply EPSG:27700 to one of the 'normal' files, it seemed to process the file without complaint, but the file size jumped from 61MB to over 1GB. Due to my current space limitations, this 17x increase in file size won't easily work.

What might be a good way to resolve this heterogeneous projection issue so gdalbuiltvrt can succeed?

1 Answer 1

5

You can "cheat" by changing your gdalwarp output to vrt for each raster file by reprojecting to the "right" projection and then use gdalbuildvrt on all these vrt files. By doing so, you avoid the issue with intermediate files that could make your hard disk drive full.

The recipe could look like

wget http://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_36_01.zip
wget https://srtm.csi.cgiar.org/wp-content/uploads/files/srtm_5x5/TIFF/srtm_36_02.zip
unzip -o srtm_36_01.zip
unzip -o srtm_36_02.zip
gdalwarp -of VRT srtm_36_01.tif srtm_36_01_out.vrt -t_srs "EPSG:27700"
gdalwarp -of VRT srtm_36_02.tif srtm_36_02_out.vrt -t_srs "EPSG:27700"
gdalbuildvrt result.vrt *_out.vrt

You could replace both gdalwarp statements, with a loop (here for Bash so for Linux or Mac)

for i in *.tif;
  do gdalwarp -of VRT $i ${i%%.*}_out.vrt -t_srs "EPSG:27700";
done;

You will need to adapt it to your exact case. I do not know the exact loop syntax on Windows.

6
  • So, instead of warping all the outliers, I generate a .vrt for each, where the vrt defines the reprojection, then create an overall .vrt on the group? Correct me if I'm wrong, but the last three lines of your recipe seem to be the essence of this approach, yes? Apr 19, 2021 at 20:48
  • Yes, it's the idea to avoid all intermediates files
    – ThomasG77
    Apr 19, 2021 at 20:50
  • Nice! Lemme try that right quick! Apr 19, 2021 at 20:50
  • The 3 last lines are the essence of the idea as you mentioned. My sample is done to be standalone. More useful for other users that do not exactly meet your exact situation but meet the same general issue
    – ThomasG77
    Apr 19, 2021 at 20:53
  • looks like that did the trick! Thank you for your quick response. Apr 19, 2021 at 22:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.