[gdal-dev] Amplitude virtual bands for complex datasets ?

[Even Rouault]

Le lundi 04 juillet 2016 14:30:26, Julien Michel a écrit :
> Hi,
> 
> Started the work here :
> 
> https://github.com/OSGeo/gdal/compare/trunk...jmichel-otb:enhance-complex-d
> atasets
> 
> For now, recognizes the following syntax :
> 
> gdal_translate -srcwin 1000 1000 1000 1000
> DERIVED_SUBDATASET:COMPLEX_AMPLITUDE:s1a-s6-slc-vv-20150619t195043-20150619
> t195101-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.

frmts/vrt seem to be the appropriate place, and make the VRTDriver register 
them.

> 
> 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

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