gdalinfo: potential path confusion: HDF4

[Markus Neteler]

Hi,

today I found probably a bug: When using gdalinfo on a HDF4 image,
it reports the path in an undesired position (IMHO):

gdalinfo sample_image_hdfeos/pg-PR1A0000-2001030601_001_015
         ^^^^^^^^^^^^^^^^^^^^^^--> path specified here

leads to:

[...]
  SUBDATASET_14_DESC=[700x700] ImageData (16-bit unsigned integer)
 
SUBDATASET_15_NAME=HDF4_SDS:ASTER_L1A:sample_image_hdfeos/pg-PR1A0000-2001030601_001_015:186
  SUBDATASET_15_DESC=[700x700] ImageData (16-bit unsigned integer)
[...]

The path is included the in output which may be wrong as
gdalinfo
sample_image_hdfeos/HDF4_SDS:ASTER_L1A:sample_image_hdfeos/pg-PR1A0000-2001030601_001_015:186
ERROR 4:
`sample_image_hdfeos/HDF4_SDS:ASTER_L1A:sample_image_hdfeos/pg-PR1A0000-2001030601_001_015:186'
does not exist in the file system,
and is not recognised as a supported dataset name.

does not work.

Perhaps it could be eliminated in the output by some 'basename' function.

Thanks,

 Markus Neteler

[warmerdam]

Markus, 

The semantics of the SUBDATASET_n_NAME is that the contents should be
a string that can be passed to GDALOpen() to open the subdataset without
any further manipulation of the string by the application. 

In this case the driver seems to be doing the right thing.  If you run
'gdalinfo
HDF4_SDS:ASTER_L1A:sample_image_hdfeos/pg-PR1A0000-2001030601_001_015:186' does
the command not work? 

You should not be prepending any paths to the contents of the SUBDATASET_n_NAME
normally.  Note that not all dataset or subdataset names are actual filesystem
paths, and assuming so in application code is unwise. 

I will leave this bug open for now, but so far I don't see a bug.

Best regards,

[neteler@…]

Frank,

well, as posted it does not work (for me). Result is:

'does not exist in the file system'
although I simply copy-pasted things without manually modifying
the path.

Aha!! Now I get it:
gdalinfo 0300099944KNLPwA/pg-PR1A0000-2000121903_005_055.hdf
[...]
SUBDATASET_15_NAME=HDF4_SDS:ASTER_L1A:0300099944KNLPwA/pg-PR1A0000-2000121903_005_055.hdf:186
[...]

Then:
gdalinfo HDF4_SDS:ASTER_L1A:0300099944KNLPwA/pg-PR1A0000-2000121903_005_055.hdf:186

... works.
A bit tricky, but finally I understood it. Sorry, you may close the report.

Markus

[dron]

Markus,

Frank right, the full path to the HDF file reported in the third element of the
SUBDATASET_n_NAME field. So you don't need specify it separately, the _only_
thing you need to open subdatset is to give the full value of the corresponding
SUBDATASET_n_NAME to the GDAL.

I will describe this issue in more details in the documentation to avoid future
confusing.