[Geoserver-users] SLD drawing order

Hi GS Friends,

i have an SLD File with more as 10 rules.

My Problem is that geoserver ignored the order of drawing. I thought the reading of SLD is from bottom to top?

Nope, it’s loading the data one feature at a time and apply all the rules on each feature in order:
that is, load feature1, apply r1, r2, r3… load feature2, apply r1, r2, …

If you want them to be z-ordered instead you will have to use multiple feature type styles, each one
having a separate rule. Mind, don’t overuse that, GeoServer will still read features just once
and create N drawing surfaces to paint the different feature type styles, meaning you’re multiplying
your memory requirements by the number of FTS you’re using

See this example in the SLD cookbook:
http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/lines.html#line-with-border

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

cmaul · May 3, 2012, 11:50pm

Stephan,

SLDs should be written that one and only one rule applies a a given scale.
This would render the order of execution meaningless. It would be your duty
to shape the SLD in a way that firstly you do not omit data that you want to
display and secondly that you make the filter mutually exclusive. So all
your 'teilmassnahmeart' values that you want to display need to be in only
one rule at one scale.

Sorry, xml is verbose, and using tags for everything and no attributes
there is little you can do.
Another tip as you seem to have very large SLDs: At around 200K the
evaluation of the SLD fails with a SAX error. If you hit this limit you can
squeeze out a little bit more space by avoiding indents in your xml. This
was with Geoserver 2.0.1. I didn't run into this problem with Geoserver
2.1.3 but it dont't expect that to have changed.

-----
____________________________

Dr Christian Maul
Project Manager

Information Services Branch
Department of Sustainability and Environment
Level13, Marland House, 570 Bourke Street
Melbourne 3000

PO Box 500, East Melbourne Vic 3002

Telephone: +61-3-8636 2325
Telefax: +61-3-8636 2813
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p4950810.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Tom_Christian · May 4, 2012, 12:12am

Unfortunately it's not always practical to aim for exactly one rule applying
at any scale. For example a roads layer will usually show highways and
residential roads at the same scale.

In my WMS roads layer all road features are contained in a single Shapefile
with an attribute indicating road type, so I style them all using a single
SLD. I want highways to show on top of residential roads so I do need to
worry about z-ordering.

In some cases I only want to show one type of road but I want something like
a thick green line with a slightly thicker grey line behind it to provide an
outline. Again, this requires multiple rules at the same scale and makes
z-ordering important.

Given the number of different types of roads it is not practical (and
presumably bad for performance) to break them out into different layers and
different SLDs.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p4950831.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

cmaul · May 4, 2012, 2:08am

Thomas,

yes agree but this is what you should aim for. What is the sense in using a
standard like SLD and then shooting holes in it by writing the styles in a
fashion that depends on execution?
They should work in Geoserver, deegree, mapserver etc. A lot of my styles
are not self-written, but swapped with other open-source users. That is the
advantage and productivity of standards.
Relying on conventions is always dangerous.
It is the same with our roads, which are in 12 different classes. That
applied to 6 scale-dependent rules would give 72 rules.
As the layers are drawn bottom up, I usually use layergroups to enforce
that.
Nobody prevents you from calling the same layer with a different style in a
layer group or a generalized layer at higher and the real one at lower
scales. At least that is what I think these groups are for: divide and
conquer.

Cheers

Christian

-----
____________________________

Dr Christian Maul
Project Manager

Information Services Branch
Department of Sustainability and Environment
Level13, Marland House, 570 Bourke Street
Melbourne 3000

PO Box 500, East Melbourne Vic 3002

Telephone: +61-3-8636 2325
Telefax: +61-3-8636 2813
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p4950991.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Tom_Christian · May 22, 2012, 7:02pm

Christian, I feel we're approaching an 'agree to disagree', but I'm curious -
where are the guidelines suggesting that SLDs should only contain one active
style at any scale?

The specification permits multiple FeatureTypeStyle elements for a good
reason - so that you can have multiple 'layers' within the resulting image
and you can control how they are positioned relative to each other. From the
specification (1.1.0):

"Note that there is no restriction against a single UserStyle from including
multiple FeatureTypeStyles that reference the same FeatureTypeName. This
case does not create an exception in the rendering semantics, however, since
a map styler is expected to process all FeatureTypeStyles in the order that
they appear, regardless, plotting one instance over top of another"

This suggests that using FeatureTypeStyle elements to control ordering is in
fact part of the standard. The specification even highlights the importance
of execution order. Given that I can find no mention of a one active style
restriction I assume that this approach is, in fact, convention.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p4976193.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Martin_Davis · May 22, 2012, 7:57pm

I’d have to agree with cheesybiscuits on this… The SLD/SE spec explicitly allows for both multiply FeatureTypeStyles and multiple Rules to apply to any given feature being rendered. (See SE 1.1 section 10.3:

Filters used in different Rules applicable to the same FeatureTypeStyle are allowed to overlap in terms of the features selected by each rule.

However, using multiple Rules per feature in a single FeatureTypeStyle may not produce the results intended, since all the rules for a feature are rendered before the next feature is drawn. If the desire is to produce something like “cased roads”, then multiple FeatureTypeStyles should be used instead, since this will avoid later features from overwriting earlier ones (which tends to produce odd-looking line joins).

On Tue, May 22, 2012 at 12:02 PM, cheesybiscuits <thomaschristian@anonymised.com> wrote:

Christian, I feel we’re approaching an ‘agree to disagree’, but I’m curious -
where are the guidelines suggesting that SLDs should only contain one active
style at any scale?

The specification permits multiple FeatureTypeStyle elements for a good
reason - so that you can have multiple ‘layers’ within the resulting image
and you can control how they are positioned relative to each other. From the
specification (1.1.0):

“Note that there is no restriction against a single UserStyle from including
multiple FeatureTypeStyles that reference the same FeatureTypeName. This
case does not create an exception in the rendering semantics, however, since
a map styler is expected to process all FeatureTypeStyles in the order that
they appear, regardless, plotting one instance over top of another”

This suggests that using FeatureTypeStyle elements to control ordering is in
fact part of the standard. The specification even highlights the importance
of execution order. Given that I can find no mention of a one active style
restriction I assume that this approach is, in fact, convention.

–
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p4976193.html

Sent from the GeoServer - User mailing list archive at Nabble.com.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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.

Christian_Weithoeft · September 14, 2012, 10:01am

Hi Christian

From another Christian on the other side of the world.

Could you please elaborate a little on this. Being new to GeoServer I'm
struggling to understand and use all the different aspects of layers, layer
groups and styles.

My task is to display different layers dependent on scale. Example could be
cost-lines with different level of details used for different scales. Layer
for 1:1.000.000 has fewer details than the corresponding layer for 1:50.000
and so on.

On the other hand I want to use the same style for the feature independent
of scale. And I don't want to have to maintain the same style in a lot of
different SLD's. (it always goes wrong at some point in maintenance,
forgetting one in the update process)

How can Layer group help me or rather can I use layer group to select the
"correct" layer for display dependent on scale.

The data are placed in a Oracle Spatial database. The data is presently in
use in an MapInfo based web tool. And from design data has been split into
separate tables for each feature/scale combination.

I have the option of joining the data in one table and add a label to
indicate which scale data is meant to describe. The data are not very
dynamic, so data maintenance is a smaller issue.

Regards

Christian Weithoeft / Dashsoft
Software developer / mapping and GIS
Aarhus
Denmark
mail to: christian@anonymised.com
web: www.dashsoft.dk

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p5001912.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Martin_Davis · September 19, 2012, 6:09pm

If the goals are:

maintain only one copy of the styling for a given feature type
display different versions of a feature depending on scale

then perhaps you could merge all feature versions of the same feature type into a single table, with an attribute indicating the appropriate scale, and then render that layer with a single SLD.

Since the scale is indicated by an attribute, the standard SLD Min/MaxScaleDenominator elements can’t be used, because they are static. Instead, use a rule filter based on the current scale, as provided by the “wms_scale_denominator” environment variable [1]. is one way to express this, or else use the “between” function.

This also allows having just a single copy of the styling for a feature, applied at all desired scales (the rule filter can AND the valid scale range conditions for a particular styling together).

[1] http://docs.geoserver.org/stable/en/user/styling/sld-extensions/substitution.html#predefined-variables

On Fri, Sep 14, 2012 at 3:01 AM, Christian Weithoeft <christian@anonymised.com> wrote:

Hi Christian

From another Christian on the other side of the world.

Could you please elaborate a little on this. Being new to GeoServer I’m
struggling to understand and use all the different aspects of layers, layer
groups and styles.

My task is to display different layers dependent on scale. Example could be
cost-lines with different level of details used for different scales. Layer
for 1:1.000.000 has fewer details than the corresponding layer for 1:50.000
and so on.

On the other hand I want to use the same style for the feature independent
of scale. And I don’t want to have to maintain the same style in a lot of
different SLD’s. (it always goes wrong at some point in maintenance,
forgetting one in the update process)

How can Layer group help me or rather can I use layer group to select the
“correct” layer for display dependent on scale.

The data are placed in a Oracle Spatial database. The data is presently in
use in an MapInfo based web tool. And from design data has been split into
separate tables for each feature/scale combination.

I have the option of joining the data in one table and add a label to
indicate which scale data is meant to describe. The data are not very
dynamic, so data maintenance is a smaller issue.

–

Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

cmaul · September 25, 2012, 1:32am

Hi Christian,

Sorry for answering so late, it escaped me.
There was a difference in approach. Cheesybiscuits and Martin rightfully
pointed out what the standard allows for. However, my position was: ’you
need to find a sensible way to deal with your spatial infrastructure and
that might not include everything you can do’. So, theirs was a technical,
mine an organisational view.

Things get complicated by itself, as Martin demonstrated with his
road-casing example. So, I want to keep it as simple as possible. There are
cases where you cannot. But going back to your problem, there are a few
thoughts how I would approach things. If you write everything in one sld,
you have the advantage of a single source of truth, but the problem is that
you need to do regression testing in case something changes. If you change
the design for one layer, you must answer the question: does this
label/filter/pattern/whatever also work for the other layer it is applied
to? So, you may opt to separate them.

The simple length of a sld is a point of consideration for me as well.

The possible re-use by others is also a point of consideration for me.
Obviously this is easier if the style is simpler. Well, there is an offset,
the style has to be complicated enough to save you work, i.e. not trivial
and general enough to be applied with little re-work. So, it is about
balance.

A very simple and similar problem to yours: We have a layer ‘bushfire prone
areas’, which was derived from a 10m grid and as a consequence is highly
complicated and slow to load. For that reason there is another generalised
layer from 50K upwards. The sld’s are called
SCHEMA_layername_authorShorthand_number.sld and in two files. The two layers
are called using a layergroup. Good about that is: there is only one layer
to test with one sld. Bad is: if I change the colour I must not forget the
other sld. There is also the issue of metadata. Both layers are an
expression of the same data, so there is only one metadata record, which is
connected to the layergroup and displayed. I don’t show the single layers.

The layer group cannot help you to select the ‘correct’ layer at a
particular scale, only the filter (in the sld) can do that. If you have one
or more attributes you can use for filtering (in my case road_type and
road_classes come to mind --
http://docs.geoserver.org/stable/en/user/styling/sld-reference/filters.html
http://www.opengeospatial.org/standards/filter ) then use it or them to chop
up your dataset and if there is none, it may be sensible to create a
variable. Filters and their syntax are worth knowing because even if you do
not use them in SLDs, you will use them in WFS. I love Martin’s example with
the variable, haven’t tried that.
Layergroups, however, can encapsulate the logic, which different layers or
parts of the same layer are assembled as a spatial feature class that you
want as and is shown as one unit. That includes, which layers are on top of
the others.

Whatever you choose to do, follow it through and spend some time and think
about naming conventions of your layers, slds and groups or use something
like svn to administer your slds and versions of them.

With these things there is no right or wrong. It seems I am for the simple
things, you are not. If you’re (unlike me) highly organised then go for the
complicated structures. That is the beauty of Geoserver that it gives you
the choice. However, you do not want to sit in front of your own work when
revisiting stuff thinking: ‘what the hell did I think, when I did this and
why did I do it this way?’

I think, that is a position ‘cheesybiscuits’ and Martin can wholeheartedly
agree to.

Cheers

Christian

-----
____________________________

Dr Christian Maul
Project Manager

Information Services Branch
Department of Sustainability and Environment
Level13, Marland House, 570 Bourke Street
Melbourne 3000

PO Box 500, East Melbourne Vic 3002

Telephone: +61-3-8636 2325
Telefax: +61-3-8636 2813
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/SLD-drawing-order-tp4948595p5004147.html
Sent from the GeoServer - User mailing list archive at Nabble.com.