[Geoserver-users] Set up an INSPIRE compliant view network service using Geoserver and Geonetwork

[elenagrigoriou]

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.

[Verbeeck Bart]

Elena

We implemented a simple solution.

For the getcapabilities request we implemented a URL-rewrite to an xml file so we have 100% control over the getcapabilities output.

Ie http://geoservices.informatievlaanderen.be/raadpleegdiensten/GRB/wms?request=getcapabilities&service=wms

Cheers

Bart

-----Original Message-----
From: elenagrigoriou [mailto:***@gmail.com]
Sent: dinsdag 30 mei 2017 8:43
To: geoserver-***@lists.sourceforge.net
Subject: [Geoserver-users] Set up an INSPIRE compliant view network service using Geoserver and Geonetwork

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

[Andrea Aime]

Hi,
I see you are pointing back to external files for metadata access so...
what is it that your url rewrite filter is adding,
that the GeoServer INSPIRE extension does not do? I see what looks like a
larger INSPIRE section at the top.
If anything mandatory is missing I'd open a ticket about it.

Cheers
Andrea


On Fri, Jun 2, 2017 at 2:01 PM, Verbeeck Bart <

Post by Verbeeck Bart
Elena
We implemented a simple solution.
For the getcapabilities request we implemented a URL-rewrite to an xml
file so we have 100% control over the getcapabilities output.
Ie http://geoservices.informatievlaanderen.be/raadpleegdiensten/GRB/wms?
request=getcapabilities&service=wms
Cheers
Bart
-----Original Message-----
Sent: dinsdag 30 mei 2017 8:43
Subject: [Geoserver-users] Set up an INSPIRE compliant view network
service using Geoserver and Geonetwork
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
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
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo Ú consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

[Paul van Genuchten]

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)

Post by elenagrigoriou
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
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[elenagrigoriou]

Thank you all very much for the replies.

I finally found out that the jrc validator is checking 2 things, the view
service capabilities response and the metadata file, which location is found
in the inspire extended capabilities geoserver provides.

So I just created an inspire compliant services metadata file with the
inspire editor (instead of creating it with a harvester) and I imported it
in geonetwork (which actually cannot validate it neither can I view it in
inspire view but anyway...).

This solution is giving me 100% compliance with inspire. The problem is that
every time I add a layer in geoserver I have to manually add the MetadataURL
(coupled resource metadata element) in the service metadata file but that is
a minor task :-)









--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Set-up-an-INSPIRE-compliant-view-network-service-using-Geoserver-and-Geonetwork-tp5322233p5323150.html
Sent from the GeoServer - User mailing list archive at Nabble.com.