Polymorphism in application-schema
Support for polymorphism is included in Geoserver 2.0.2. Why do we need polymorphism support in app-schema? Some complex attributes are polymorphic by nature, which means they can have different types for different features.
Before polymorphism was supported, attribute types had to be specified in the mapping file, so could not vary across features. With polymorphism support, filter functions can now be used to specify conditions when determining the encoded type.
If MaterialCode is “rock”, er:material should be encoded as gsml:RockMaterial, otherwise it should be encoded as gsml:Mineral.
This can be expressed in the mapping file like this:
<AttributeMapping> <targetAttribute>er:material</targetAttribute> <sourceExpression> <linkElement> if_then_else(equalTo(MaterialCode, 'rock'), 'gsml:RockMaterial', 'gsml:Mineral') </linkElement> </sourceExpression> </AttributeMapping>
Another common example is replacing null values with an xlink:href to a URI representing missing values:
<AttributeMapping> <targetAttribute>er:startDate</targetAttribute> <sourceExpression> <linkElement>if_then_else(isNull(START_DATE), toXlinkHref('urn:ogc:def:nil:OGC::missing'), 'gml:TimeInstantPropertyType') </linkElement> </sourceExpression> </AttributeMapping>
Read more about app-schema polymorphism support: polymorphism.
- OGC Filter Injection Vulnerability Statement
- GeoServer 2.22.0 Release
- GeoServer 2.21.2 Release
- Jiffle and GeoTools RCE vulnerabilities
- GeoServer 2.20.4 Released
- Spring4Shell RCE vulnerability
- GeoServer 2.20.3 Released
- GeoServer 2.19.5 Released
- GeoServer 2.19.4 Released
- Log4J2 zero day vulnerability assessment