Skip to content
This repository has been archived by the owner on Jan 12, 2024. It is now read-only.

Specificity and z-ordering #247

Open
ajashton opened this issue Feb 1, 2013 · 17 comments · Fixed by #277
Open

Specificity and z-ordering #247

ajashton opened this issue Feb 1, 2013 · 17 comments · Fixed by #277
Labels

Comments

@ajashton
Copy link
Member

ajashton commented Feb 1, 2013

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
Copy link

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
Copy link
Contributor

tmcw commented Mar 28, 2013

@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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

tmcw commented Apr 30, 2013

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

@springmeyer
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

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:

screen shot 2013-05-22 at 7 27 49 pm

@springmeyer
Copy link

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
Copy link

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

@springmeyer springmeyer mentioned this issue Jun 1, 2013
@springmeyer
Copy link

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
Copy link

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
Copy link

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

@springmeyer springmeyer reopened this Jun 14, 2013
@springmeyer
Copy link

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
Copy link
Contributor

Possibly related issue: #284

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants