Hi Elena, thank you for sharing this, while reading your mail, I get the
impression this is more a geonetwork issue then a geoserver issue. In scenario
1 a service metadata (iso19119) document is introduced that contains
information that can not be stored in a capabilities document, the capabilities
document references this service metadata record. Geoserver implements this
scenario.
In scenario 2 there is no service metadata required, but all metadata
properties are stored inside the capabilities response, geoserver currently
doesn’t support scenario 2.
In your mail you mention you have a geonetwork harvester that harvests an
iso19119 document from the get capabilities document. This harvester will
however not provide you with a fully compliant inspire iso19119 document, since
the required information is not available in the get capabilities response,
however the harvested document could be an interesting starting point to
complete it into a complient document. Adding those elements to geoserver is
only relevant in scenario 2, since the geonetwork harvester will (initially)
not be able to pick them up.
Another option I see (which i think is very useful) is to set some default
values in the geonetwork-xslt that transforms the capabilities document thus
resulting in a compliant inspire iso19119 document. The xslt involved is here:
https://github.com/geonetwork/core-geonetwork/blob/develop/schemas/iso19139/src/main/plugin/iso19139/convert/OGCWxSGetCapabilitiesto19119/OGCWxSGetCapabilities-to-19119.xsl
<https://github.com/geonetwork/core-geonetwork/blob/develop/schemas/iso19139/src/main/plugin/iso19139/convert/OGCWxSGetCapabilitiesto19119/OGCWxSGetCapabilities-to-19119.xsl>
What i usually do is to create an iso19119 document from the standard inspire
template and then use the suggest service to parse the capabilities information
to add the layer references automatically.
Geoserver these days also has a CSW service, maybe it’s an option to let that
expose the requested iso19119 document (there is a settings file, allowing you
to add additional properties to the output of that file)
> On 30 May 2017, at 08:43, elenagrigoriou <[email protected]> wrote:
>
> Dear all,
>
> I am trying to set up an INSPIRE compliant view service using Geoserver and
> Geonetwork. I mostly follow the instructions given here
> <http://geonetwork-opensource.org/manuals/3.0.5/eng/users/tutorials/inspire/view-geoserver.html>
>
> , along with the guidelines provided in the context of INSPIRE implementing
> rules.
>
> Geoserver implements scenario 1 of the INSPIRE technical guidance. If I
> understand well, that means that some of the view service metadata are
> mapped to the wms elements of the capabilities response, which is extended
> in order to include more elements that INSPIRE requires, such as
> MetadataUrl, supported and response language.
>
> I am testing my implementation with the JRC INSPIRE validator
> <http://inspire-geoportal.ec.europa.eu/validator2/> . The validator does
> not find the metadata elements that are not included in the capabilities
> response.
> I think that this is expected, since, according to the instructions I
> followed, the metadata file to which the element <MetadataUrl> is pointing,
> was created by harvesting the capabilities response of the wms (using
> Geonetwork’s harvester). So, the metadata elements required by INSPIRE are
> not included.
>
> So, my question is, where do I fill out the metadata elements INSPIRE
> requires? If needed, how can I change the Geoserver wms capabilities
> response, so that it will include more metadata (conformity, temporal
> reference etc).
>
> Has anyone used Geoserver/Geonetwork, following the aforementioned
> instructions, and succeeded a 100% INSPIRE compliance?
>
> I would be very interested to hearing your experience.
>
> Thank you in advance.
>
> Elena
>
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/Set-up-an-INSPIRE-compliant-view-network-service-using-Geoserver-and-Geonetwork-tp5322233.html
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
