Add the ability to transform the appearance of a feature type (based on simple features) by:

• Renaming the attributes
• Changing the attribute order

With just these customizations, the ability to write on the feature type via WFS-T should not be lost.

Stretch goals for this proposal would be to also allow for:

• Hiding attributes
• Attribute type re-mapping
• Adding attributes and set their value via CQL expression

Andrea Aime

This proposal is for GeoServer 2.21

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

GeoServer faithfully exposes the attributes of the data source to the OGC services users. This has a few drawbacks:

• Attribute names might be non-descriptive, not matching XML element limitations, or otherwise unfit for publication (e.g., all caps attributes from Oracle, compressed names in Shapefile to match DBF limits).
• The order of the attributes might not be following a logical structure.

In other cases, the original data source contains values of interest split among different attributes (e.g., date and time), or be stored as strings due to data source limitation (e.g. dates stored as ISO strings, finally, some attributes should simply not be published at all (regardless of the user).

We propose to make the attributes of a simple feature type editable from both the GUI and the REST API, mostly using existing facilities.

GUI wise, we propose to add a "customize feature type" check box on top of the existing feature type table, making it editable:

At the beginning, each attribute will have the same structure as the native type, but users will be able to:

• Remove an attribute, using the remove button
• Re-order attributes, by simple drag and drop (same as layers in layer groups)
• Edit the "property" column, renaming the column
• Edit the type, choosing a different type from a drop-down box (or should we allow freeform editing here? E.g. hstore attributes map to a java.util.Map for example).
• Edit the source, eventually typing a complex CQL
• Changing the nullability of an attribute (this will automatically affect the min/max occurrence)

FeatureTypeInfo already contains a list of AttributeTypeInfo objects. The list is normally empty (with the exception of legacy data directories), allowing GeoServer to compute the attributes directly from the feature type, on an as-needed basis.

AttributeTypeInfo already contains name, type binding, nullability, the work in this proposal will add "source" as OpenGIS Expression, which will be serialized as a CQL on disk.

The mapping machinery will be provided by the Geotools gt-transform module, which can support all the requirements, and has the unique ability to retain write support when the mappings configured can be "back-mapped" to source properties.

Most of GeoServer will be unaffected by the changes, as the FeatureSource/FeatureStore instances returned by ResourcePool will perform the required mapping automatically. Classes that will definitely need to be modified are:

• ResourcePool, in its code to compute the final feature type
• GeoServerFeatureSource/Store/Locking, currently doing some light mapping in type names and forcing the chosen CRS
• XStreamPersister to handle the storage of the new properties in AttributeTypeInfo

Foreseeable interactions with the rest of the systems are:

• With authorization subsystems like GeoFence. GeoFence will have to work on top of the provided properties, so working above the attribute re-mapping (as it does today when schema.xsd is used)
• With the feature type own filter attribute, which is also going to work on top of the mapping
• With the old schema.xsd feature type customization, mostly allowing selection of attributes. This one will stop working if the feature type is being customized explicitly.

In most data directories the list of AttributeTypeInfo is empty, but older data directories have them stored, for example, the release data directory does.

On upgrade, the stored attributes will start doing more work than they previously did, as the nullability and the eventual type binding will become active (type binding is actually not present in the release data directory).

While this is probably a minority of cases, and the attribute info should match anyways, we might want to consider adding a new boolean flag in FeatureTypeInfo marking the customization: the feature type transformation would be enacted only when the flag is present and raised.

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime: +1
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen: +1
• Kevin Smith:
• Simone Giannecchini:
• Torben Barsballe: +1
• Nuno Oliveira: +1

• Pull Request 123