Hi all, this is not yet a proposal for GeoNetwork but we're currently
working on adding harvesting GetCapabilities document from WMS/WFS
service and will be glad to get comments/inputs on that topic. It will
harvest capabilities from service supporting WMS, WFS or WCS spec.
A mapping from the GetCapabilities document is defined to produce :
- one metadata for the service (using ISO19119)
- n metadata for all layers/FeatureType/Coverage available in that
service (ISO19139)
It will use the same mechanism as the harvesting for other sources (ie.
CSW, OAI, WebDav ...).
On the R&D section of the trac you could access to a draft document
http://trac.osgeo.org/geonetwork/wiki/ISO19119impl presenting :
- use cases
- GUI
- mapping
This development is made in the context of GeoSciML & OneGeology
projects with BRGM.
Comments & inputs welcomed.
Ciao. Francois
Francois-Xavier Prunayre wrote:
Hi all, this is not yet a proposal for GeoNetwork but we're currently
working on adding harvesting GetCapabilities document from WMS/WFS
service and will be glad to get comments/inputs on that topic. It will
harvest capabilities from service supporting WMS, WFS or WCS spec.
A mapping from the GetCapabilities document is defined to produce :
- one metadata for the service (using ISO19119)
- n metadata for all layers/FeatureType/Coverage available in that
service (ISO19139)
It will use the same mechanism as the harvesting for other sources (ie.
CSW, OAI, WebDav ...).
On the R&D section of the trac you could access to a draft document
ISO19119impl – GeoNetwork opensource Developer website presenting :
- use cases
- GUI
- mapping
This development is made in the context of GeoSciML & OneGeology
projects with BRGM.
Comments & inputs welcomed.
Ciao. Francois
Hi Francois,
Looks good! We've also been working on this but you're further down the track than us in setting up the harvester - I have a few questions:
1. How are we going to deal with the difference between the capabilities statements (vendors and OGC versions)? I'm looking at deegree's 1.3.0 wms capabilities for example (as its our use case) and its a bit different to the mapping you've defined (its one that we're working on a mapping for now). I thought we could use or pinch some of this from OGC client toolkits like GeoTools which seem to deal quite nicely with different vendors/OGC versions?
2. I think we've done the same as you for integrating 19119 into GN - but just to check - 19139 has a MD_ServiceIdentification element which doesn't display as a choice in GN 2.1 but does under the modified schema parsing code I've worked on (it says see 19119 for more detail) which seems to indicate to me that the best way to integrate 19119 and 19139 is to make SV_ServiceIdentification a member of the substitution group for MD_AbstractIdentification - 19119 doesn't appear as a separate schema then its just part of 19139. If you're building a metadata record with service metadata you use (or choose) srv:SV_ServiceIdentification in place of gmd:MD_DataIdentification. You don't need a separate tab in the editor then either - everything appears under 'Identification'.
3. Is there more that can be done with the Operations metadata mapping? I thought we could map parameters including layer names etc as part of this section but I haven't worked it out completely yet.
Cheers,
Simon