Hi,
Is it possible to parameterize ColorMapEntry in a style. I want to be able to
pass in different values for "quantity" when I request a raster layer. The value
for quantity will be used to calculated quantity values for each of the
ColorMapEntrys.
Thanks!
I don’t think this is possible at the moment. The problem is that the quantity value is supplied by an attribute, rather than a sub-element (where it would be possible to allow a filter expression instead of a fixed value.
The ColorMapEntry element is actually a bit of an anomaly in SLD - most parameters in other styling elements are supplied as element content, rather than attributes. A nice extension for GeoServer would be to allow CQL expressions in attribute values in SLD.
On Mon, Jan 7, 2013 at 3:48 AM, Ramkumar Nagabhushanam <ramkumar2@anonymised.com> wrote:
Hi,
Is it possible to parameterize ColorMapEntry in a style. I want to be able to
pass in different values for “quantity” when I request a raster layer. The value
for quantity will be used to calculated quantity values for each of the
ColorMapEntrys.Thanks!
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only – learn more at:
http://p.sf.net/sfu/learnmore_122412
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
–
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Mon, Jan 7, 2013 at 6:57 PM, Martin Davis <mdavis@anonymised.com> wrote:
I don’t think this is possible at the moment. The problem is that the quantity value is supplied by an attribute, rather than a sub-element (where it would be possible to allow a filter expression instead of a fixed value.
The ColorMapEntry element is actually a bit of an anomaly in SLD - most parameters in other styling elements are supplied as element content, rather than attributes. A nice extension for GeoServer would be to allow CQL expressions in attribute values in SLD.
Hmm… let’s say the reason for the usage of the attribute is not so difficult to imagine, rasters have
no “attributes”, so theoretically there would be nothing to write an expression against, standard wise.
GeoServer has the env function though, that one would indeed be usable as a source of values for
the color map
Cheers
Andrea
–
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
Agreed. I was mostly thinking of the ability to be able to use the “env” function - I should have said that explicitly.
It seemed like the cleanest, most general way of providing access to “env” was to allow CQL expressions (especially since there might well be the need to perform some further computation on the “env” value to adapt it to the quantity required for any particular band).
On Mon, Jan 7, 2013 at 10:31 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Mon, Jan 7, 2013 at 6:57 PM, Martin Davis <mdavis@anonymised.com> wrote:
I don’t think this is possible at the moment. The problem is that the quantity value is supplied by an attribute, rather than a sub-element (where it would be possible to allow a filter expression instead of a fixed value.
The ColorMapEntry element is actually a bit of an anomaly in SLD - most parameters in other styling elements are supplied as element content, rather than attributes. A nice extension for GeoServer would be to allow CQL expressions in attribute values in SLD.
Hmm… let’s say the reason for the usage of the attribute is not so difficult to imagine, rasters have
no “attributes”, so theoretically there would be nothing to write an expression against, standard wise.GeoServer has the env function though, that one would indeed be usable as a source of values for
the color mapCheers
Andrea–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.Ing. Andrea Aime
@geowolf
Technical LeadGeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Mon, Jan 7, 2013 at 8:27 PM, Martin Davis <mdavis@anonymised.com> wrote:
Agreed. I was mostly thinking of the ability to be able to use the “env” function - I should have said that explicitly.
It seemed like the cleanest, most general way of providing access to “env” was to allow CQL expressions (especially since there might well be the need to perform some further computation on the “env” value to adapt it to the quantity required for any particular band).
Ah, I see what you mean. Yes, it is consistent with what we already did for “dynamic symbolizers”, where
portions of CQL expressions can be included in the external graphic location attribute:
http://blog.geoserver.org/2008/12/08/dynamic-symbolizers-part-1/
For the raster symbolizer it could be something like:
and the parser could recognize that the value is starting from ${ and parse it as a cql expression.
Or maybe not even use it ${, check if the value is the expected literal type, if not, parse it as a CQL
expression.
That said… someone needs to write the code for this 
Cheers
Andrea
–
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