[Geoserver-devel] [JIRA] (GEOS-7094) CSS z-index for line rendering works inconsistently

GeoServer GeoServer Developer
1

Jonathan Ball created an issue

GeoServer / BugGEOS-7094

CSS z-index for line rendering works inconsistently

Issue Type:

BugBug

Affects Versions:

2.7.1.1

Assignee:

Unassigned

Components:

CSS

Created:

30/Jun/15 1:14 PM

Environment:

Windows 64, Geoserver WAR running in Tomcat 7

Priority:

MediumMedium

Reporter:

Jonathan Ball

Let’s say I have a road with casings as follows:

    /* yellow road with a grey casing*/
    [type = 'Road']{
      stroke: #888888, #f8f8ba;
      stroke-width: 10, 8;
      stroke-linejoin: round;
      stroke-linecap: round;
      z-index: 0, 1;
    }

This works as expected. Now, let’s add another road as follows:

    /* yellow road with a grey casing*/
    [type = 'secondary']{
      stroke: #888888, #f8f8ba;
      stroke-width: 10, 8;
      stroke-linejoin: round;
      stroke-linecap: round;
      z-index: 0, 1;
    }
    /* green road with a black casing*/
    [type = 'trunk' ]{
      stroke: #000000, #94d494;
      stroke-width: 10, 8;
      stroke-linecap: round;
      stroke-linejoin: round;
      z-index: 10, 11; 
    }

This draws the trunk roads on top of the secondary roads, also as expected. So far so good. But let’s suppose we have lots of roads and want the more major roads always on top. So we have the following code:

    /* yellow road with a grey casing*/
    [type = 'secondary']{
      stroke: #888888, #f8f8ba;
      stroke-width: 10, 8;
      stroke-linejoin: round;
      stroke-linecap: round;
      z-index: 10, 11;
    }
    /* green road with a black casing*/
    [type = 'trunk' ]{
      stroke: #000000, #94d494;
      stroke-width: 10, 8;
      stroke-linecap: round;
      stroke-linejoin: round;
      z-index: 20, 21; 
    }

This time, it is the secondary roads that are drawn on top despite having a lower z-index (10 < 20: FAIL). This is inconsistent with previous example (0 < 10: CORRECT). So, let’s take it a bit further. If I make the Z-indexes of the secondary roads 20 & 21 and raise the trunk roads z-indexes to 30 & 31, then we are back to correct rendering order (trunk on top). Go one step further and make secondary roads 30 & 31 and trunk 40 and 41 and we return to a FAIL. Again, testing with extreme z-indexes of 10,11 vs 100,101 fails but 20,1 vs 200,201 renders correctly.

So, in conclusion, z-index works sometimes and fails other times and is not solely dependent on the relative size of the indexes. The documentation does not specify any limit and I don’t know if that is what I am experiencing, though why values in the hundres do sometimes work, suggests that this is not the case. If there is a low limit on z-indexes, it is very handy to be able to use large values (>>0-9) because you can then use the units to order parts of a feature (e.g. roads with casings) and the tens or hundreds to order types of feature (so in my use-case tertiary roads are 10-19, secondary 20-29, primary 30-39 and so on).

Add Comment

Add Comment

This message was sent by Atlassian JIRA (v6.5-OD-07-005#65007-sha1:7561251)

Atlassian logo