On Mon, Jul 4, 2011 at 8:52 AM, Alex Mantaut <alexmant...@suremptec.com.ar> wrote: > I would like to ask what would be the best way to implement a driver > that handles HDF5 subproducts, in a way that it doesn't interfere with the > behavior for hdf5 for files that ain't from any specific product type, and > allows to add new product types easly... (It's quite likely I will have to > add a new hdf5 product type soon) > > Because hdf5 products are just hdf5 files with a special order in the > metadata, I think that the code to interpret them should go in the > hdf5dataset (or hdf5imagedataset) to reuse the code that opens the files... > Is this okay? > > If the code for subproducts should go on the hdf5dataset (or > hdf5imagedataset) I have a doubt about design...
Alex, We have a similar issue in the HDF4 driver. The approach there has roughly been to have one or some data items in the HDF4Dataset class (or perhaps HDF4ImageDataset) which enumerates what the product is, with a generic option for anything which isn't special product. The Open() method has special logic to identify products, and harvest extra metadata depending on the product type. Rather than create subdriver's I'd suggest such using this approach, and perhaps having one 'metadata harvest" method on the driver for each subproduct. In many cases that is sufficient. I look forward to seeing your patches! Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
