Allow Symbolizer to provide computed geometries

Description

The previous Styled Layer Description and the latest Symbology Encoding specification (document OGC 05-077r4 released in 2007) define the Symbolizer geometry attribute as a PropertyName. This specification matches the XSD the definition, which is:

 

Consequently the geometry attribute has been defined as below in the http://www.geoapi.org/snapshot/pending/org/opengis/style/Symbolizer.html - GeoAPI interface:

@XmlElement()
getGeometryPropertyName();

Looking closer at the SE specification we can read, page 24:

<blockquote>
The only method available for defining a geometry is to reference a geometry property using the ogcropertyName element (defined in the Filter Specification). The content of the element gives the property name in XPath syntax. In principle, a fixed geometry could be defined using GML or operators could be defined for computing the geometry from references or literals. However, using a feature property directly is by far the most
commonly useful method.</blockquote>

Computed geometries have always been an option, but has been excluded since it's a very small % of the use cases. We believe this choice has been made to simplify interoperability and implementations. But ourdays computer capabilities have greatly improved, and so has GPU performances and mapping in general. Computed geometries are now used in meteorology, navy, statistic maps, or to achieve stylish effects.

In 2009 Jody Garnett added a commented block:

/**

  • Expression used to define a geometry

  • geometry attribute should be used. This expression is often a PropertyName.
    *

  • @ geometry should be used.
    */
    /* Expression getGeometry(); */

The proposal is to uncomment the method introduced by Jody Garnett on Symbolizer:

  • Expression getGeometry();

Impact of this change on other interfaces

The SymbolizerFactory also use an Expression to define the geometry attribute:

  • PointSymbolizer pointSymbolizer(String name, Expression geometry, ... );
    * LineSymbolizer lineSymbolizer(String name, Expression geometry, ... );
    * PolygonSymbolizer polygonSymbolizer(String name, Expression geometry, ... );
    * RasterSymbolizer rasterSymbolizer(String name, Expression geometry, ... )
    * TextSymbolizer textSymbolizer(String name, Expression geometry, ... )

The only exception is the extension symbolizer which is still defined as a string in the factory:

  • ExtensionSymbolizer extensionSymbolizer(String name, String geometry, ... );

If this JIRA issue is accepted, then the we would add the missing create method for extension symbolizer on StyleFactory:

  • ExtensionSymbolizer extensionSymbolizer(String name, Expression geometry, ... );

Deprecation

If this JIRA task is accepted, then the current Symbolizer.getPropertyName() would become unnecessary, since its functionality can be handle by the new method with a PropertyName expression. We propose to deprecate the old method.

Environment

None

Status

Assignee

Unassigned

Reporter

codehaus

Priority

Medium
Configure