[Geoserver-users] Proposal for a change to the Recode function

While I love the Recode function, there is one problem with it. There is no (obvious) way to define a value to use if none of the 'data' items matches the 'lookupValue', and the current structure doesn't lend itself to adding one. I can see three potential ways to solve this

1) Change the definition of the 'data' element to be compared using Regular Expression syntax to the lookupValue, or

2) Add a attribute to the Function element called something like 'default'. If no match is found in the data elements, use the value it specifies as the content.

3) Define a special value/position for the data element that would be treated as the default if found. For example, if the last data item in the list was the literal value 'default' then use if no other earlier match.

The first item is likely too large a change to current/expected behavior, so at best I can see this as a new 'RecodeRegEx' function or similar.

The second item is the one I like best, but I don't know if the applicable standard would allow (of could be changed to allow) attributes for the Function element.

The third option is likely the easiest, but I don't particularly like special cases of this nature - too easy to cause unexpected behaviors.

So does anyone else have similar thoughts, and/or other ideas on how to deal with this?

I got one more suggestion to consider:

  1. Count the attributes and if event consider the last attribute as the default value.

This is a bit tricky Tom as the recode function is not defined by us - it is part of the symbology encoding 1.1 specification (so it is a mandatory function we must implement to be SE 1.1 compatible).

Here is a quote from http://www.opengeospatial.org/standards/se

Recoding is defined by the Recode element:

<xsd:element name=“Recode” type=“se:RecodeType” substitutionGroup=“se:Function”/>

<xsd:complexType name=“RecodeType”>

xsd:complexContent

<xsd:extension base=“se:FunctionType”>

xsd:sequence

<xsd:element ref=“se:LookupValue”/>

<xsd:element ref=“se:MapItem” maxOccurs=“unbounded”/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:complexType>

<xsd:element name=“MapItem” type=“se:MapItemType” substitutionGroup=“ogc:expression”/>

<xsd:complexType name=“MapItemType”>

xsd:complexContent

<xsd:extension base=“ogc:ExpressionType”>

xsd:sequence

<xsd:element ref=“se:Data”/>

<xsd:element ref=“se:Value”/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexTyp:>

This function recodes values from a property or expression into corresponding values of

arbitrary type. The comparisons are performed checking for identical values.

I also wonder if we are missing a point, these functions each have an optional fallback value (supposed to be used if the function is not available on the engine doing the rendering). We could hijack this fallback value:

ogc:PropertyNamevehiclesPerHour</ogc:PropertyName>

15000
215000
340000
475000
5

···

On 14 October 2016 at 17:05, Tom S <tom-sourceforge@anonymised.com> wrote:

While I love the Recode function, there is one problem with it. There is
no (obvious) way to define a value to use if none of the ‘data’ items
matches the ‘lookupValue’, and the current structure doesn’t lend itself
to adding one. I can see three potential ways to solve this

  1. Change the definition of the ‘data’ element to be compared using
    Regular Expression syntax to the lookupValue, or

  2. Add a attribute to the Function element called something like
    ‘default’. If no match is found in the data elements, use the value it
    specifies as the content.

  3. Define a special value/position for the data element that would be
    treated as the default if found. For example, if the last data item in
    the list was the literal value ‘default’ then use if no other earlier match.

The first item is likely too large a change to current/expected
behavior, so at best I can see this as a new ‘RecodeRegEx’ function or
similar.

The second item is the one I like best, but I don’t know if the
applicable standard would allow (of could be changed to allow)
attributes for the Function element.

The third option is likely the easiest, but I don’t particularly like
special cases of this nature - too easy to cause unexpected behaviors.

So does anyone else have similar thoughts, and/or other ideas on how to
deal with this?


Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


Geoserver-users mailing list
Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


Jody Garnett