[Geoserver-users] Recode Transform problem when used with stroke-dasharray

GeoServer GeoServer User
1

I am seeing an odd behavior in GeoServer V2.2.2 with Style processing. I have a style that includes

<sld:Rule>
<sld:MaxScaleDenominator>8000.0</sld:MaxScaleDenominator>

<TextSymbolizer>
<Label>
<ogc:Function name="Recode">
<ogc:PropertyName>data_type</ogc:PropertyName>

<ogc:Literal>0</ogc:Literal> <!-- Other -->
<ogc:Literal>2 1 1 2 </ogc:Literal>

<ogc:Literal>1</ogc:Literal> <!-- Closed -->
<ogc:Literal>1 1</ogc:Literal>
</ogc:Function>
</Label>
</TextSymbolizer>

<sld:LineSymbolizer>
<sld:Stroke>

<sld:CssParameter name="stroke-width">12</sld:CssParameter>

<sld:CssParameter name="stroke">
<ogc:Function name="Recode">
<ogc:PropertyName>congestion_level</ogc:PropertyName>

<ogc:Literal>B</ogc:Literal> <!-- Black -->
<ogc:Literal>#CC0000</ogc:Literal>

<ogc:Literal>R</ogc:Literal> <!-- Red -->
<ogc:Literal>#FF9900</ogc:Literal>
</ogc:Function>
</sld:CssParameter>

<sld:CssParameter name="stroke-dasharray">
<ogc:Function name="Recode">
<ogc:PropertyName>data_type</ogc:PropertyName>

<ogc:Literal>0</ogc:Literal> <!-- Other -->
<ogc:Literal>2 1 1 2 </ogc:Literal>

<ogc:Literal>1</ogc:Literal> <!-- Closed -->
<ogc:Literal>1 1</ogc:Literal>

</ogc:Function>
</sld:CssParameter>

<sld:CssParameter name="stroke-opacity">0.6</sld:CssParameter>

</sld:Stroke>
</sld:LineSymbolizer>
</sld:Rule>

The line label shows the expected value (based on the data_type attribute). The line color is set as expected in the first transform. But the line style is NOT being applied. If I put a copy of the <sld:CssParameter name="stroke-dasharray"> directive without the function it renders as expected (and was hard coded).

Any thoughts on why this might be misbehaving?

And on a related note, there is nothing in the docs, but is there any way to have a 'default/otherwise' type value of last resort in cases where none of the literals match. If not I would recommend this as a useful addition.

--

Tom Saul --- ICx Transportation Group --- 360-620-9975

Conference Bridge: 404-835-7069 or 866-210-1669 : Code 3606209975
Web Conference : URL http://www.atconference.com/meet

2

On Thu, Feb 28, 2013 at 3:50 AM, Tom S <tom-sourceforge@anonymised.com.> wrote:

I am seeing an odd behavior in GeoServer V2.2.2 with Style processing.

stroke-dasharray only works with literals, there is no support for freeform expressions.
There is some interest in making it allow freeform expressions, but the change is
deep and can be done only on the development series:
https://jira.codehaus.org/browse/GEOT-3776
Right now I’m not clear if Tobias is trying to make a quick hack that is not likely be accepted
by the community, or the full solution that takes time (but that would be accepted).

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

3

Thanks - this subtlety is not obvious in the documentation (to me) - especially since the parameter to Recode is a Literal. So the next question is, is there a way to convert the Recode output into a Literal. I have tried wrapping the entire function invocation in a Literal block (doesn’t work). Would it be possible to add a ‘parseLiteral’ function that converted data into the needed format, or is there already a way to do this?

···

On 2/27/2013 11:01 PM, Andrea Aime wrote:

On Thu, Feb 28, 2013 at 3:50 AM, Tom S <tom-sourceforge@anonymised.com> wrote:

I am seeing an odd behavior in GeoServer V2.2.2 with Style processing.

stroke-dasharray only works with literals, there is no support for freeform expressions.
There is some interest in making it allow freeform expressions, but the change is
deep and can be done only on the development series:
https://jira.codehaus.org/browse/GEOT-3776
Right now I’m not clear if Tobias is trying to make a quick hack that is not likely be accepted
by the community, or the full solution that takes time (but that would be accepted).

Cheers
Andrea

4

On Thu, Feb 28, 2013 at 6:22 PM, Tom S <tom-sourceforge@anonymised.com.> wrote:

Thanks - this subtlety is not obvious in the documentation (to me) - especially since the parameter to Recode is a Literal. So the next question is, is there a way to convert the Recode output into a Literal. I have tried wrapping the entire function invocation in a Literal block (doesn’t work). Would it be possible to add a ‘parseLiteral’ function that converted data into the needed format, or is there already a way to do this?

None (besides changing the code as suggested in that jira ticket). When a parameter is a literal, the only accepted input is a static string

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it