5

I tried to follow what was suggested in How to use OS Terrain 50 in QGIS, but I got the following problem:

  • in spite of being generally able to generate .vrt files using gdalbuildvrt from unzipped .asc files, when I try to do it using /vsizip/ the resulting .vrt seems corrupted;
  • it only contains NaN values, as can be seen from the following QGIS screenshot:

    croped image

GDAL version: GDAL 1.11.2, released 2015/02/10

First few lines for a single .asc file input:

ncols 200
nrows 200
xllcorner 440000
yllcorner 1200000
cellsize 50
    -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9 -0.9

First few lines of the corresponding output:

<VRTDataset rasterXSize="200" rasterYSize="200">
  <SRS>PROJCS["British_National_Grid",GEOGCS["GCS_OSGB_1936",DATUM["OSGB_1936",SPHEROID["Airy_1830",6377563.396,299.3249646]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",400000],PARAMETER["False_Northing",-100000],PARAMETER["Central_Meridian",-2],PARAMETER["Scale_Factor",0.999601272],PARAMETER["Latitude_Of_Origin",49],UNIT["Meter",1]]</SRS>
  <GeoTransform>  4.4000000000000000e+05,  5.0000000000000000e+01,  0.0000000000000000e+00,  1.2100000000000000e+06,  0.0000000000000000e+00, -5.0000000000000000e+01</GeoTransform>
  <VRTRasterBand dataType="Float32" band="1">
    <SimpleSource>
      <SourceFilename relativeToVRT="0">/vsizip/hp40_OST50GRID_20150709.zip/HP40.asc</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="200" RasterYSize="200" DataType="Float32" BlockXSize="200" BlockYSize="1" />
      <SrcRect xOff="0" yOff="0" xSize="200" ySize="200" />
      <DstRect xOff="0" yOff="0" xSize="200" ySize="200" />
    </SimpleSource>
  </VRTRasterBand>
</VRTDataset>

Does anybody know what might cause it?

closed as off-topic by Andre Silva, nmtoken, Vince, BERA, Jochen Schwarze Feb 22 at 20:19

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This problem cannot or can no longer be reproduced. Changes to the system or to the asker's circumstances may have rendered the question obsolete, or the question does not include a procedure to enable potential answerers to reproduce the same symptoms. Such questions are off-topic as they are unlikely to help future readers, but editing them to include more details can lead to re-opening." – Andre Silva, nmtoken, Vince, BERA, Jochen Schwarze
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Vsizip is required only if the rasters remain zipped. If you're using the .asc directly, do not include /vsizip/// in the file paths you feed gdalbuidvrt. Can you confirm that you're using it on zips? Also, it won't work on zip files within zip files (how the OS ship their data). Can you post a few lines of the input and output files from gdalbuildvrt and state your GDAL version installed please? – Sorbus Jan 16 '16 at 13:12
  • I confirm that I'm trying to use it from zip files. I also confirm that I did I first extraction and I am trying to use it on the "second layer" of zip files. I know that I don't need to use vsizip if the .asc is already extracted, and so far i was using gdalbuildvrt with an input file containing the paths of the extracted .asc and everything is all right that way; I would just like to skip one step and read from the archive directly. How many lines do you need? I notice that the comment limit is easy to reach. GDAL version is GDAL 1.11.2, released 2015/02/10 – Filoz Jan 16 '16 at 23:22
  • 2
    @Sorbus, the problem was easily solved: it was just a problem of relative / absolute path; when using /vsizip/ it looks like that the path has to be absolute; if you use a relative one you won't get any error but the vrt will not be properly linked to the input file. Sorry for the loss of time. – Filoz Jan 16 '16 at 23:47
  • I'm glad you've solved it! No problem. – Sorbus Jan 16 '16 at 23:49
0

The original poster solved their own question as follows:

The problem was easily solved: it was just a problem of relative / absolute path; when using /vsizip/ it looks like that the path has to be absolute; if you use a relative one you won't get any error but the vrt will not be properly linked to the input file.

-quoted from comment by @Filoz

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