[gdal-dev] GDALOpenInternal Problem Opening specific HDF5 bands

[Michele]

Thanks for the reply, Even!  
I can do gdalinfo c:\pathToFile\filename.h5.
What do you mean, " try accessing the subdataset it will report. The expected syntax is like HDF5:"c:\pathToFile\filename.h5":subdataset_name"?
Do you mean gdalinfo HDF5:"c:\pathtoFile\filename.h5"://ImageData/h2?
When I do that, I get:
 ERROR 4: `HDF5:c:\pathToFile\filename.h5://ImageData/h2' does not exist in the file
and is not recognised as a supported dataset name.
gdalinfo failed - unable to open 'HDF5:c:\pathToFile\filename.h5://ImageData/h2'.
We know h2 exists because it was listed in gdalinfo for the filename.
Thanks,Michele
      From: Even Rouault <even.rouault at spatialys.com>
 To: Michele <clearlymichele at yahoo.com> 
Cc: gdal-dev at lists.osgeo.org
 Sent: Monday, October 10, 2016 9:44 AM
 Subject: Re: [gdal-dev] GDALOpenInternal Problem Opening specific HDF5 bands
   
Le lundi 10 octobre 2016 15:20:08, Michele a écrit :
> I'm trying to open an HDF5 file, specific bands, but GDAL is giving an
> error message: 
> 
> > "'HDF5:C:\pathToFile\pathToFile/filename.h5://ImageData/B4' does not>
> > exist in the file system and is not recognized as a supported data set>
> > name"
> 
> I got the error message after the GDALOpenInternal call using
> CPLGetLastErrorMsg().  I can't step into GDALOpenInternal (with Visual
> Studio) because we don't have GDAL source cpp file; just h file that came
> with the package, unless I'm searching for the wrong file name. The string
> for the ConnectionString parameter for GDALOpenInternal is shown in the
> quotes above. I found [qgis polygonize error 4 "file does not exist in the
> file system"], but they said it was because of using non-ascii characters
> in file path string.  I didn't see any other pertinent info on this error
> message. We need to access the specific band of the HDF5 file.  I noticed
> that our slashes in the path are showing in different directions, but I'm
> not sure that would be the issue here.  We have both windows and linux
> OS's.  This error was seen on windows os. We used (gdalinfo.exe
> filename.h5) and do see that the B4 exists there. Using the string,
> HDF5:"C:\pathToFile\filename.h5"://ImageData/B2, didn't work for
> openInternal with GDAL.
> 
> I saw  (gdal.org/gdal_tutorial.html), which gives an example to open a band
> after a GDALOpen, but it seems that it's supposed to work with
> GDALOpenInternal also according to my co-workers. We just don't have a
> good example of the connection string to get it working with
> GDALOpenInternal since we don't have access to that part of the code that
> does it. They want me to focus on using GDALOpenInternal.
> 
> I'm
> seeing lists.alioth.debian.org/pipermail/pkg-grass-devel/2012-Novem‌​ber/…
> , which gives me hope, but doesn't have a good example. I saw this which
> could be an example, although it isn't using a path, but I'm not sure:
> gdalwarp HDF4_SDS:ASTER_L1B:"pg-PR1B0000-2002031402_100_001":2
> pg-PR1B0000-2002031402_100_001_2.tif
> 
> My question is, what format for the connection string do I need to use
> GDALOpenInternal, if it's not what I show for the two things I tried
> above? 

You should try first 

gdalinfo c:\pathToFile\filename.h5

and then, if that opens, try accessing the subdataset it will report. The 
expected syntax is like HDF5:"c:\pathToFile\filename.h5":subdataset_name

Since you seem to mention that the path contains non ASCII characters, I 
wouldn't be surprise if that didn't work correctly on Windows. You should 
perhaps try making sure your path is encoded in the current ANSI code page of 
your system since that's probably what the HDF5 API expects.

Would probably make sense for GDAL to recode from UTF-8 to current ANSI code 
page automagically as it does in the XLS driver:

#ifdef _WIN32
    if( CPLTestBool( CPLGetConfigOption( "GDAL_FILENAME_IS_UTF8", "YES" ) ) )
        pszName = CPLRecode( pszFilename, CPL_ENC_UTF8, CPLString().Printf( 
"CP%d", GetACP() ) );
    else
        pszName = CPLStrdup( pszFilename );
#else
    pszName = CPLStrdup( pszFilename );
#endif

That assumes that the accentued characters you need can be expressed in the 
current ANSI code page, otherwise you'll have to move the file elsewhere

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161010/75b0b4cb/attachment-0001.html>