Group symbolizer parse and render

[hollinger]

This adds functionality for parsing and rendering group symbolizer (mapnik/mapnik#2160). The goal is to be able to create group symbolizers in Carto CSS. The basic attributes are covered in mapnik/mapnik-reference#61. The changes here are focused on the ability to match child rules to a group symbolizer and render them as xml content within the parent group symbolizer along with a group layout.

A group symbolizer contains child rules, which operate much like other style rules. The idea is that multiple sets of data columns in a single feature can be independently matched against the same set of child style rules. For example, the primary use case for which I currently use group symbolizer is dual road shields. Matching two sets of columns against the rules within the group symbolizer can produce any combination of two shields. These two shields are then arranged in a "group" and placed on the feature geometry.

The implementation proposed in this pull request addresses how child rules are defined for a given group symbolizer. A group symbolizer can be assigned a name and multiple class names, much like a data layer. The name and class is used to select style information from the mss files, also like a layer.

For example, you could specify:

.road-shields {
  ...
}
.us-shields {
  ...
}
#roads {
   group-class: 'road-shields us-shields';
   ...
}

The above would create a group symbolizer in the roads style that contains style rules created from road-shields and us-shields styles. Those rules would be used to style the individual shields in the group before placing the group along the geometry of the road itself.

See https://github.com/mapnik/mapnik/wiki/GroupSymbolizer for more information on group symbolizer.

[springmeyer]

can you clarify how does this relates to #347?

[hollinger]

This does not have a direct relation to #347. Group symbolizer is a separate feature.

[1ec5]

GroupSymbolizer support in Carto would be awesome! Personally, though, I find it more natural to express each GroupRule as an instance rather than tying disparate rules together with group-class. For example:

#roads-text-ref {
  [highway = 'motorway'][zoom >= 13] {
    group-start-column: 1;
    group-num-columns: 6;
    group-placement: line;
    group-spacing: 750;
    group-min-distance: 30;

    shield/shield-size: 10;
    shield/shield-fill: #fff;
    shield/shield-face-name: @bold-fonts;
    shield/shield-name: "[ref%]";
    shield/shield-file: url("symbols/mot_shield[length%].png");
  }
  …
}

Or would that syntax be too restrictive? I have a proof of concept that only supports SimpleLayout but could easily be extended to support other layouts with an additional (non-instance) property.

[springmeyer]

@1ec5 - wow, just seeing this: I like the simplicity of your syntax. Would you be able to rebase your branch with latest carto master so we could easily try this out?

Or would that syntax be too restrictive?

@hollinger - do you have thoughts?

[hollinger]

@1ec5 @springmeyer I like the instance syntax idea, as it is simpler to define group rules this way. The thing that is missing here is the ability to define a filter for each individual group rule, which is rather important to what group symbolizer was designed for.

The output xml structure could be something like:

<GroupSymbolizer ... >
   <GroupRule>
      <Filter>[type%] = 1</Filter>
      ...
   <GroupRule>
   <GroupRule>
      <Filter>[type%] = 2</Filter>
      ...
   <GroupRule>
   ...
</GroupSymbolizer>

Could this be incorporated in the instance syntax somehow?

[springmeyer]

@hollinger - awesome thanks for the comments. Btw I'm taking a look at updating mapnik/mapnik#2549 now too.

The thing that is missing here is the ability to define a filter for each individual group rule, which is rather important to what group symbolizer was designed for.

Oh, wow, totally missed that feature.

What about?

shield/group-filter:"[type%] = 2";

That would not be very CSS like but this is also a crazy advanced feature so keeping it to a property:value keeps things simple.

[pnorman]

@springmeyer Someone from Mapbox might need to adopt this and do anything that's missing, since I don't think @hollinger is working on any map rendering stuff right now, and the Maps team at MQ doesn't exist anymore

[1ec5]

My bad, I derailed this discussion by proposing an alternative but didn't follow through with a PR. Sorry about that. I need to dig back in and figure out how to adapt @hollinger's tests to my proposal.