Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Le dimanche 20 octobre 2013 18:21:23, Frank Warmerdam a écrit : Even, I'm happy with this RFC. It's a bit sad that the list of domains is duplicated and has to be freed again by the caller, but it certainly avoids any doubts about the lifetime of the returned list. Hi Frank, Indeed, for the default implementation it would have been doable to return oMDMD.GetDomainList() directly, but for specialized implementations this wasn't possible and would oblige them to have a member variable to hold the return value. So returning a list to free with CSLDestroy() seemed to be a simpler approach. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
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.roua...@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.roua...@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@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Kurt, I have been trying to think through how an OGR driver for ISO19115 / 19139 would work. Do you mean a driver that would read (and/or write) ISO 19139 XML files ? Do such documents fit (enough) well with the OGR data model ? Is there a concept of record/feature ? I'm unfortunately not familiar with what those documents look like. 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. Not sure to understand your need about BAG. There is already a xml:BAG metadata domain into which the ISO19115 stuff is dumped. So your need would be an API to parse the XML ? There are perhaps good ideas in the various projects that revolve around CSW. 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. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Does that include the upcoming ISO19115-1 ? Doug On Wed, Oct 23, 2013 at 10:29 AM, Even Rouault even.roua...@mines-paris.org wrote: Kurt, I have been trying to think through how an OGR driver for ISO19115 / 19139 would work. Do you mean a driver that would read (and/or write) ISO 19139 XML files ? Do such documents fit (enough) well with the OGR data model ? Is there a concept of record/feature ? I'm unfortunately not familiar with what those documents look like. 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. Not sure to understand your need about BAG. There is already a xml:BAG metadata domain into which the ISO19115 stuff is dumped. So your need would be an API to parse the XML ? There are perhaps good ideas in the various projects that revolve around CSW. 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. Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
The reader in the BAG directory is a bare minimum implementation. Out side of BAGs there is definitely a need. Pardon my ignorance, but what is CSW? OGC CSW (Catalog Service Webservice) : http://www.opengeospatial.org/standards/cat And there are a few OSGeo related projects around this : - http://pycsw.org/ - http://geopython.github.io/OWSLib/ - ... ? -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Hi Is there a way to export Metadata in a XML form (ISO 19139 XML implementation of ISO 19115 ) ? xav 2013/10/19 Even Rouault even.roua...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
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.roua...@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@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Even, I'm happy with this RFC. It's a bit sad that the list of domains is duplicated and has to be freed again by the caller, but it certainly avoids any doubts about the lifetime of the returned list. I have an internal driver here at Planet Labs where I tree any subnode in our JSON metadata format as a GDAL metadata domain. It will be interested to write an implementation of GetMetadataDomainList() for that. Best regards, Frank On Sat, Oct 19, 2013 at 11:59 AM, Even Rouault even.roua...@mines-paris.org wrote: 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
