Proposal: GSIP 234 - Advertise and Enforce Attribute Restrictions

aleric-geosolutions · July 31, 2025, 4:59pm

Hello, GeoServer Community,

I’d like to share a new proposal aimed at improving how attribute-level restrictions are managed and exposed in GeoServer.

NOTE: Since I am not allowed to add pages to the Github Wiki, I am posting the full proposal in this post, while adding as an attachment the GSIP in the standard Markdown template.
GSIP-234.md (4.0 KB)

Overview

This proposal introduces support for defining, advertising, and enforcing restrictions on feature type attributes in GeoServer. The goal is to improve data integrity and support clients by:

Allowing administrators to configure restrictions on feature attributes (e.g., enumerations, min/max ranges).
Advertising these restrictions to clients via DescribeFeatureType using standard XML Schema restrictions.
Enforcing the restrictions during write operations (e.g., WFS-T, REST API).

Motivation

GeoServer currently lacks:

A standardized way to expose attribute-level value restrictions to clients.
Server-side enforcement of such restrictions on data writes.
An API for programmatic constraint configuration.

Adding these capabilities will:

Improve data quality by preventing invalid inputs.
Enable client applications (e.g., MapStore, GeoNode) to provide appropriate user interfaces (e.g., dropdowns, numeric bounds).
Ensure consistent behavior across services and interfaces.

Proposed Changes

1. Attribute Constraint Model

Extend the AttributeTypeInfo model to support:

Enumerations of valid values for string and int attributes.
Minimum and maximum inclusive bounds for numeric types.

restrictions will be defined per attribute and stored persistently in the featuretype.xml.

2. Restriction Advertising in DescribeFeatureType

Modify the WFS DescribeFeatureType response to include attribute restrictions using standard XSD restriction elements:

xsd:simpleType with xsd:restriction over the base type
xsd:enumeration for fixed values
xsd:minInclusive / xsd:maxInclusive for numeric ranges

Examples:

<xsd:element name="status" minOccurs="1" maxOccurs="1" nillable="false">
    <xsd:simpleType>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ACTIVE"/>
            <xsd:enumeration value="INACTIVE"/>
            <xsd:enumeration value="UNKNOWN"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:element>


<xsd:element name="value" minOccurs="1" maxOccurs="1" nillable="false">
    <xsd:simpleType>
        <xsd:restriction base="xsd:float">
            <xsd:minInclusive value="0.0"/>
            <xsd:maxInclusive value="100.0"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:element>

3. Constraint Enforcement on Write

Extend GeoServer’s data validation pipeline to enforce the defined restrictions when receiving data write requests via:

WFS-T (Insert/Update)
REST API (PUT/POST)

Restriction compliance checks will occur in GeoserverFeatureStore to centrally ensure consistent enforcement regardless of service or store.

5. Admin UI Support

Enhance the GeoServer admin UI to allow configuring attribute-level restrictions (enumeration, min/max) through the FeatureType editor.

The Feature Type Details table will be made not-editable.

Then, a click on the Edit icon will open a pop-up, to edit the feature type details.
The selection of a specific constraint depends on the type of the attribute.
Example for a “Range” restriction:

Example for an “Options” restriction:

Compatibility

This solution will be aimed to maintain the following:

Fully backward-compatible: restrictions are optional.
DescribeFeatureType output remains valid XSD.

This said, I am eager to hear your thoughts and feedback on this proposal.

Please feel free to share any concerns, suggestions, or alternative approaches that you believe should be considered.

Best regards,
Alessandro Ricchiuti

jnewmoyer · July 31, 2025, 5:29pm

I absolutely love this idea.

Only a couple of questions:

How does this compare to what’s already available with dimensions?
Is there anything covering this in OGC specifications that would be good to follow for interoperability?

aaime-geosolutions · August 4, 2025, 12:35pm

They are unrelated, dimensions are a WMS specific concept, while the proposal talks about WFS instead (which has no dimensions at all). That said, WMS dimensions are providing a list of valid values for a dimension, and the XML schema restrictions are doing something similar.

The activation is opposite though, querying vs writing:

In WMS if you use a dimension value that’s not in the list of valid values, you should get an exception (that’s querying)
In WFS if you query with a value that’s not in the domain, you get an empty response. It’s when you write that you’ll get an exception.

The proposal is already using the one bit that the specification provides in this regard: the DescribeFeatureType provides an XML schema, any violation of the schema should be met with an exception (although often times GeoServer is lenient).

Cheers
Andrea

nmco · August 4, 2025, 4:36pm

Hi Alessandro,
+1 from me.

ianturton · August 4, 2025, 5:09pm

+1

Ian

aaime-geosolutions · August 4, 2025, 5:26pm

Hi Alessandro,
thanks for your proposal, I’ve added it to the wiki:

Looks good to me. Just a tiny bit of feedback GUI wise, I’d consider doing something about the list of options, when it’s displayed in the main panel… maybe show it as comma separated to make sure it does not use too much vertical space, and eventually limit to the number of entries that are displayed. E.g., if more than 10 you could use ellipsis to indicate there are more entries but they are too many.
Something like this:

Options: opt1,opt2,opt3,opt4,opt5,opt6,opt7,opt8,opt9,…

Cheers
Andrea

afabiani · August 5, 2025, 9:11am

+1 thanks

aaime-geosolutions · August 6, 2025, 7:58am

And oh, I forgot to vote… +1

Thanks for advertising the schema restrictions with a standard compliant syntax, that should allow clients to figure out the valid values and come up with sensible GUI controls when doing WFS-T

Cheers
Andrea

simonegiannecchini · August 6, 2025, 8:13am

+0

jive · August 6, 2025, 9:47pm

Thanks @aleric-geosolutions and @aaime-geosolutions for adding to wiki.

Alessandro can you give me your GitHub handle, we have a group for people that have asked to edit the wiki. We do not have fine grain control (need a professional account for that) but we can trust you to edit the wiki, and not merge random PRs.

jive · August 6, 2025, 10:04pm

+1

The only hesitations I have are on that table:

vertical alignment
I assume you want up and down arrows for order?
These tables (in several parts of the UI) are getting larger and larger over time

Q:Do we need to sort by description or details? If not we may be able to reduce the number of columns (with name and description combined, and type and restrictions combined)

	Attribute	Type
1	the_geom POI	Point
2	NAME source: origional_name	String
3	THUMBNAIL POI tumbnail	String Options: 1.png 2.png abc.png

aleric-geosolutions · August 7, 2025, 8:43am

Hello @jive .

@axl8713 is my GitHub handle.

Thanks!

tbarsballe · August 12, 2025, 4:54pm

+1 from me.

Looks like a very useful addition.
One thing I am a bit curious about is how this will interact with existing feature restrictions coming from the underlying datastore (e.g. a JDBC database with column constraints).
My assumption would be these would behave as manually configured restrictions (and not be editable, if the DB schema isn’t editable) but that isn’t entirely clear from the proposal.

Cheers,
Torben

On Thu, Jul 31, 2025 at 10:05 AM Alessandro Ricchiuti via OSGeo Discourse <noreply@discourse.osgeo.org> wrote:

aleric-geosolutions
July 31

Hello, GeoServer Community,

I’d like to share a new proposal aimed at improving how attribute-level restrictions are managed and exposed in GeoServer.

NOTE: Since I am not allowed to add pages to the Github Wiki, I am posting the full proposal in this post, while adding as an attachment the GSIP in the standard Markdown template.
GSIP-234.md (4.0 KB)

Overview

This proposal introduces support for defining, advertising, and enforcing restrictions on feature type attributes in GeoServer. The goal is to improve data integrity and support clients by:

Allowing administrators to configure restrictions on feature attributes (e.g., enumerations, min/max ranges).

Advertising these restrictions to clients via DescribeFeatureType using standard XML Schema restrictions.

Enforcing the restrictions during write operations (e.g., WFS-T, REST API).

Motivation

GeoServer currently lacks:

A standardized way to expose attribute-level value restrictions to clients.

Server-side enforcement of such restrictions on data writes.

An API for programmatic constraint configuration.

Adding these capabilities will:

Improve data quality by preventing invalid inputs.

Enable client applications (e.g., MapStore, GeoNode) to provide appropriate user interfaces (e.g., dropdowns, numeric bounds).

Ensure consistent behavior across services and interfaces.

Proposed Changes### 1. Attribute Constraint Model

Extend the AttributeTypeInfo model to support:

Enumerations of valid values for string and int attributes.

Minimum and maximum inclusive bounds for numeric types.

restrictions will be defined per attribute and stored persistently in the featuretype.xml.

2. Restriction Advertising in DescribeFeatureType

Modify the WFS DescribeFeatureType response to include attribute restrictions using standard XSD restriction elements:

xsd:simpleType with xsd:restriction over the base type

xsd:enumeration for fixed values

xsd:minInclusive / xsd:maxInclusive for numeric ranges

Examples:
<xsd:element name="status" minOccurs="1" maxOccurs="1" nillable="false">
    <xsd:simpleType>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ACTIVE"/>
            <xsd:enumeration value="INACTIVE"/>
            <xsd:enumeration value="UNKNOWN"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:element>
<xsd:element name="value" minOccurs="1" maxOccurs="1" nillable="false">
    <xsd:simpleType>
        <xsd:restriction base="xsd:float">
            <xsd:minInclusive value="0.0"/>
            <xsd:maxInclusive value="100.0"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:element>
3. Constraint Enforcement on Write

Extend GeoServer’s data validation pipeline to enforce the defined restrictions when receiving data write requests via:

WFS-T (Insert/Update)

REST API (PUT/POST)

Restriction compliance checks will occur in GeoserverFeatureStore to centrally ensure consistent enforcement regardless of service or store.

5. Admin UI Support

Enhance the GeoServer admin UI to allow configuring attribute-level restrictions (enumeration, min/max) through the FeatureType editor.

The Feature Type Details table will be made not-editable.

Then, a click on the Edit icon will open a pop-up, to edit the feature type details.
The selection of a specific constraint depends on the type of the attribute.
Example for a “Range” restriction:

Example for an “Options” restriction:

Compatibility

This solution will be aimed to maintain the following:

Fully backward-compatible: restrictions are optional.

DescribeFeatureType output remains valid XSD.

This said, I am eager to hear your thoughts and feedback on this proposal.

Please feel free to share any concerns, suggestions, or alternative approaches that you believe should be considered.

Best regards,
Alessandro Ricchiuti

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

aleric-geosolutions · September 17, 2025, 1:46pm

Hello, @jive. Sorry for the late reply.

I’m posting here some examples of the table showing attributes with “heavy” customization, for example when there is a long options list.
Here is a screenshot from a laptop (1920x1200):

And here is one from an emulated iPad:

As you can see, despite the lengthy description and the large options list, the UI does not suffer too much from the amount of information displayed.

As for the sorting by description/details, I’m not sure about the actual need, so I don’t have a strong opinion there.

aleric-geosolutions · September 17, 2025, 1:56pm

Hello, @tbarsballe. Sorry for the late reply.
These constraints actually serve different purposes, or better, represent different approaches to setting constraints on the data.
In our case, the constraints defined in the UI are always enforced at the GeoTools / GeoServer level, regardless of whether the underlying datastore already has its own constraints.

Hope this clarifies things!
Happy to discuss further if needed.

aleric-geosolutions · September 18, 2025, 10:14am

Hello, everyone.

I’ve moved the GSIP under the “Active Proposals” section of the wiki.

PRs are here:

Thanks in advance to anyone who can have a look at them!

Cheers,
– Alessandro

jive · September 19, 2025, 11:48pm

Thanks @aleric-geosolutions for all your work thus far, I had a review of the PR ahead of GeoServer 2.28-M0 milestone relesae - and it is stuck on some compile warnings.

The functionality is very welcome and I would love to see both this GSIP approved and the PR merged next week if possible.