|
|
Iurie Maxim created an issue |
|
Several WFS requests on complex features are returning null namespace prefixes |
|
Issue Type: |
|
|---|---|
|
Assignee: |
Unassigned |
|
Created: |
23/Apr/17 3:24 PM |
|
Environment: |
Windows server. |
|
Priority: |
|
|
Reporter: |
|
Tested on 2.12-beta because this issue https://osgeo-org.atlassian.net/browse/GEOS-4773 appear to be solved in this version, but null namespace prefixes are still present in virtual services for complex features and on some other WFS requests. Probably all or some of the issues described below are related to the fact that Geoserver creates so called “workspaces” that are in a one-to-one relationship with a XSD schema and therefore nor a complex features and nor a dataset composed of more complex features are not managed in a single workspace.
In order to implement INSPIRE, a protected site complex feature type is based on three XSD schemas, namely ps.XSD (protected site), base.XSD (it includes the inspireId) and gn.XSD (geographical name), therefore three workspaces are created from one complex feature type: ps, base and gn. If a user wants to retrieve the inspireIds or the geographical names of all or some protected sites, unfortunately the GetPropertyValue request returns null namespace prefixes. Links to test nulls: To be noted that a GetPropertyValue request does not return null namespace prefixes for the first nested element: but it returns null namespace prefixes for the second, third, … nested element: However, a GetFeature request is not providing null namespace prefixes for that complex feature Other software is not returning null namespace prefixes in GetPropertyValue requests, therefore there is not a WFS request issue.
In practice a dataset contains more than one featureType from multiple INSPIRE data themes, all having the same metadata and having the geometries in topology, being produced at the same precision and having the same lineage. In this example the dataset contains protected sites (ps), administrative units (au), bio-geographical regions (br) and their corresponding geographical names (gn), for all these being created five so called workspaces: ps, au, br, gn and base. A GetFeature request in order to retrieve this dataset trough a Stored Querry is returning null namespaces. Link to test nulls: Other software is not returning null namespace prefixes, therefore there is not an WFS request issue.
Link to test nulls: Other software is able to create separate endpoints per each dataset even if the dataset has more than one complex featureType. General considerations: INSPIRE requires data providers to have unique endpoints for each dataset. Therefore in INSPIRE one datset = one endpoint. Currently the unique solution in Geoserver to provide multiple endpoints is the use of virtual services. In Geoserver virtual services endpoint names are inheriting the names of the workspaces which unfortunately are inheriting the name of the XSD schema. Because a complex feature is based on multiple XSD schemas (all INSPIRE complex features are based on base.XSD schema as well) in order to serve an INSPIRE complex feature in Geoserver there will be at least two workspaces, one named base and another named similar to the data theme (ex: ps for protected sites) Most complex features have geographical names, and gn.XSD is used in those complex feature types. In this case a data provider can, and therefore he should provide access at two complex features, one beeing gn:GeographicalName and the other of the data theme (i.e.: ps:ProtectedSite). In this case already the dataset is composed of two feature types (i.e: ps and gn) and it is based on three XSD files (including base). Therefore, for complex features, the so called workspaces in Geoserver are not workspaces as those entities can be considered only as XSD holders. For complex features a workspace should be based on multiple XSD schemas, therefore a one-to-many relationship should exist between a workspace and the XSDs and not a one-to-one relationship as it is now. As INSPIRE requires a unique endpoint per dataset, so, from an INSPIRE data provider point of view the workspace that is used for creating virtual services should store the dataset. Each such new workspace should have a one-to-many relationship with al XSD schemas used by those featureTypes that are part of the dataset. The endpoint used for the virtual service should provide access to one, many and altogether featureTypes that are part of the dataset. From an INSPIRE data provider perspective a workspace is tight to a dataset. A dataset can contain more than one complex feature type, therefore a dataset is based on more than one XSD schema and more than one complex featureType. A dataset is similar to a “feature dataset” in ArcGIS that contains “feature classes” that are similar to featureTypes (each featureType can be represented in different styles based on a SLD, for each style being created a WMS “layer”). If a single instance of Geoserver would be able to provide access to a single dataset, than workspaces do not make sense from INSPIRE perspective as they are not actually workspaces for complex features. If a single instance of Geoserver would be able to provide access to more datasets, then one workspace may be linked to the one dataset based on multiple featureTypes and therefore on multiple XSD schemas. As INSPIRE requires datasets to be accessible at a unique endpoint, virtual services for such workspaces make sense. We came as well to the conclusion that with the current Geoserver configuration WFS and WMS should be accessible from different endpoints (probably even from different Geoserver instances), but this is another subject, maybe to be further discussed and it is linked to poor performance of rendering images based on complex features, so flat simple features are more suitable for WMS. The link between WMS and WFS features is ensured trough short URL, such as for example http://inspire.teamnet.ro/ENV/PADS/psPS/RONPA0022 Iurie |
|
|
|
This message was sent by Atlassian JIRA (v1000.910.0#100040-sha1:0b083fc) |
|
|