[Geoserver-devel] Problem obtaining an SLD from the REST API

Hi,

When I try to obtain an SLD from GeoServer REST API that have an WellKnownName element that use some ogc:function I don't get the expected result.

Lets say I have following SLD:

<?xml version="1.0" encoding="utf-8"?>
<sld:StyledLayerDescriptor xmlns="http://www.opengis.net/sld&quot;
                              xmlns:sld="http://www.opengis.net/sld&quot;
                              xmlns:ogc="http://www.opengis.net/ogc&quot;
                              xmlns:gml="http://www.opengis.net/gml&quot; version="1.0.0">
   <sld:NamedLayer>
     <sld:Name>test</sld:Name>
     <sld:UserStyle>
       <sld:FeatureTypeStyle>
         <sld:Rule>
           <sld:PointSymbolizer>
             <sld:Graphic>
               <sld:Mark>
                 <sld:WellKnownName>
                   <ogc:Function name="strToUpperCase">
                     <ogc:Literal>shape</ogc:Literal>
                   </ogc:Function>
                 </sld:WellKnownName>
               </sld:Mark>
             </sld:Graphic>
           </sld:PointSymbolizer>
         </sld:Rule>
       </sld:FeatureTypeStyle>
     </sld:UserStyle>
   </sld:NamedLayer>
</sld:StyledLayerDescriptor>

The request /geoserver/rest/styles/test.sld will return:

<?xml version="1.0" encoding="utf-8"?>
<sld:StyledLayerDescriptor xmlns="http://www.opengis.net/sld&quot;
                            xmlns:sld="http://www.opengis.net/sld&quot;
                            xmlns:ogc="http://www.opengis.net/ogc&quot;
                            xmlns:gml="http://www.opengis.net/gml&quot; version="1.0.0">
   <sld:NamedLayer>
     <sld:Name>test</sld:Name>
     <sld:UserStyle>
       <sld:Name>test</sld:Name>
       <sld:FeatureTypeStyle>
         <sld:Name>name</sld:Name>
         <sld:Rule>
           <sld:PointSymbolizer>
             <sld:Graphic>
               <sld:Mark>
<sld:WellKnownName>strToUpperCase([shape])</sld:WellKnownName>
               </sld:Mark>
             </sld:Graphic>
           </sld:PointSymbolizer>
         </sld:Rule>
       </sld:FeatureTypeStyle>
     </sld:UserStyle>
   </sld:NamedLayer>
</sld:StyledLayerDescriptor>

I don't know if this is a bug or the expected output, the SLDTransformer class in Geotools handles the WellKnownName element as a simple element and only do a simple toString:

         public void visit(Mark mark) {
             start("Mark");
             if (mark.getWellKnownName() != null && !"square".equals(mark.getWellKnownName().evaluate(null))) {
                 element("WellKnownName", mark.getWellKnownName().toString());
             }
             if (mark.getFill() != null) {
                 mark.getFill().accept(this);
             }
             if (mark.getStroke() != null) {
                 mark.getStroke().accept(this);
             }
             end("Mark");
         }

In my point of view the WellKnownName should have a full conversion, i.e. instead of:

     element("WellKnownName", mark.getWellKnownName().toString());

we should have:

     encodeValue("WellKnownName", null, mark.getWellKnownName(), null);

If this is not the expect behavior I can make a pull request in Geotools and if this is the expected behavior can someone give-me some explanation about ?

Best regards,

Nuno Oliveira

On Tue, Mar 4, 2014 at 3:03 PM, Nuno Oliveira <
nuno-miguel-oliveira@anonymised.com> wrote:

In my point of view the WellKnownName should have a full conversion,
i.e. instead of:

     element("WellKnownName", mark.getWellKnownName().toString());

we should have:

     encodeValue("WellKnownName", null, mark.getWellKnownName(), null);

If this is not the expect behavior I can make a pull request in Geotools
and if this is the expected behavior can someone give-me some
explanation about ?

So, the SLD spec says, that the well known name is a fixed string:

<xsd:element name="WellKnownName" type="xsd:string"/>

However we extended our own parser and machinery to deal with a generic
expression, but the same was not done for the encoding part, so this is a
bug.
A pull request would be welcomed, please remember to include a test

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

-------------------------------------------------------

I think you have just found a gap from when we extended SLD to support expressions for dynamic marks. Technically SLD should only allow a String for WellKnownName, I would expect the expression to be encoded as a String with a bit more escaping.

See:

···

Jody Garnett

On Wed, Mar 5, 2014 at 1:03 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

When I try to obtain an SLD from GeoServer REST API that have an
WellKnownName element that use some ogc:function I don’t get the
expected result.

Lets say I have following SLD:

<?xml version="1.0" encoding="utf-8"?>

<sld:StyledLayerDescriptor xmlns=“http://www.opengis.net/sld
xmlns:sld=“http://www.opengis.net/sld
xmlns:ogc=“http://www.opengis.net/ogc
xmlns:gml=“http://www.opengis.net/gml
version=“1.0.0”>
sld:NamedLayer
sld:Nametest</sld:Name>
sld:UserStyle
sld:FeatureTypeStyle
sld:Rule
sld:PointSymbolizer
sld:Graphic
sld:Mark
sld:WellKnownName
<ogc:Function name=“strToUpperCase”>
ogc:Literalshape</ogc:Literal>
</ogc:Function>
</sld:WellKnownName>
</sld:Mark>
</sld:Graphic>
</sld:PointSymbolizer>
</sld:Rule>
</sld:FeatureTypeStyle>
</sld:UserStyle>
</sld:NamedLayer>
</sld:StyledLayerDescriptor>

The request /geoserver/rest/styles/test.sld will return:

<?xml version="1.0" encoding="utf-8"?>

<sld:StyledLayerDescriptor xmlns=“http://www.opengis.net/sld
xmlns:sld=“http://www.opengis.net/sld
xmlns:ogc=“http://www.opengis.net/ogc
xmlns:gml=“http://www.opengis.net/gml
version=“1.0.0”>
sld:NamedLayer
sld:Nametest</sld:Name>
sld:UserStyle
sld:Nametest</sld:Name>
sld:FeatureTypeStyle
sld:Namename</sld:Name>
sld:Rule
sld:PointSymbolizer
sld:Graphic
sld:Mark
sld:WellKnownNamestrToUpperCase([shape])</sld:WellKnownName>
</sld:Mark>
</sld:Graphic>
</sld:PointSymbolizer>
</sld:Rule>
</sld:FeatureTypeStyle>
</sld:UserStyle>
</sld:NamedLayer>
</sld:StyledLayerDescriptor>

I don’t know if this is a bug or the expected output, the SLDTransformer
class in Geotools handles the WellKnownName element as a simple element
and only do a simple toString:

public void visit(Mark mark) {
start(“Mark”);
if (mark.getWellKnownName() != null &&
!“square”.equals(mark.getWellKnownName().evaluate(null))) {
element(“WellKnownName”,
mark.getWellKnownName().toString());
}
if (mark.getFill() != null) {
mark.getFill().accept(this);
}
if (mark.getStroke() != null) {
mark.getStroke().accept(this);
}
end(“Mark”);
}

In my point of view the WellKnownName should have a full conversion,
i.e. instead of:

element(“WellKnownName”, mark.getWellKnownName().toString());

we should have:

encodeValue(“WellKnownName”, null, mark.getWellKnownName(), null);

If this is not the expect behavior I can make a pull request in Geotools
and if this is the expected behavior can someone give-me some
explanation about ?

Best regards,

Nuno Oliveira


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi Aime,

Thanks for the feedback. I will make a pull request in Geotools and provide a test for this use case.

Best regards,

Nuno Oliveira

On 03/04/2014 02:10 PM, Andrea Aime wrote:

On Tue, Mar 4, 2014 at 3:03 PM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com <mailto:nuno-miguel-oliveira@anonymised.com>> wrote:

    In my point of view the WellKnownName should have a full conversion,
    i.e. instead of:

         element("WellKnownName", mark.getWellKnownName().toString());

    we should have:

         encodeValue("WellKnownName", null, mark.getWellKnownName(),
    null);

    If this is not the expect behavior I can make a pull request in
    Geotools
    and if this is the expected behavior can someone give-me some
    explanation about ?

So, the SLD spec says, that the well known name is a fixed string:

<xsd:element name="WellKnownName" type="xsd:string"/>

However we extended our own parser and machinery to deal with a generic
expression, but the same was not done for the encoding part, so this is a bug.
A pull request would be welcomed, please remember to include a test

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

-------------------------------------------------------

Hi,

Sorry, I don't understand what you mean by: "I would expect the expression to be encoded as a String with a bit more escaping".

Do you agree in having a full encoding of the WellkownName element (i.e. its expression):

     encodeValue("WellKnownName", null, mark.getWellKnownName(), null);

or just having a more powerful toString ?

Best regards,

Nuno Oliveira

On 03/04/2014 02:11 PM, Jody Garnett wrote:

I think you have just found a gap from when we extended SLD to support expressions for dynamic marks. Technically SLD should only allow a String for WellKnownName, I would expect the expression to be encoded as a String with a bit more escaping.
See:
- http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
- http://blog.geoserver.org/2008/12/16/dynamic-symbolizers-part-2/

Jody Garnett

On Wed, Mar 5, 2014 at 1:03 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com <mailto:nuno-miguel-oliveira@anonymised.com>> wrote:

    Hi,

    When I try to obtain an SLD from GeoServer REST API that have an
    WellKnownName element that use some ogc:function I don't get the
    expected result.

    Lets say I have following SLD:

    <?xml version="1.0" encoding="utf-8"?>
    <sld:StyledLayerDescriptor xmlns="http://www.opengis.net/sld&quot;
                                  xmlns:sld="http://www.opengis.net/sld&quot;
                                  xmlns:ogc="http://www.opengis.net/ogc&quot;
                                  xmlns:gml="http://www.opengis.net/gml&quot;
    version="1.0.0">
       <sld:NamedLayer>
         <sld:Name>test</sld:Name>
         <sld:UserStyle>
           <sld:FeatureTypeStyle>
             <sld:Rule>
               <sld:PointSymbolizer>
                 <sld:Graphic>
                   <sld:Mark>
                     <sld:WellKnownName>
                       <ogc:Function name="strToUpperCase">
     <ogc:Literal>shape</ogc:Literal>
                       </ogc:Function>
                     </sld:WellKnownName>
                   </sld:Mark>
                 </sld:Graphic>
               </sld:PointSymbolizer>
             </sld:Rule>
           </sld:FeatureTypeStyle>
         </sld:UserStyle>
       </sld:NamedLayer>
    </sld:StyledLayerDescriptor>

    The request /geoserver/rest/styles/test.sld will return:

    <?xml version="1.0" encoding="utf-8"?>
    <sld:StyledLayerDescriptor xmlns="http://www.opengis.net/sld&quot;
                                xmlns:sld="http://www.opengis.net/sld&quot;
                                xmlns:ogc="http://www.opengis.net/ogc&quot;
                                xmlns:gml="http://www.opengis.net/gml&quot;
    version="1.0.0">
       <sld:NamedLayer>
         <sld:Name>test</sld:Name>
         <sld:UserStyle>
           <sld:Name>test</sld:Name>
           <sld:FeatureTypeStyle>
             <sld:Name>name</sld:Name>
             <sld:Rule>
               <sld:PointSymbolizer>
                 <sld:Graphic>
                   <sld:Mark>
    <sld:WellKnownName>strToUpperCase([shape])</sld:WellKnownName>
                   </sld:Mark>
                 </sld:Graphic>
               </sld:PointSymbolizer>
             </sld:Rule>
           </sld:FeatureTypeStyle>
         </sld:UserStyle>
       </sld:NamedLayer>
    </sld:StyledLayerDescriptor>

    I don't know if this is a bug or the expected output, the
    SLDTransformer
    class in Geotools handles the WellKnownName element as a simple
    element
    and only do a simple toString:

             public void visit(Mark mark) {
                 start("Mark");
                 if (mark.getWellKnownName() != null &&
    !"square".equals(mark.getWellKnownName().evaluate(null))) {
                     element("WellKnownName",
    mark.getWellKnownName().toString());
                 }
                 if (mark.getFill() != null) {
                     mark.getFill().accept(this);
                 }
                 if (mark.getStroke() != null) {
                     mark.getStroke().accept(this);
                 }
                 end("Mark");
             }

    In my point of view the WellKnownName should have a full conversion,
    i.e. instead of:

         element("WellKnownName", mark.getWellKnownName().toString());

    we should have:

         encodeValue("WellKnownName", null, mark.getWellKnownName(),
    null);

    If this is not the expect behavior I can make a pull request in
    Geotools
    and if this is the expected behavior can someone give-me some
    explanation about ?

    Best regards,

    Nuno Oliveira

    ------------------------------------------------------------------------------
    Subversion Kills Productivity. Get off Subversion & Make the Move
    to Perforce.
    With Perforce, you get hassle-free workflows. Merge that actually
    works.
    Faster operations. Version large binaries. Built-in WAN
    optimization and the
    freedom to use Git, Perforce or both. Make the move to Perforce.
    http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

The proposal[1] documents the use of ${ cql expression} so your original example would be:

sld:WellKnownName${strToUpperCase(‘shape’)}</sld:WellKnownName>

···

On Wed, Mar 5, 2014 at 1:47 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

Sorry, I don’t understand what you mean by: “I would expect the expression to be encoded as a String with a bit more escaping”.

Do you agree in having a full encoding of the WellkownName element (i.e. its expression):

encodeValue(“WellKnownName”, null, mark.getWellKnownName(), null);

or just having a more powerful toString ?

Best regards,

Nuno Oliveira

On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The proposal[1] documents the use of ${ cql expression} so your original
example would be:

<sld:WellKnownName>${strToUpperCase('shape')}</sld:WellKnownName>

Jody, the proposal was implemented so that the syntax above is used only
for external graphics
(where we don't have space to embed a Expression) but not for
WellKnownName, where a
regular expression can be used.

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

-------------------------------------------------------

Thanks Jody and Aime for the explanations, I will proceed with the pull request.

By the way ( I know and understand the need to follow with the standards but, ) when we have a big SLD with complex "business" based on scales, request attributes , properties ... we often end up with an SLD that have a lot of boilerplate code and vendor options that makes him very difficult to maintain and is very error-prone.

The function mechanism is nice but requires implementing some Java code and the XML can become very bad ...

Does Geoserver have any intention to improve the SLD dynamics mechanisms ?

It would be nice to have some more powerful scripting support like SpEL or Groovy for example.

( http://docs.spring.io/spring/docs/4.0.3.BUILD-SNAPSHOT/spring-framework-reference/htmlsingle/#expressions)

Best regards,

Nuno Oliveira

On 03/04/2014 03:26 PM, Andrea Aime wrote:

On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett <jody.garnett@anonymised.com <mailto:jody.garnett@anonymised.com>> wrote:

    The proposal[1] documents the use of ${ cql expression} so your
    original example would be:

    <sld:WellKnownName>${strToUpperCase('shape')}</sld:WellKnownName>

Jody, the proposal was implemented so that the syntax above is used only for external graphics
(where we don't have space to embed a Expression) but not for WellKnownName, where a
regular expression can be used.

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

-------------------------------------------------------

On Tue, Mar 4, 2014 at 5:10 PM, Nuno Oliveira <
nuno-miguel-oliveira@anonymised.com> wrote:

Thanks Jody and Aime for the explanations, I will proceed with the pull
request.

By the way ( I know and understand the need to follow with the standards
but, ) when we have a big SLD with complex "business" based on scales,
request attributes , properties ... we often end up with an SLD that have a
lot of boilerplate code and vendor options that makes him very difficult to
maintain and is very error-prone.

The function mechanism is nice but requires implementing some Java code
and the XML can become very bad ...

Does Geoserver have any intention to improve the SLD dynamics mechanisms ?

"GeoServer" has no intentions of its own, it really depends on what funding
becomes available
(and people with funds most of the time have a very specific idea of how
they should be used)
and to a much more modest extend, to what the developers feel like doing on
a Sunday

It would be nice to have some more powerful scripting support like SpEL or
Groovy for example.

(
http://docs.spring.io/spring/docs/4.0.3.BUILD-SNAPSHOT/spring-framework-reference/htmlsingle/#expressions
)

You can look into CSS for a more compact styling language (
http://docs.geoserver.org/latest/en/user/extensions/css/index.html)
and GeoScript modules in order to implement your filter functions in a
scripting language

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

-------------------------------------------------------

On Tue, Mar 4, 2014 at 4:26 PM, Andrea Aime <andrea.aime@anonymised.com>wrote:

On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett <jody.garnett@anonymised.com>wrote:

The proposal[1] documents the use of ${ cql expression} so your original
example would be:

<sld:WellKnownName>${strToUpperCase('shape')}</sld:WellKnownName>

Jody, the proposal was implemented so that the syntax above is used only
for external graphics
(where we don't have space to embed a Expression) but not for
WellKnownName, where a
regular expression can be used.

Hum nope, checked the code, it should also actually be able to handle the
syntax you have
proposed above, I just never used it since implementing it.

So we have two possible ways to implement the translaction back to SLD,
personally I'd
still prefer the one using an OGC expression, it's more in line with the
rest of the
SLD, the ${cqlExpression} thing was created only to deal with the
impossibilty
of writing a full OGC expression in the external graphics url

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

-------------------------------------------------------

Hi,

I just made the pull request for this: https://github.com/geotools/geotools/pull/385

Since we use a lot of other functions in our SLD I keep the OGC expression syntax, it seems more "compatible".

By the way, I test the CQL syntax and all seems to work fine ... if I forgot something to make it compatible let me know.

Thanks for your feedback.

Best regards,

Nuno Oliveira

On 03/04/2014 04:58 PM, Andrea Aime wrote:

On Tue, Mar 4, 2014 at 4:26 PM, Andrea Aime <andrea.aime@anonymised.com <mailto:andrea.aime@anonymised.com>> wrote:

    On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett
    <jody.garnett@anonymised.com <mailto:jody.garnett@anonymised.com>> wrote:

        The proposal[1] documents the use of ${ cql expression} so
        your original example would be:

        <sld:WellKnownName>${strToUpperCase('shape')}</sld:WellKnownName>

    Jody, the proposal was implemented so that the syntax above is
    used only for external graphics
     (where we don't have space to embed a Expression) but not for
    WellKnownName, where a
    regular expression can be used.

Hum nope, checked the code, it should also actually be able to handle the syntax you have
proposed above, I just never used it since implementing it.

So we have two possible ways to implement the translaction back to SLD, personally I'd
still prefer the one using an OGC expression, it's more in line with the rest of the
SLD, the ${cqlExpression} thing was created only to deal with the impossibilty
of writing a full OGC expression in the external graphics url

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

-------------------------------------------------------

Thanks Nuno:

Created an Jira issue: https://jira.codehaus.org/browse/GEOT-4726

And have applied the fix to master, 11.x and 10.x

···

Jody Garnett

On Thu, Mar 6, 2014 at 1:28 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I just made the pull request for this: https://github.com/geotools/geotools/pull/385

Since we use a lot of other functions in our SLD I keep the OGC expression syntax, it seems more “compatible”.

By the way, I test the CQL syntax and all seems to work fine … if I forgot something to make it compatible let me know.

Thanks for your feedback.

Best regards,

Nuno Oliveira

On 03/04/2014 04:58 PM, Andrea Aime wrote:

On Tue, Mar 4, 2014 at 4:26 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hum nope, checked the code, it should also actually be able to handle the syntax you have
proposed above, I just never used it since implementing it.

So we have two possible ways to implement the translaction back to SLD, personally I’d
still prefer the one using an OGC expression, it’s more in line with the rest of the
SLD, the ${cqlExpression} thing was created only to deal with the impossibilty
of writing a full OGC expression in the external graphics url

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


On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The proposal[1] documents the use of ${ cql expression} so your original example would be:

sld:WellKnownName${strToUpperCase(‘shape’)}</sld:WellKnownName>

Jody, the proposal was implemented so that the syntax above is used only for external graphics
(where we don’t have space to embed a Expression) but not for WellKnownName, where a
regular expression can be used.

Hi Jody,

Thanks.

Related to the contribution agreement, I have only signed the geoserver one when I contribute the W3DS module.

Since I pretend to become more active in the geoserver\geotools stack (and have other things that maybe interesting to contribute)
I definitively should sign the contribution agreement.

I found this page http://docs.codehaus.org/display/GEOTOOLS/Replace+Contribution+Agreement

Is this the right one: http://docs.geotools.org/latest/developer/procedures/contribution_license.html ?

Best regards,

Nuno Oliveira

On 03/05/2014 11:46 PM, Jody Garnett wrote:

Thanks Nuno:

Created an Jira issue: https://jira.codehaus.org/browse/GEOT-4726

And have applied the fix to master, 11.x and 10.x

Jody Garnett

On Thu, Mar 6, 2014 at 1:28 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com <mailto:nuno-miguel-oliveira@anonymised.com>> wrote:

    Hi,

    I just made the pull request for this:
    https://github.com/geotools/geotools/pull/385

    Since we use a lot of other functions in our SLD I keep the OGC
    expression syntax, it seems more "compatible".

    By the way, I test the CQL syntax and all seems to work fine ...
    if I forgot something to make it compatible let me know.

    Thanks for your feedback.

    Best regards,

    Nuno Oliveira

    On 03/04/2014 04:58 PM, Andrea Aime wrote:

    On Tue, Mar 4, 2014 at 4:26 PM, Andrea Aime
    <andrea.aime@anonymised.com
    <mailto:andrea.aime@anonymised.com>> wrote:

        On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett
        <jody.garnett@anonymised.com <mailto:jody.garnett@anonymised.com>> wrote:

            The proposal[1] documents the use of ${ cql expression}
            so your original example would be:

            <sld:WellKnownName>${strToUpperCase('shape')}</sld:WellKnownName>

        Jody, the proposal was implemented so that the syntax above
        is used only for external graphics
         (where we don't have space to embed a Expression) but not
        for WellKnownName, where a
        regular expression can be used.

    Hum nope, checked the code, it should also actually be able to
    handle the syntax you have
    proposed above, I just never used it since implementing it.

    So we have two possible ways to implement the translaction back
    to SLD, personally I'd
    still prefer the one using an OGC expression, it's more in line
    with the rest of the
    SLD, the ${cqlExpression} thing was created only to deal with the
    impossibilty
    of writing a full OGC expression in the external graphics url

    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 <tel:%2B39%200584%20962313>
    fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
    mob: +39 339 8844549 <tel:%2B39%20%C2%A0339%208844549>

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

    -------------------------------------------------------

That is the one! It should be a lot easier to follow then last time (and you can just email it in). Do keep in mind there is one to bounce off your employer as well.

···

Jody Garnett

On Fri, Mar 7, 2014 at 9:28 PM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi Jody,

Thanks.

Related to the contribution agreement, I have only signed the geoserver one when I contribute the W3DS module.

Since I pretend to become more active in the geoserver\geotools stack (and have other things that maybe interesting to contribute)
I definitively should sign the contribution agreement.

I found this page http://docs.codehaus.org/display/GEOTOOLS/Replace+Contribution+Agreement

Is this the right one: http://docs.geotools.org/latest/developer/procedures/contribution_license.html ?

Best regards,

Nuno Oliveira

On 03/05/2014 11:46 PM, Jody Garnett wrote:

Thanks Nuno:

Created an Jira issue: https://jira.codehaus.org/browse/GEOT-4726

And have applied the fix to master, 11.x and 10.x

Jody Garnett

On Thu, Mar 6, 2014 at 1:28 AM, Nuno Oliveira <nuno-miguel-oliveira@anonymised.com> wrote:

Hi,

I just made the pull request for this: https://github.com/geotools/geotools/pull/385

Since we use a lot of other functions in our SLD I keep the OGC expression syntax, it seems more “compatible”.

By the way, I test the CQL syntax and all seems to work fine … if I forgot something to make it compatible let me know.

Thanks for your feedback.

Best regards,

Nuno Oliveira

On 03/04/2014 04:58 PM, Andrea Aime wrote:

On Tue, Mar 4, 2014 at 4:26 PM, Andrea Aime <andrea.aime@anonymised.com.> wrote:

Hum nope, checked the code, it should also actually be able to handle the syntax you have
proposed above, I just never used it since implementing it.

So we have two possible ways to implement the translaction back to SLD, personally I’d
still prefer the one using an OGC expression, it’s more in line with the rest of the
SLD, the ${cqlExpression} thing was created only to deal with the impossibilty
of writing a full OGC expression in the external graphics url

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


On Tue, Mar 4, 2014 at 3:59 PM, Jody Garnett <jody.garnett@anonymised.com…> wrote:

The proposal[1] documents the use of ${ cql expression} so your original example would be:

sld:WellKnownName${strToUpperCase(‘shape’)}</sld:WellKnownName>

Jody, the proposal was implemented so that the syntax above is used only for external graphics
(where we don’t have space to embed a Expression) but not for WellKnownName, where a
regular expression can be used.