|
We tested quite a lot the Geoserver 2.13.0 to understand how the new isolated workspaces can be used for implementing INSPIRE and we came to certain conclusions.
I. A GetFeature Request assumes that both the namespace *(actually the XML namespace = *prefix) and the featureType is provided: “request=GetFeature&typeNames=namespace:featureType”
The namespace used in the GetFeatureRequest is the XML namespace.
For example:
If namespace URI= “target schema”= https://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd, for the ”ProtectedSite” featureType the XML namespace (prefix) is ”ps” as declared in the schema xmlns:ps=“http://inspire.ec.europa.eu/schemas/ps/4.0”.
So there is a namespace URI and an XML namespace.
Currently Geoserver is using the name of the workspace *as *prefix (XML namespace), so the GetFeature request works only if the typeNames=workspace:featureType and this is misleading and also not correct according to INSPIRE
As we created a __workspace named “CDDA” and in the “__namespace URI*” we provided the “URI of the target schema” = https://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd. In order to retrieve the features, the GetFeature request will contain “typeNames=*CDDA:ProtectedSite”.
However the request should contain “typeNames=ps:ProtectedSite” as the ”XML namespace” = ”prefix of the featureType” should be ”ps” according to INSPIRE.
Our understanding was that the isolated workspaces were created in order “to be able to publish the same feature type (name space + name) multiple times”. However, namespace should refer to both namespace URI and XML namespace (prefix), while currently it refers only to namespace URI.
In the app-schema there are both the prefix (XML namespace) and the uri (namespace URI) used for mapping as can be seen bellow.
<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>
<ns3:AppSchemaDataAccess xmlns:ns2=“http://www.opengis.net/ogc” xmlns:ns3=“http://www.geotools.org/app-schema”>
<namespaces>
<Namespace>
<prefix>ps</prefix>
<uri>http://inspire.ec.europa.eu/schemas/ps/4.0</uri>
</Namespace>
Therefore, as currently implemented, isolated workspaces should be used in conjunction with virtual services in order to be able to publish the same featureType ”ps:ProtectedSite” multiple times. With current implementation it seems that we can publish the the ProtectedSite featureType but with different *prefixes *that are now inherited from the “workspace name”. So we can publish at the “ps” virtual service endpoint the “ps.ProtectedSite” featureType and at the ”CDDA” virtual service endpoint we can publish ”CDDA:ProtectedSite” even if we need to serve ”ps:ProtectedSite” trough both virtual service endpoints.
We see that there is a problem that the workspace name that is used for virtual services is inherited as well by the namespace of the featureType (prefix (XML namespace)) and this is not usable for INSPIRE.
Therefore, we are proposing to change the workspace UI and the functionalities behind.
Now the workspace UI has two elements:
”name” that is storing the “name of the workspace”
“namespace URI” that is storing the “URI of the target schema”
In the UI should be added as well the
”XML namespace (prefix of the featureType)” in order to store the namespace of the featureType that is used in the GetFeature request, namely the prefix of the featureType.
As an example:
”workspace name” = ”CDDA”
”namespace URI” = https://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd
”XML namespace” = ”ps” (see https://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd where xmlns:ps=“http://inspire.ec.europa.eu/schemas/ps/4.0”)
The ”XML namespace” should not be taken anymore from ”workspace name” as currently implemented and In this case we would be able to request the ”ps:ProtectedSite” at the ”CDDA” virtual service endpoint.
With this approach, a data provider will be able to serve different ”ps:ProtectedSite” at different endpoints. Each endpoint will be linked to a dataset containing feature types that are based on a single XSD schema.
II. To complicate the things a little bit, if we would like to take into consideration that a dataset can be formed by multiple featureTypes from different XSD schemas, than each endpoint should be linked to a dataset containing feature types that are coming from more than one XSD schema.
In a such example in a
”workspace name” = ”CDDA”
”namespace URI(s)” = https://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd, https://inspire.ec.europa.eu/schemas/gn/4.0/GeographicalNames.xsd
”XML namespace(s)” = ”ps”, ”gn”
workspace CDDA endpoint should allow direct access at both ps:ProtectedSites and gn:GeographicalNames featureTypes.
III. Not sure if Geoserver was built in such way to allow INSPIRE implementation, but currently it seems that Geoserver has the following limitations in relation with INSPIRE:
- In a Geoserver instance it is not possible to serve more than once the same featureType, including its prefix (XML namespace), even if using isolated workspaces and virtual services endpoints. In other words it is possible to serve a feature type only by using different prefix (i.e.: ps.ProtectedSite and ps1.ProtectedSite). The prefix is inherited from the name of the workspace. This breaks several INSPIRE requirements and the only solution is to install separate instance of Geoserver for each feature type that need to be published several times.
- In a Geoserver instance is not possible to serve more than one dataset if that dataset is based on more than one XSD schema and more featureTypes need to be served at a certain endpoint. In other words it is possible to serve a dataset composed by ps:ProtectedSites features and their corresponding gn:GeosgraphicalNames features at a certain endpoint, but it is not possible in the same instance to serve as well at another endpoint a dataset composed of au:AdministrativeUnits and their corresponding gn:GeograpficalNames features.
- It is not yet WFS 2.0.0 nor WMS 1.3 compliant and is not passing the CITE OGC Validations (strangely it fails even the GetFeatureById WFS request with app-schema
 GEOS-6233 Open ).
Hope it helps,
Iurie Maxim
http://essensys.ro
|
