Specificity and z-ordering

[ajashton]

So attachment order is determined by definition order:

#layer::a { // renders below }
#layer::b { // renders above }

...unless one attachment has more 'specificity' than the other(s):

#layer::a[zoom>=0] { // renders above }
#layer::b { // renders below }

Two issues with this: it feels like unexpected behavior to the user, and the only way to work around it is by equaling out the specificity (which is hacky and not even always possible). I would love if specificity didn't work this way, but having an explicit z-index option (#237) would be workable.

Thoughts?

[migurski]

Explicit z-index feels correct to me here. The behavior of attachments is foreign to CSS, whose closest features are the :before and :after pseudo-elements. Specificity should continue to work the way it does; it’s not immediately intuitive but it’s stable and predictable once you grok what’s going on. I don’t believe that render order derived from position in the stylesheet has this same benefit.

[tmcw]

@migurski see #237 for the more in-depth discussion - I think AJ's suggestion is solid though I'm not sure what to do about mixing this explicit order with the implied order that's already there.

[migurski]

Once you add z-index, it seems like you’d want to extend the Mapnik core to actually re-order features coming out of a datasource. You’ve already started mixing content & style, might as well follow through on the implications. This would require Carto to be a first-class replacement for the XML rather than a preprocessor. AJ’s reservations expressed in the comment on #237 largely come from the difficulty of expressing this all in XML, so it should be ditched.

Sample use-case: buildings with z_order properties that can be rendered above or below nearby roads to faithfully represent case like overpass-covers-building vs. building-covers-tunnel, despite having two separate data layers.

Anecdotally I’ve encountered bugs like #268 in Carto on a frequent basis, but that’s the first one I reported. I usually work around them by writing ~2x more Carto CSS than I would Cascadenik CSS and fix the problem by over-specifying. They feel like a result of mixing the attachment/instance concepts into a style language that’s not suited for expressing content edits or layer-level properties (e.g. #249), and the bugs emerge from the stresses placed on the underlying Layer/Style/Symbolizer/Feature loop.

Search your feelings, you know it to be true.

[migurski]

Thinking about this a little more (I’m on a train!) I see parallels with GL’s depth buffer, which performs depth sorting at the last possible moment before rendering to pixels. In my work on Python-based datasources, I’m finding that setting an attachment in Carto causes layer datasources to be evaluated twice, which in my case results in twice the network fetching overhead.

Pulling all features from all Datasources could happen once, up-front, before looping through styles and symbolizers. Layers could provide one source of depth hint, just as element in order in HTML does, with z-index and attachment order providing another.

[springmeyer]

This behavior looks like a regression in latest carto. I tracked this ticket down just now because I'm noticing this behavior for the first time in my actual usage. In TileMill 0.10.1 this css renders labels on top (as I would expect) while in the dev build of TileMill I'm testing with (v0.10.1-59-g338d40a) the labels are rendered underneath the polygons.

[tmcw]

@springmeyer any luck maybe using git bisect to nail down the specific regression commit?

[springmeyer]

Tom, I will tackle this but not tried to narrow down yet. Will do asap.

On Apr 30, 2013, at 10:30 AM, Tom MacWright [email protected] wrote:

@springmeyer any luck maybe using git bisect to nail down the specific regression commit?

—
Reply to this email directly or view it on GitHub.

[gravitystorm]

I've run into the same issue. git bisect shows that it's 4d4abb2 that introduced the switching.

Simple testcase that I've been using:

#countries {
  ::outline {
    line-color: #85c5d3;
    line-width: 4;
    line-join: round;
    //[ne_10m_adm = 'AAA'] { line-color: red; }
  }
  ::inline {
    line-color: black;
    line-width: 1;
  }
}

Uncomment the ne_10m_adm filter, and the order of attachments switches, from that revision onwards.

[springmeyer]

awesome thanks for the help narrowing in @gravitystorm. Either Tom or I will try to track this down. I'm busy with Mapnik release atm, but this is on my mind. @gravitystorm - also, fyi: mapnik/mapnik#1859

[springmeyer]

happened to just be testing tilemill/carto master and see that this issue is likely the cause of the inverted road casings in the open-streets-dc sample project:

[springmeyer]

I have confirmed the git bisect of @gravitystorm - this was definitely broken in 4d4abb2. I've added (currently failing) tests now that enforce the old behavior of style/attachment order than is independent to the # of rules in the style

[springmeyer]

pull request fixing this at #277. Hoping @tmcw can take the lead on reviewing and merging it if seems wise.

[springmeyer]

So, overall:

1. This original issue is a regression in the still unreleased/dev code of carto/tilemill - specificity should not change the order of attachments (aka Mapnik styles).
2. After this is fixed, we should discuss mid-term solutions to make ordering of attachments easier to control as discussed in Add z-index #237
3. @migurski's comments above seem critical to potential new features or flexibility for mapnik, and are much more actionable with vector tiles that contain all possible data for layers in memory (can make resorting feasible and refetching for multiple passes much less expensive). @migurski - would you be up for creating a ticket at mapnik's github site summarizing what you'd love to see?

[springmeyer]

noticing that the openstreets-dc stylesheet is still not rendering correctly with latest carto/tilemill/mapnik - looks like like it did before this fix: #247 (comment)

[springmeyer]

re-opening, not convinced this is fixed fully or that the problem is fully understood.

[springmeyer]

these are the relevant changes between carto v0.9.3 and master: https://gist.github.com/springmeyer/5784466

Studying them now to try to reduce a testcase.

[yohanboniface]

Possibly related issue: #284