Placeholder areas

[lucaswoj]

From @kkaefer on January 20, 2017 15:1

I'm proposing to introduce placeholder areas: Annotations are currently located in a layer that is above all other layers, meaning that annotations will always cover existing features, such as labels. Similarly, when adding new layers, you'll have to explicitly name an existing layer as the beforeLayerID parameter to have the layer inserted below that layer.

Placeholder areas would be named regions within a style that can be referenced when inserting new layers, or adding annotations (i.e. every placeholder area would have its own annotation layer). An example JSON excerpt would look like this:

"layers": [
  // background layer
  // water layer
  {
    "area": "landmass"
  },
  // ... other layers ...
  {
    "area": "overlay"
  },
  // ... label layers ...
]

We'd have to establish some convention for style authors to follow, but it'll help the common case of a user inserting some annotations that cover up the labels.

There might be some way we could reuse Studio metadata (which has layer groups) to accomplish this as well.

/cc @lucaswoj @kronick @jfirebaugh @1ec5 @tmcw

Copied from original issue: mapbox/mapbox-gl-style-spec#658

[lucaswoj]

From @1ec5 on January 20, 2017 16:37

Annotations are specific to the native SDKs are aren't mentioned in this specification. Could the native SDKs (or mbgl) address the problem of inserting layers above annotations (but not the broader idea of placeholder areas) by keeping track of the bottommost annotation layer and always inserting before it?

[lucaswoj]

From @1ec5 on January 20, 2017 16:40

Note that the automatically added point annotation layer is already used as a placeholder of sorts for view-backed annotations that are (due to platform limitations) always rendered atop the entire map, regardless of any layers that may sit above the point annotation layer in the style.

[lucaswoj]

From @andrewharvey on January 25, 2017 4:30

This could be useful in the GL JS context as well to put client side layers (such as annotations; basically extra layers in the application code not from the Studio Style) below the labels from the Style. With the default Mapbox styles, this usually means for Streets a beforeLayer of housenum-label and for Satellite Streets a beforeLayer of waterway-label (event though ferry-label is lower).

What about a "placeholder" layer type. So you could for example add an annotation placeholder layer to your Style then do beforeLayer annotation?

[lucaswoj]

From @1ec5 on January 25, 2017 6:44

Since a style JSON file is expected to be platform-agnostic, it shouldn’t assume support for a platform-specific feature – annotations in this case, but the canvas layer type added in mapbox/mapbox-gl-style-spec#656 is problematic for the same reason.

A no-op “divider” layer could be useful for a developer to cede control over the exact z-ordering of a runtime-inserted layer to their style designer. At runtime, the developer would insert above or below the divider (doesn’t matter which) without replacing the divider. However, I don’t think the SDK could rely on the designer to add a dedicated placeholder or divider layer for something like annotations that has to work in every style (even a barren style with no layers or sources).

[lucaswoj]

From @jfirebaugh on January 26, 2017 21:34

Previously: mapbox/mapbox-gl-styles#34, mapbox/mapbox-gl-styles#258.

[tmpsantos]

This is a very nice thing to have and we need something like this on the Qt SDK. When adding native views to a style, specially route lines, you often want it to be under the labels. The SDK could query for a specific mark and if it exists, add the layer before it, otherwise on top of the topmost layer.

Having a standard mark for where the labels start in the Mapbox official styles would be helpful. I would name this layer mark in the spirit of #pragma mark.

Studio could implement the groups with a start and end mark:

{
    "id": "road-labels-start",
    "type": "mark"
},
{
    "id": "road-label-small",
    "type": "symbol"
},
{
    "id": "road-label",
    "type": "symbol"
},
{
    "id": "road-labels-end",
    "type": "mark"
},

[anandthakker]

Noting that "nested styles" is an alternative design that addresses partially overlapping concerns.