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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
