Le 28/06/2016 à 12:39, Even Rouault a écrit :
There would be likely changes to do in:
- GDALOpen(), to detect a syntax like
"DERIVED_SUBDATASET:Amplitude:original_datasetname" and create the appropriate
dataset. Hum, or perhaps better, instead of hacking GDALOpen(), having a
driver that would recognize this syntax and instanciate the proper derived
dataset.
- GDALDataset::GetMetadata( pszDomain ) when pszDomain equals "SUBDATASETS"
-> with the issue I mentionned for drivers that already implement subdatasets
and will not call the base method.
Hum, or perhaps a better solution would be to have a new metadata domain
"DERIVED_SUBDATASETS". Would solve the potential confusion between "natural"
and derived subdatasets, and would probably require little/no changes in
drivers. Would not confuse gdal_translate -sds. Could be used by mapserver
unmodified. But would require QGIS querying this new metadata domain.
To check if I understood well :
I will create a driver that will recognize the
"DERIVED_SUBDATASET:Amplitude:original_datasetname" syntax. This driver
needs to now if "original_datasetname" is of complex type (to report it
can open it), and will also expose the derived band somehow (can I
benefit from the CreateDerivedBand API, and the pixel functions from
Antonio ?). Also, "original_datasetname" can be a subdataset itself.
There should also be a mechanism that will report the existing
DERIVED_SUBDATASETS upon query (this I did not get yet).
I am not sure if I can figure out how to do this, but I will try.
Regards,
Julien
--
Julien MICHEL
CNES - DCT/SI/AP
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
