[Gdal-dev] max number of simplesources in vrt rasterband?

Mon Feb 9 03:50:50 EST 2004

CC-ing this to the list, as others might be interested and Frank might want to 
have a look at my described findings of a possible bug/feature regarding BIL 
header reading (see below).
FYI, this thread is about automatically bulk generation of 1) bil header files 
for srtm binary tiles, and 2) a srtm.vrt file that encompasses all these 
tiles and thus can be used as a generic height data coverage for the entire 
earth (if all data are available).

On Monday 09 February 2004 07:00, you wrote:
> Vincent,
>
> On Thu, Feb 05, 2004 at 10:17:27AM +0100, Vincent Schut wrote:
> > Markus,
> >
> > I am not entierly sure that mine are not shifted, however, they appear
> > quite OK when comparing with landsat and even Ikonos imagery.
>
> This sounds very good!
>
> > For generating the header file, I used the website
> > http://www.uweb.ucsb.edu/~nico/comp/bil_header.htm, but I changed the
> > corner coordinates to whole degrees instead of (degrees -/+ half a
> > pixelsize). That is because the srtm filename coordinates are said to be
> > the *center* of the UL pixel. GDAL uses *corners* of pixels for its
> > coordinates, and when checking the corners for a srtm/hdr file
> > combination made exactly according the website above, GDAL reports corner
> > coordinates that are shifted hafl a pixelsize. I don't know if it is an
> > error in GDAL reading .bil headers, or an error on that website. But
> > after removing the addition/subtraction of 0.0004166667 of the UL pixel
> > coordinates, gdalinfo imho reports the right corners: an overlap of
> > 0.0004166667 on each side of the whole degree lines, instead of
> > 0.000833333 on one side and none on the other.
>
> Maybe it were useful to bring up that issue on 'gdal' ML to be sure
> that BIL is read correctly.
[Frank and/or others that know more about gdal & bil, you might want to check 
the above mentioned.]
>
> > Attached you will find my python script that checks the current dir for
> > .hgt files, creates a .hdr file for them if there isn't one already, and
> > creates a file called srtm.vrt that contains all the srtm tiles found.
> > The srtm.vrt file is always of world size for script simplicity sake. Run
> > it in a directory with unzipped srtm data and you will end up with
> > srtm.vrt file that encompasses the entire world in latlong/wgs84
> > coordinates, and from which you can extract data very easily with
> > gdal_translate, e.g.: gdal_translate -projwin 116 0 117 -2 srtm.vrt
> > sungaiwain.srtm.tif to create a 16bit geotiff of 1 by 2 degrees of a
> > swamp forest / nature reserve called 'Sungai Wain' at the south-east of
> > Kalimantan (Borneo), Indonesia. That means, if you appear to have the
> > srtm tiles for that area. Otherwise you will get 0's, I guess...
> >
> > Also attached is my current srtm.vrt which is quite large because I
> > already have South America and the lower half of EurAsia included...
> >
> > I would appreciate your findings on the usefullness of the script and the
> > correctness of the placing of the srtm data. I am eager to hear! :-)
>
> I tried, but I got some unusual results:
>
> gdalinfo N53E007.bil
> Driver: EHdr/ESRI .hdr Labelled
> Size is 1201, 1201
> Coordinate System is '
> Origin = (52.999583,7.000417)
> Pixel Size = (0.00083333,-0.00083333)
> Corner Coordinates:
> Upper Left  (  52.9995833,   7.0004167)
> Lower Left  (  52.9995833,   5.9995833)
> Upper Right (  54.0004167,   7.0004167)
> Lower Right (  54.0004167,   5.9995833)
> Center      (  53.5000000,   6.5000000)
> Band 1 Block=1201x1 Type=Int16, ColorInterp=Undefined
>   NoData Value=-32768
>
> If I am not wrong, X and Y are flipped. The N53E007 map should
> cover Southern Germany. Am I missing something?

Right, my mistake. Flipped x and y coordinates in bil header writing. Mind 
though that this is of no influence on the usability of the final vrt file, 
as it uses pixel offsets instead of geographic coordinates, and these pixel 
offsets were calculated and written correctly.

A new version of the script with also another error fixed (you could not read 
the srtm.vrt file from outside the srtm directory due to missing directory 
prefixes in the xml descriptions) is attached.
>
> > I hope you find the script usefull. If so, and it appears correct, maybe
> > I should post it on the GDAL mailling list...
>
> Generally yes, but I would like to understand above problem :-)
>
> Thanks for your quick help!
Welcome!
>
>  Markus
>
> > Cheers,
> > Vincent.
> >
> > On Wednesday 04 February 2004 18:11, you wrote:
> > > Vincent,
> > >
> > > I'm a GDAL user and have written a script to generate the BIL
> > > header for the SRTM data.
> > > Would you mind to send me an example of your vrt files
> > > so that I can verify if my header is constructed correctly
> > > from the SRTM file name? I have the impression that "my" SRTM
> > > data are shifted.
> > >
> > > Thanks in advance
> > >
> > >  Markus Neteler
> > >
> > > On Tue, Feb 03, 2004 at 06:04:22PM +0100, Vincent Schut wrote:
> > > > Folks,
> > > >
> > > > I have a vrt file with approx. 1800 simplesource items (SRTM tiles).
> > > > Gdal always gives an error (with gdalinfo, gdal_translate, ...) for
> > > > the 1020th file in the vrt file. If I try to open this individual
> > > > raster file with gdal, everything goes fine. If I change the order of
> > > > the simplesources, the error still comes at the 1020th simplesource
> > > > (which is another raster file then) So I suspect there is a maximum
> > > > at the number of simplesources that can be defined in one vrt file?
> > > > If so, is it possible to enlarge this number?
> > > >
> > > > Cheers,
> > > > Vincent.

-- 
-----------------------------
 Vincent Schut
 SarVision B.V.
 Wageningen, The Netherlands
 www.sarvision.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: srtm_create_vrt.py
Type: application/x-python
Size: 3251 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040209/92faad59/srtm_create_vrt.bin