Unique Endpoint per Dataset

[nmco]

Description The closest solution provided by GeoServer are the namespace specific endpoints. While the namespace specific endpoints provide the correct capabilities, when providing complex features, there’s a problem with the namespace encoding (formally its nicer if all namespaces are declared in the header and then used, in the namespace specific encoding of complex features each namespace is defined where used; the namespaces are all set to null). Also, multiple datasets may be provided by an organization using the same INSPIRE Theme, thus namespace.

Workaround Set up simple features and define filters on these for the id, then request the correct feature by id

Sub Issues parent of #2 parent of #3 parent of #4 parent of #5 parent of #6

Required By required by #11 required by #13 required by #15 required by #22

[nmco]

"Ilkka Rinne 16.3.2017:This should be solved by the proposed ""isolated workspaces"" feature currently in discussion between Finnish Environment Institute and a contractor.This would introduce Isolated workspaces not tied to a single namespace, and make it possible to provide data using same feature types in more than one of these isolated workspaces (more than one data source mapping for a feature type). A known limitation will be that feature type lookup for chained features is not isolated to a workspace: there could now be more than one mapping for a feature type, so the current data store is searched first, and then all others (globally). First match will be used.

[nmco]

Iurie Maxim 21/4/2017: This discussion held two months ago: http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html shows that isolated workspaces is just a concept not implemented, that touches some fundamentals of Geoserver. It has as well some other issues. My understanding is that currently is just a proposed development that was not done and tested in order to see if this is a solution or not and what are the limitations. If it will be done, than it should be understood that a workspace need to have a one-to-one relationship with a dataset, because according to INSPIRE each dataset should have a unique endoint. It should be understood as wel that a dataset is composed of one or more complex featue types, and each complex feature type is defined trough multiple XSD schemas. Therefore one-to-many relationships should exist between a dataset and complex feature types and one-to-many relationships should exist between a complex feature type and XSD schemas."

[nmco]

Linking this to the GeoServer JIRA ticket: https://osgeo-org.atlassian.net/browse/GEOS-8734

At this point three known issues remain on GeoServer:

• App-Schema defined feature types need always to be referenced by their full qualified name (workspace_prefix:feature_type_name) even in the context of a particular workspace virtual service.

• When publishing an App-Schema defined feature type the layer name needs to be equal to the feature type mappings root target element. Removing this limitation will, for example, allow users to prefix the layer name with INSPIRE mandated prefix.

• App-Schema requires that the same prefix used in the feature type mappings needs to be used for filtering even if the use prefix is tied to the correct namespace. If two different prefix point to the same namespace, XML elements prefixed with those prefix must be considered the same.

GeoSolutions is now working on fixing this issues.