|ID||Problem||Description||Workaround||INSPIRE Themes impacted||Version||Date Reported||Reported by||In the process of negotiating funding||Comments||OSGeo Issue Link|
|1||Unique Endpoint per Dataset||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.||Utilize Apache's rewriting functionality. For getCapabilities the namespace specific URI should be used, for getFeature the request URI should be rewritten with the namespace excluded.||2.9||1/31/2017||Kathi Schleidt||Finnish Environment Institute||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.|
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.
|2||Stored Queries||(Some filtering of the data trough) Stored queries are not possible on complex features.|
Correction: It is possible, but the query XPath is different than for simple features - when defining stored queries for complex features, the entire XPath including the base feature name must be provided (Kathi).
Correction2: relativ path also works, if you start with ./ (Kathi)
|Set up simple features and define filters on these for the id, then request the correct feature by id||2.9||1/31/2017||Kathi Schleidt||Ilkka Rinne 16.3.2017: Not true, the getSpatialDataSet stored query is working in FEI:s Geoserver 2.9.0: see http://geoserver.ymparisto.fi/geoserver/wfs?service=WFS&version=2.0.0&request=getfeature&storedqueryid=http://inspire.ec.europa.eu/operation/download/getspatialdataset/&DataSetIdCode=http://paikkatiedot.fi/so/1002201/ps/ProtectedSite/&count=1|
Iurie Maxim 21/4/2017: Kathi is not talking only about getspatialdataset stored querry, but is talking about filtering the data trough stored querries. This may be in relation with issue 14. I think that Kathi points to the fact that she had a problem to retrieve a feature by inspireId, thus by providing either two or three parameters: namespace, localId, versionId). We will test to better undertand which is the problem. Indeed is not too clear what Kathi wants to indicate, but I supose that is something related to the problem of the features that have versions, therefore is not the case of protected sites that have no versions. The example provided by Ilkka works only for one dataset with only one featureType per geoserver instance. Ilkka, first time try to provide two datasets, each one with only one FeatureType (i.e.: ps:ProtectedSite and gn:NamePlace with the names of Protected Sites) and create a stored query request to retrieve Protected sites and another request to retrieve the geographical names of the protected sites by using the same storedqueryid. Second time try to provide a dataset that is providing access to both featureTypes, namely ps and gn and create a stored querry to download that dataset containing both featuretypes without having nulls in the namespaces. Then you will see that Kathi has a point even if it is not described in detail. Another problem can be related to the fact that only CRS is a OCG parameter for stored querries, while DataSetIdCode, DataSetIdNameSpace and Language are not and are not understood by a GetFeature WFS 2.0.2 request. Conclusion: Would be good if Kathi will provide more details for us to understand.
|3||WMS doesn't work on some geometry types|
|GeoServer cannot provide a WMS from certain complex feature types due to the geometry used|
Also, seems to crash TomCat when doing GetFeatureInfo but needs to be checked
|Set up simple features and create a WMS for these; may need some rewriting, not sure||SU, LU||2.9||1/31/2017||Kathi Schleidt||Iurie Maxim 21/4/2017: WMS is actualy rendering images very slow based on complex features. so for usability the recommandation is to use always simple features. We used rewriting to produce short URLs for retrieving each feature so they can be used within the WMS to link with WFS (http://inspire.biodiversity.ro/ENV/PADS/psPS/RONPA0022). The problem indicated by Kathi is not a Geoserver problem is a complex feature problem. All existing software have same problem of slow rendering if the features are complex and all have issues with one-to-many relationships. This should not be indicated as Geoserver issue. Actualy I would mention that GML is the real problem and the fact that the geometry in the GML is a text. Compared to a personal geodatabase ir to a shapefile storing the same information a GML is at least 100 times larger (in MB). GML is simmilar to an Oracle or SQL Dump, is a format for data exchange, not for data use. For usability purposes at leaset a compressed GML file similar with KMZ should be developed.|
|4||WFS-T doesn't work with complex features||all||all||Kathi Schleidt||Iurie Maxim 24/4/2017: Most probably the issue is not related to Geoserver but is related to complex features and/or transformers (such as app-schema or FME). Complex features are handled in Geoserver trough app-schema. App-schema was not designed for data editing, but only for data reading and transormation. Depending on the database structure, in most cases if data is transformed, it cant be edited (ex: if two fields are concatenated into one then it is not possible to edit one field in order to edit two fields). This is the reason why it is not possible to edit trough app-schema. On the other hand for complex features, as they are based on multiple features, it means than in a corectly designed database the data of a complex feature is stored in more than one table and usually has one-to-many or even many-to-many relationships. Therefore for complex features, in order to edit the data, in most cases the data need to be edited in more than one table (tables are linked trough primary and foreign keys that are not exposed in the GML of the complex feature). For better understanding the editing of complex features it should be understood that it is simmilar to the SQL views or simple Microsoft Access Querries that are not allowing to edit the data if the data is transformed or if it is coming from more than one table. Therefore editing must be made directly in the tables trough specific mechanisms that knows how the data is stored in the database and what triggers need to be made in order to insert, edit or delete a record. A general issue is related to the fact that in INSPIRE it is not imposed a certain database structure and will never be imposed such a fixed structure (as for example ESRI is providing in ArcGIS for INSPIRE extension), simply because each data provider has different data and the INSPIRE model tries to accomodate most of these data models trough a single data model.|
|5||Requests for multiple complex features crashes Geoserver||While getFeature works for multiple features (featureId=F1, F2), it will only do this a few times. Then no complex features are returned. Strange is that simple features and WMS continue to work||request features individually||all||all||Kathi Schleidt||Iurie Maxim 21/4/2017: Try to crash our Geoserver please with this approach. Most probably the solution is how much memory is provided to Java.|
|6||It is not possible to create two or more endpoints for an XSD schema.||For an XSD schema GeoServer is creating by default a workspace, that can be used as an endpoint to be used to request that dataset through WFS or WMS. The problem is that the workspace and the endpoint are inheriting the name of the schema. Therefore with GeoServer it is currently possible to create only one workspace and one endpoint for one XSD schema. This means that if a data provider has more than one datasets that are refering the same XSD schema, then that provider cant use the GeoServer solution, unless he is installing GeoServer on multiple servers with different web addresses (endpoints). As in reality most data providers have more than one dataset (with different metadata) for a XSD schema, they cant use GeoServer. An example is a data provider that has geology for the entire country at 1:200.000 scale and some areas covedered with more details, at 1:50.000 scale.||Installing Geoserver several times on the same server or on multiple servers. If a data provider has for example five datasets for an XSD schema he will need to have 5 Geoserver instances. More likely nobody will do this in a production environment.||all||all||2/18/2017||Sorin Rusu||Ilkka Rinne: See my comment in "Unique Endpoint per Dataset"|
Iurie Maxim 21/4/2017: Not sure if the "isolated workspaces" even if will be developed in the next months will solve the problem. The solution proposed must be tested for example by providing with the same Geoserver intance two datasets for the same featureType (i.e.: dataset 1 - geology scale 1:200.000 at national level, dataset 2 = geology of one area at 1:50.000 scale with more details/attributes) with different metadata pointing to different endpoints. Each dataset must be accesible as well trough a strored querry having the same Id, but accessed at different endpoints. Therefore stored querries must not be available at geoserver level, but at workspace level.
|7||It is not posible to retrieve and test the dataset provided via WFS in the EC Geoportal if a data provider has to provide more than one dataset via Geoserver||The Recommandation 13 of the Tehnical Guidelines for Inspire Download Services states: ”The following identifier should be used to identify the Stored Query for serving pre-defined Spatial Data Sets: http://inspire.ec.europa.eu/operation/download/GetSpatialDataSet”. A machine is able to get the entire dataset if the machine knows the name of the stored querry that is providing the entire dataset. Thats why even the EC Geoportal is using the name of the stored querry defined in reccomandation 13 in order to retrieve the dataset in order to test that the WFS is responding. Without fullfiling the recomandation 13 a machine is not able to test a dataset provided via WFS. Therefore the recomandation 13 is actaulay a requirement. The problem is that Geoserver is not able to store two or more stored querries with the same identifier. Therefore if the Geoserver is providing access to more than one datsets, then in order to retrieve those datasets via stored querries, the only solution is to have different identifiers for those stored querries, but this is not in accordance with the reccomandation 13 and even more the EC Geoportal will provide an error as it will not be able to test that WFS without knowing how to retieve the dataset trough a stored querry.||The data provider has to instal Geoserver for each dataset. If a data provider has 10 datsets than he will need to install 10 instances of Geoserver on multiple servers with 10 different endpoints.||all||all||2/18/2017||Sorin Rusu||Ilkka Rinne 16.3.2017: not true,see my comment for "Stored Queries".|
Iurie Maxim 21.04.2017: According to GetCapabilities document http://geoserver.ymparisto.fi/geoserver/wfs?service=WFS&version=2.0.0&request=getcapabilities the geoserver indicated by ilkka is providing access to a single dataset containing a single feature type. Therefore the comment is not relevant. We agree that there is no prioblem to serve only one dataset with only one feature type through a single instance of Geoserver. The problems are starting when a data provider need to provide access to more than one dataset and more than one feature type. Ilkaa, you should try to serve as well the geographical names of protected sites on the same Geoserver instance and why not even in the same dataset (as for sure the metadata are exactly the same because the named places are embeded in the protected sites)
|8||It is not possible to use more than one endpoint per Geoserver instance||There is a known bug (https://osgeo-org.atlassian.net/browse/GEOS-4773) that is not solved for more than five years already as Geoserver is creating null prefixes for complex features in virtual services that are used to create multiple endpoints. If a data provider has more than one dataset to be provided via WFS in Geoserver than for each dataset he will need an endpoint (according to Requirement 52 of the Tehnical Guidelines for Inspire Download Services) That endpoint is used as well in the metadata in order for indicate the internet address where it is possible to access that dataset via WFS (actualy the GetCapabilities document). Geoserver is using so called virtual services in order to create multiple endpoints. Unfortunately for complex features (that are in GML 3.2) a WFS request to such an endpoint is providing a GML 3.2 file with null values for prefixes, that makes the GML files unusable. Solving this bug will be the first step that will allow a data provider to serve via WFS one dataset for each XSD schema. If the bug will be fixed the data provider will not be able to serve two or more datasets for the same XSD schema and the data provider will not be able to create stored querries with the same identifier for each dataset, unless the previous two issues will be solved as well.||The data provider has to instal Geoserver for each dataset. If a data provider has 10 datsets than he will need to install 10 instances of Geoserver, most probably on multiple servers.||all||all||2/18/2017||Sorin Rusu||National Land Survey of Finland|
|9||querring multiple type names in Stored querries fails||Known bug from 2012 https://osgeo-org.atlassian.net/browse/GEOS-5512||Iurie Maxim: it works if in the querry are made separate requests for each typeName instead of one request for all typeNames. Most probably this approach has an issue as in this case typenames cant be provided as a parameter of the WFS request.||all||all||2/18/2017||Sorin Rusu||Iurie Maxim 21/4/2017: We solved this issue for downloading a dataset containing multiple type names, but the result has null values for namespaces. See problem 15.|
|10||It is not possible to provide access via WFS to more than one dataset based on multiple INSPIRE data themes (XSD files)||It is common that data providivers are managing spatial databases that are based on multiple INSPIRE data themes, as for example a topographical map containing roads, rivers, lakes, inhabited places, geogrpahical names, administrative units etc. Having common metadata, all these "layers" are part of the same dataset. Becauase Geoserver is creating one workspace and one virtual service (endpoint) for each XSD schema, in order to access this dataset virtual services cant be used.Therefore by using Geoserver it is not possible to provide access via WFS to more than one dataser based on multiple INSPIRE data themes. If a data provider would need to provide access to two such datasets, then the only solution is to install the second instance of geoserver.||The data provider has to instal Geoserver for each dataset. If a data provider has 10 datsets than he will need to install 10 instances of Geoserver on multiple servers with 10 different endpoints.||all||all untill the last 2.12-beta||2/18/2017||Iurie Maxim||Ilkka Rinne 16.3.2017: See my comment in "Unique Endpoint per Dataset".|
|11||FeatureTypes/layers always published in all service types||Due to performance reasons it makes sense to publish the WMS layers and WFS featureTypes for the same INSPIRE feature types using different data sources: It should be possible to publish the complex feature data for the INSPIRE data via a WFS endpoint using AppSchema data source, and a WMS layer corresponding to the same feature type using a direct PostGIS data source, or even a shapefile. Currently each layer is automatically visible both as a WFS feature type and a WMS layer, so this is not possible.||The data provider has to use different Geoserver instances for WMS and WFS to map their data source differently.||all||all||3/16/2017||Ilkka Rinne||Ilkka Rinne 16.3.2017: The proposed "Isolated workspaces" feature would provide a workaround. Data providers could create separate workspaces with only WMS enabled in one and only WFS enabled in the other, with different data source configurations for the identically named layers.|
Iurie Maxim 24.04.2017: This isolated workspaces seems actualy to be multiple Geoserver instances. Actualy Geoserver is installed several times on the same machine (the war file is uncompressed in the Tomcat twice, once for WMS and once for WFS. For 10 datasets a data provider will have 20 Geoserver Instances that will consume a significant amount of RAM that will need to be provided to Java. We already performed some tests. Implementations are not possible without specialised people or step by step guidelines.
|12||SLD rules based on complex feature attributes fails||GetMap requests for complex features from AppSchema store layers fails when the layer is using a SLD style containing filter expressions based on attribute names. Error message: "The requested Style can not be used with this layer. The style specifies an attribute of geometry and the layer is: ps:ProtectedSite".||Use SLDs without references to feature attribute values. This makes SLD use very difficult when the features contain varying geometry types.||all||2.9.0 - 2.10.2||3/17/2017||Ilkka Rinne||Iurie Maxim 21/4/2017: We did not encounter issues related to use of SLDs for WMS, but for WMS we used only simple features (based on flat data) for increasing the speed of rendering the images from the data. We used both Geoserver and ArcGIS Server for WMS and each has some advantages and disatvantages related to SLDs and filtering the data. We do not see any reason of using complex features in WMS and we do not see any requirement or reccomandation to do so. The link between WMS and WFS features can be ensured trough short URL, such as for example http://inspire.teamnet.ro/ENV/PADS/psPS/RONPA0022|
|13||SLD editing fails sometimes when updating a ComplexFeature layer style||When saving an edited SLD style which is used on a layer based on AppSchema complex feature type, the workspace option becomes empty, and sometimes the whole SLD definition is lost. This seems to be connected to how GeoWebCache fails to update the cached layer data for complex feature layers.||No workaround. Save SLDs often and store them in a safe place :-)||all||2.10.2||3/17/2017||Ilkka Rinne|
|14||GetProperyValue for an element of a featureType embeded in another featureType is returning null namespace prefixes in the GML||For example a GetPropertyValue request to retrieve the geographical name of a protected site will return null namespace prefixes in the GML. With other software there are no such issues. Links to test: 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|
|all||all untill the last 2.12-beta||4/21/2017||Iurie Maxim||This bug was reported at https://osgeo-org.atlassian.net/browse/GEOS-8108, on 2017/07/04. The fix from July 2017 did not solved this issue||https://osgeo-org.atlassian.net/browse/GEOS-8108|
|15||GetSpatialDataSet StoredQuerry is providing null namespace prefixes while retriewing a dataset with multiple featureTypes.||GetSpatialDataSet StoredQuerry is providing null namespace prefixes while retriewing 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 beeing 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 coresponding geographical names, but there are null namespaces. With other software there are no such issues. 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||all||all untill the last 2.12-beta||4/21/2017||Iurie Maxim||This bug was reported at https://osgeo-org.atlassian.net/browse/GEOS-8108, on 2017/07/04. The fix from July 2017 did not solved this issue||https://osgeo-org.atlassian.net/browse/GEOS-8108|
|16||GetFeature requests to virtual services are returning null namespace prefixes, therefore virtual services cant be used as endpoints to fullfill REQ. 51||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 enpoints, 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. Links to test nulls http://inspire.teamnet.ro/geoserver/ps/wfs?request=GetFeature&version=2.0.0&typeNames=ps:ProtectedSite&count=2 and http://geoserver.ymparisto.fi/geoserver/ps/wfs?request=GetFeature&version=2.0.0&typeNames=ps:ProtectedSite&count=2||all||all untill the last 2.12-beta||4/21/2017||Iurie Maxim||This bug was reported at https://osgeo-org.atlassian.net/browse/GEOS-8108, on 2017/07/04. The fix from July 2017 solved only this issue.||https://osgeo-org.atlassian.net/browse/GEOS-8108|
|17||Currently Geoserver's virtual services cant be used for ensuring a unique endpoint per dataset (but only per featureType)||This is because workspaces in Geoserver have a one-to-one relationship with an XSD schema, while for complex features (that are based on multiple XSD schemas) a workspace should have a one-to-many relationship with XSD schemas. |
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 simmilar 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 bbeeing 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 all toghether featureTypes that are part of the dataset.
|do not use virtual services, but create several enpoints by deploying several instances of Geoserver in Tomcat.||all||all untill the last 2.12-beta||4/23/2017||Iurie Maxim|
|18||Geoserver Global Settings dont apply to GML 3.2 GetFeature data||If you configure Geoserver to provide just 2 digits in the GetFeature response, from the global settings tab, this will only apply to GML2 or GML3 data, while GML3.2 data will come with at least 4 digits, and if coming through an App-Schema defined layer, with 8 digits.|
Since GML data is encoded verbose, not binary each digit added to the request greatly increases the overall size of the response
|no known workaround||all||all||04/27/2017||Sorin Rusu||not yet|
|19||Extended capabilities in geoserver are incomplete and EC tests are not passed||According to section 6.6 at page 66 in the Download Service TG (http://inspire.ec.europa.eu/documents/technical-guidance-implementation-inspire-download-services) there are a lot of metadata elements in the extended Get Capabilities document that are not implemented in the Geoserver, namely: The resource type, temporal reference, Responsible Organisation, Metadata Point Of Contact, Metadata Date, Metadata Language, Spatial Data Service Type, Response Language, Supported Languages, Get Download Service Metadata Operation Metadata, Get Spatial Dataset Operation Metadata, Get Describe Spatial Dataset Operation Metadata ...|
This is a known limitation described here http://docs.geoserver.org/latest/en/user/extensions/inspire/using.html
|Edit the wms.xml and wfs.xml file in the data_dir.|
The only issue here is that if anything is changed in the interface the file(s) gets overwritten, so the service should be firstly fully configured in the interface (GUI) and than edited in the Notepad++. Keep a copy of the extended capabilities section for further use.
|20||On a WFS 2.0.0 served with Geoserver and AppSchema, the GetProperyValue for geometry returns a java.lang.ClassCastException message, while for all other properties it works.||In order to provide by reference a protected site geometry for CDDA reporting according to http://dd.eionet.europa.eu/schemas/cdda/CddaReporting_V3.0.xsd, the GetPropertyValue for geometry is needed: http://gmlid.eu/RO/ENV/PADS/WFS?service=wfs&version=2.0.0&request=GetPropertyValue&typeNames=ps:ProtectedSite&valueReference=ps:geometry&featureID=RO.ENV.PADS.PS.RONPA0022. All other properties, excepting geometry, can be retrieved - e.g. http://gmlid.eu/RO/ENV/PADS/WFS?service=wfs&version=2.0.0&request=GetPropertyValue&typeNames=ps:ProtectedSite&valueReference=ps:siteName&featureID=RO.ENV.PADS.PS.RONPA0022.||all||all||06/14/2017||Daniel Cocanu|
|21||On a GetFeature WFS 2.0 request on a virtual service is not possible anymore to get the response in browser, the only response is the default one that is the file to be saved as "application".||A GetFeature request to a virtual service, is not able to provide any other output format than the “application/xml+gml; version=3.2” even if any other type is indicated as default in the WFS settings Override MIME Type (ex: text/xml or text/xml; subtype=gml/3.2) and even if the output format is explicitly requested.|
Link to test that is not possible to specify another output format on requests to virtual services: http://inspire.teamnet.ro/geoserver/ps/wfs?request=GetFeature&version=2.0.0&typeNames=ps:ProtectedSite&outputFormat=text/xml
|Open the provided gml file from downloads||all||all||07/13/2017||Iurie Maxim||This issue appeared in april after it was made this fix: https://osgeo-org.atlassian.net/browse/GEOS-6891||https://osgeo-org.atlassian.net/browse/GEOS-8224|
|22||WFS Schema Location incorrect in DescribeFeatureType||DescribeFeatureType provides an invalid xsd location under the schema location element for the wfs namespace (should be: http://schemas.opengis.net/wfs/2.0/wfs.xsd is: '/usr/share/apache-tomcat-8.5.12/webapps/geoserver/WEB-INF/lib/gt-xsd-wfs-16.2.jar (No such file or directory)')||all||all||09/08/2017||Kathi Schleidt||https://osgeo-org.atlassian.net/browse/GEOS-8250|
|23||Multiple xlinks not possible at base feature level||In some data models (i.e. LandCoverVector), elements with a multiplicity > 1 are used to nest child features within the main feature (in LandCoverVector Units are added by aggregation under the member element). This can be utilized to provide xlinks referencing these features instead of providing all the data inline (causes size issues, i.e. 180MB for 1 feature). Unfortunately, GeoServer App Schema only supports this type of multiplicity at a deeper level within the featureType||Use Deegree||LandCover||all||13.02.2018||Kathi Schleidt|