We have a layer with +- 350K records and the point features are rendered
based on 2 attributes: 1 has 10 distinct values and defines the symbol
(mark), the other one has 12 distinct values and defines the color.
Now we have 1 big SLD with +- 3200 lines and because of its size the SLD is
hard to maintain. That's why we want to change and are looking for
alternatives. I tested already 2 alternatives: using recode function and
storing symbol + color in spatial table. Both have its pros and cons. But
maybe there are a few others.
In an ideal world using this SLD (or SLDs) it's possible to:
- render the features correctly (of course)
- render features which are unknown with a specific rendition (similar to
the ElseIf rule)
- create different legends: 1 based on symbol, the other one on color
(because a legend with 120 different items - as with our current SLD - is
not really clarifying)
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/SLD-Best-practices-tp5067939.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Hi Roel,
I’ve never used it myself, but perhaps the CSS module (soon to be extension maybe) will let you do what you want. It seems to be more terse than the very-verbose SLD files.
http://docs.geoserver.org/stable/en/user/extensions/css/index.html?highlight=css
Jonathan
On 22 July 2013 12:13, Roel De Nijs <roel.denijs@anonymised.com> wrote:
We have a layer with ± 350K records and the point features are rendered
based on 2 attributes: 1 has 10 distinct values and defines the symbol
(mark), the other one has 12 distinct values and defines the color.
Now we have 1 big SLD with ± 3200 lines and because of its size the SLD is
hard to maintain. That’s why we want to change and are looking for
alternatives. I tested already 2 alternatives: using recode function and
storing symbol + color in spatial table. Both have its pros and cons. But
maybe there are a few others.
In an ideal world using this SLD (or SLDs) it’s possible to:
- render the features correctly (of course)
- render features which are unknown with a specific rendition (similar to
the ElseIf rule)
- create different legends: 1 based on symbol, the other one on color
(because a legend with 120 different items - as with our current SLD - is
not really clarifying)
–
View this message in context: http://osgeo-org.1560.x6.nabble.com/SLD-Best-practices-tp5067939.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.
On Mon, Jul 22, 2013 at 1:13 PM, Roel De Nijs <roel.denijs@anonymised.com>wrote:
We have a layer with +- 350K records and the point features are rendered
based on 2 attributes: 1 has 10 distinct values and defines the symbol
(mark), the other one has 12 distinct values and defines the color.
Now we have 1 big SLD with +- 3200 lines and because of its size the SLD is
hard to maintain. That's why we want to change and are looking for
alternatives. I tested already 2 alternatives: using recode function and
storing symbol + color in spatial table. Both have its pros and cons. But
maybe there are a few others.
In an ideal world using this SLD (or SLDs) it's possible to:
- render the features correctly (of course)
- render features which are unknown with a specific rendition (similar to
the ElseIf rule)
- create different legends: 1 based on symbol, the other one on color
(because a legend with 120 different items - as with our current SLD - is
not really clarifying)
I don't think there is any solution that satisfies the third requirement.
Not without
developing new features in the legend bulding code at least.
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
-------------------------------------------------------
Jonathan Moules-2 wrote
I've never used it myself, but perhaps the CSS module (soon to be
extension
maybe) will let you do what you want. It seems to be more terse than the
very-verbose SLD files.
http://docs.geoserver.org/stable/en/user/extensions/css/index.html?highlight=css
Great alternative for the (indeed) very verbose SLD files! If we decide to
stick to creating rules for every combination, using the css module will
definitely result in serious decrease of lines and thus better
maintainability.
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/SLD-Best-practices-tp5067939p5068012.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
geowolf wrote
I don't think there is any solution that satisfies the third requirement.
Not without
developing new features in the legend bulding code at least.
The third requirement is just a nice to have. We'll settle for any solution
which has a better maintainability than a very large SLD file.
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/SLD-Best-practices-tp5067939p5068017.html
Sent from the GeoServer - User mailing list archive at Nabble.com.