[gdal-dev] Call for discussion for "RFC 43 GDALMajorObject::GetMetadataDomainList()"

[Kurt Schwehr]

Even,

I have been trying to think through how an OGR driver for ISO19115 /  19139 would work.  I'm going to work on a band aid to the new BAG tweak to their ISO metadata, but we definitely could use a bare driver for read / write.  The quest boils down to what is the minimal set of things that we should aim for and how tolerant of craziness should we cope with.  I've seen some "interesting" things passed off as ISO metadata.  As a start to this, I'm going to start trying to collect a range of sample files.  The timing is pretty good in that there is a discussion of FGDC to ISO conversion on the IOOS Data Management and Communications (DMAC) steering committee mailing list.

-kurt

On Oct 20, 2013, at 5:21 AM, Even Rouault <even.rouault at mines-paris.org> wrote:

> Le dimanche 20 octobre 2013 11:38:24, xavier lhomme a écrit :
>> Hi
>>  Is there a way to export Metadata in a XML form (ISO 19139 XML
>> implementation of ISO 19115 ) ?
> 
> Xavier,
> 
> This is clearly out of the scope of this RFC.
> 
> Apart from a few basic items ( raster dimensions, tiling, geotransform/GCP, 
> SRS ), GDAL drivers currently expose metadata as close as possible as the way 
> they are encoded in the format they deal with (and GDAL probably predates the 
> current metadata standards). By searching a bit, I've found a few projects 
> (but I haven't actually tried them) that would expose GDAL metadata in 
> standard ways :
>  * a QGIS plugin : MetaTools . https://github.com/nextgis/metatools 
>  * MetaGETA : Python scripts  . https://code.google.com/p/metageta/
>  * Metadata crawler of Geonetwork . 
> http://trac.osgeo.org/geonetwork/wiki/crawler
>  * ...
> 
> MetaGETA seems interesting since it has specialized code for different GDAL 
> drivers to extract particular metadata items, in addition to the standard 
> metadata.
> 
> As far as if this would be interesting to have in GDAL itself, this is an open 
> question. I'm not very well versed in metadata standards, but my impression is 
> that there are many of them (ISO 19139, that seems to have had several 
> versions, and that can have custom profiles apparently, FGDC, ...), and we 
> probably wouldn't want to have to implement all of them in each driver.
> 
> (Annectodicaly GDAL is a consumer of ISO 19115 in the BAG driver, to extract 
> georeferencing.)
> 
> I'm also wondering to which extent it is possible to generate valid XML 
> metadata documents in an automated way, from the information found in the 
> dataset. I'm thinking particularly to mandatory metadata items whose content 
> couldn't be found in the dataset.
> 
> Even
> 
>> 
>> xav
>> 
>> 
>> 2013/10/19 Even Rouault <even.rouault at mines-paris.org>
>> 
>>> Hi,
>>> 
>>> This is a call for discussion for "RFC 43
>>> GDALMajorObject::GetMetadataDomainList()" :
>>> 
>>> http://trac.osgeo.org/gdal/wiki/rfc43_getmetadatadomainlist
>>> 
>>> Beginning of the RFC inline :
>>> """
>>> 
>>> == Summary ==
>>> 
>>> This (mini)RFC proposes a new virtual method, GetMetadataDomainList(), in
>>> the
>>> GDALMajorObject class (and a C API) to return the list of all available
>>> metadata domains.
>>> 
>>> == Background ==
>>> 
>>> GDALMajorObject currently offers the GetMetadata() and GetMetadataItem()
>>> methods that both accept a metadata domain argument. But there is no way
>>> to auto-discover which metadata domains are valid for a given
>>> GDALMajorObject (i.e. a dataset or raster band). This make it impossible
>>> to have generic code
>>> that can exhaustively discover all metadata in a dataset/raster band.
>>> 
>>> [...]
>>> 
>>> """
>>> 
>>> Best regards,
>>> 
>>> Even
>>> 
>>> --
>>> Geospatial professional services
>>> http://even.rouault.free.fr/services.html
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> -- 
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev