-
Notifications
You must be signed in to change notification settings - Fork 7
GSIP 201 Support for schemaless features
Currently GeoServer/GeoTools are built around the assumption about the existance of a fixed schema upfront for the data. This caused for instance the need for the MongoDB datastore to create a Schema based on all the document held by the collection before being able to server any feature. To handle such cases we would like to propose the addition of SchemalessType concept to GeoServer. By **SchemalessType ** we mean a ComplexType/FeatureType implementation that allows the addition/update/removal of descriptors, contrary to the currently existing- ComplexType implementation. Its introduction is meant to support the serving of features that doesn't have a schema defined upfront, as in the mongodb case where each document might have a different set of attributes. Is is worth mentioning that modifiable feature type is not a completely new concept for GeoServer since already exists a FeatureType implementation that in theory allows desciptors to be updated.
Currently when building a feature it is assumed that a feature type is available. This is manifested in the geotools code by the fact that the PropertyImpl class throws an exception if the descriptor is null.
The new SchemalessFeatureType will help to overcome this limitation, by allowing to build a feature type along the features building process, and its update one a new feature with attribute not already added to the schema is found during the streaming process.
The identified impediment to the introduction of the Schemaless concept are listed below with the proposed solution.
Property names are often evaluated against the FeatureType to perform a validation before they are evaluated against a Feature.
The crucial points where validation occurs are, on the GeoServer side in the GetMapKvpRequestReader and in the StreamingRenderer on GeoTools.
We need a way to make the validation uneffective since following a Schemaless approach means to not being able to provide a Schema upfront the features building process.
The proposed solution to overcome the issue is a new PropertyAccessor implementation that would check the object against which the property name is being evaluated returning a ComplexType anyType as a result, thus avoiding the validation checks to fail.
Blocking Unsupported GetFeature requests
Schemaless features are likely to be a problem for GML and other output formats. Thus an exception needs to be thrown for a GetFeature request when asking schemaless features with unsupported output formats.
The foreseen solution is to modify the canHandleInternal method of the WFSGetFeatureOutputFormat class to retrieve the feature type and returning false if it is found to be a SchemalessFeatureType. Then the single implementation will override it to allow or not allow for it.
A schemaless feature will not have a schema defined upfront, each feature read from the datastore may have a different set of attributes ...
Nuno Oliveira Marco Volpini
This proposal is for GeoServer 2.15-beta.
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
Project Steering Committee:
- Alessio Fabiani:
- Andrea Aime:
- Ian Turton:
- Jody Garnett:
- Jukka Rahkonen:
- Kevin Smith:
- Simone Giannecchini:
- Torben Barsballe:
- Nuno Oliveira: