Frank,<br><br><div class="gmail_quote">On 16 April 2010 19:25, Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Jose Gomez-Dans wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Running gdalinfo -stats on the new filename proceeds reporting the expected information, band by band... slowly but surely, until it reaches band 33 (it's band 33 everytime, even with different datasets):<br></blockquote>
</div></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
</blockquote></div>
I suspect the HDF library is using a table of file accessors that is only<br>
32 large,so when GDAL tries to open a 33rd file things fail. Your workaround<br>
of translating to geotiff and working with that should be fine. <br></blockquote><div><br>So this is the case, and in fact it is mentioned on the HDF GDAL driver page: <br><<a href="http://www.gdal.org/frmt_hdf4.html">http://www.gdal.org/frmt_hdf4.html</a>> (section Driver building). <br>
<br>I was quite bemused, and thought that maybe this 33 number would change if I ran my script on different dates or jupiter/Mars positions in the sky X-) Glad to hear the answer is much simpler than that!<br><br>Thanks a lot,<br>
Jose<br></div></div><br>