Hi,
Started the work here :
https://github.com/OSGeo/gdal/compare/trunk...jmichel-otb:enhance-complex-datasets
For now, recognizes the following syntax :
gdal_translate -srcwin 1000 1000 1000 1000
DERIVED_SUBDATASET:COMPLEX_AMPLITUDE:s1a-s6-slc-vv-20150619t195043-20150619t195101-006447-00887d-001.tiff
~/tmp/test.tif
I need to see about exposing those derived datasets properly.
Antonio, I copied one of your pixel function for fast prototyping, I
hope you do not mind. Of course upon completion of this work we should
merge properly all your pixel functions with proper
credits/copyright/licence. Thing is I did not know where to put them
within gdal.
Regards,
Julien
Le 04/07/2016 à 11:06, Even Rouault a écrit :
Hi,
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)
That or we could also possibly accept non-complex types (assume imaginary part
= 0). Antonio's functions handle complex & non-complex AFAICS
, and will also expose the derived band somehow (can I
benefit from the CreateDerivedBand API,
If you write it, yes... (it doesn't exist yet if I wasn't clear)
If you follow the VRT pixel function road, that's a matter of building a on-
the-fly VRT dataset.
http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_creation could possibly be
used. But AFAICS setting the pixel function name isn't supported. Could be
done by implementing CPLErr VRTSourcedRasterBand::SetMetadataItem( const char
*pszName, const char *pszValue, const char *pszDomain ), similarly to what
VRTSourcedRasterBand::SetMetadataItem(...) handles for vrt sources.
and the pixel functions from Antonio ?).
Would make sense to internalize this code (uses X/MIT license)
Also, "original_datasetname" can be a subdataset itself.
Yes, that shouldn't matter to the driver. It is just a string that it provides
to GDALOpen() (some care must be taken when parsing
DERIVED_SUBDATASET:algname:original_datasetname, since original_datasetname
can have columns too)
There should also be a mechanism that will report the existing
DERIVED_SUBDATASETS upon query (this I did not get yet).
Implement in GDALDataset, the following method (from GDALMajorObject)
virtual char **GetMetadata( const char * pszDomain = "" );
char **GDALDataset::GetMetadata( const char * pszDomain = "" )
{
if( pszDomain != NULL && EQUAL(pszDomain, "DERIVED_SUBDATASET") )
{
// some stuff. Be careful that ownership of returned char**
belongs
// to the dataset object
}
else
return GDALMajorObject::GetMetadata(pszDomain);
}
As well as :
virtual char **GetMetadataDomainList(); to report DERIVED_SUBDATASET when it
makes sense (contrary to GetMetadata(), ownership of the returned char**
belongs to the caller)
Even
--
Julien MICHEL
CNES - DCT/SI/AP - BPI 1219
18, avenue Edouard Belin
31401 Toulouse Cedex 09 - France
Tel: +33 561 282 894 - Fax: +33 561 283 109
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
