Hello everybody, Looking at Snowflake GoPublisher WFS that does not have these problems to deliver INSPIRE compliant WFS, there, the "workspace" is not linked to a single XSD schema.
For a reason that we cant understand, in Geoserver the name of the workspace is inherited from the name of the XSD file. For complex features this does not make sense, as a complex feature is based on multiple feature types, and therefore on multiple XSD files. For example, in order to provide access to ps:ProtectedSite feature type, in Geoserver, three workspaces need to be created, ps for ps.XSD, base for base.XSD and gn for gn.XSD. But in reality in order to provide access to a single complex featureType, ps:ProtectedSite, from the user perspective it should be only one workspace, considering that ps:ProtectedSite that is a dataset. Therefore from an INSPIRE data provider perspective that need to provide access to complex features, the Geoserver wokspace is not actually a workspace, but an XSD schema holder. From the INSPIRE data provider perspective the "workspace" is actually the Geoserver instance and the geoserver workspaces are just used for holding XSDs. While working with Snowflake GoPublisherWFS we found that the software do not have such an approach of workspaces. In a GoPublisherWFS instance can be loaded as many XSD files as necessary to provide access to a dataset. Even more there are no problems to provide access to a dataset that has more than one featureType. We can say that in GoPublisherWFS one instance = one workspace based on multiple XSD files. With GoPublisherWFS it is possible to provide access to a dataset that contains more than one featureType. We tried to do the same in Geoserver, but we found that this approach with workspaces based on a single XSD schema are generating issues that are not present in GoPublisherWFS. We tested in Geoserver 2.12-beta as this bug https://osgeo-org.atlassian.net/browse/GEOS-4773 was closed in this version. 1. For example a GetPropertyValue request to retrieve the geographical name of a protected site will return null namespace prefixes in the GML. Link to test nulls: http://inspire.teamnet.ro/geoserver/wfs?version=2.0.0&request=GetPropertyValue&typeName=ps:ProtectedSite&valueReference=ps:siteName/gn:GeographicalName/gn:spelling/gn:SpellingOfName&count=2 2. Another example is related to GetSpatialDataSet StoredQuerry that is providing null namespace prefixes while retrieving a dataset with multiple featureTypes. In practice a dataset contains more than one featureType from multiple data themes, all having the same metadata and having the geometries in topology and being produced at the same precision and having the same lineage. The request is providing a dataset with protected sites, administrative units, bio-geographical regions and their corresponding geographical names, but there are null namespaces. Link to test nulls: http://inspire.teamnet.ro/geoserver/wfs?request=GetFeature&StoredQueryID=http://inspire.ec.europa.eu/operation/download/GetSpatialDataSet&version=2.0.0&crs=epsg:3035&count=1 3. Even if we do not intend to use virtual services unless they will be linked to a dataset, a GetFeature request to a virtual service (in this case "ps") are returning null namespace prefixes in the retrieved GML. This means that virtual services cant be used as endpoints, in order to allow a single instance of Geoserver to be used with multiple endpoints in the case that a data provider has one featureType per dataset. Other software is able to create separate endpoints per each dataset even if the dataset has more than one featureType. Link to test nulls http://inspire.teamnet.ro/geoserver/ps/wfs?request=GetFeature&version=2.0.0&typeNames=ps:ProtectedSite&count=2 Therefore maybe the current workspaces in Geoserver should not be named workspaces in the context of complex features or the so called workspaces need to be redesigned. It looks like Geoserver should make a shift from flat data to many-to many related data, simillar to the shift from shp to gdb or from xls to mdb. >From an INSPIRE data provider perspective a workspace is tight to a dataset. A dataset can contain more than one complex feature type so a dataset is based on more than one XSD schema and more than one featureType. A dataset is similar to a "feature dataset" in ArcGIS that contains "feature classes" that are simmilar to featureTypes. 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 thy are not acttualy 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 and 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 used for WMS. The link between WMS and WFS features is ensured trough short URL, such as http://inspire.teamnet.ro/ENV/PADS/psPS/RONPA0022 Best regards, Iurie Maxim Teamnet, Romania -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-tp5307302p5318092.html Sent from the GeoServer - Dev 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
