Layer metadata handling via UI

[aparlato]

Based on request from downstream client:

There are scenarios for us where we want the ability within a tool to turn specific style layers on and off (and potentially other interactivity down the line) in a style. Maperture could be a good home for this barring really specific editor requests/needs.

Right now this is possible in Maperture via the experimental PR for injecting custom JS, however it might be worth considering a spec for more defined handling as the custom JS injection is a bit of an advanced feature and catchall in lieu of a defined spec.

My thought is that we could define a metadata structure for layers in a stylesheet that Maperture could interpret into controllable UI. This way users can add appropriate metadata to their stylesheet and Maperture will just work with it.

Below are some thoughts on how this might be structured. All the following options use a very limited control that could be rendered as radio buttons or a similar UI.

Minimal:

We define a series of pretty specific functions allowed through metadata that are layer specific. In this case, type: visibility means that layer has some kind of toggle to turn on and off.

Example: Layer visibility

// poi layer
metadata: {
  layerControl: {
    // Allow a UI label different from the layer id to be passed
    label: 'POIs',
    // Would always be interpreted as on/off switch for layer
    type: 'visibility'
  }
}

More specific functionality:

We allow user to pass option values for any given property on a layer's metadata. This is similar to the above except that users can specify properties and values more specifically.

Example: Layer visibility

// poi layer
metadata: {
  layerControl: {
    // Allow a UI label different from the layer id to be passed
    label: 'POIs',
    // Property to target
    property: [ 'layout', 'visibility' ],
    // Palette of values that could be offered. These could also be expressions
    values: [ { name: 'on', value: 'visible' }, { name: 'off', value: 'none' } ],
  }
}

Example: Color change

// landuse layer
metadata: {
  layerControl: {
    // Allow a UI label different from the layer id to be passed
    label: 'POIs',
    // Property to target
    property: [ 'paint', 'fill-color' ],
    // Palette of values that could be offered. These could also be expressions
    values: [ { name: 'Red hospital', value: [ [ '==', [ 'get', 'class' ], 'hospital' ], 'red', 'green' ] }, { name: 'None', value: 'green' } ],
  }
}

Grouping layers

In this scenario, we would define a control at the top level and relevant style layers' metadata would reference the appropriate control and values that should be passed for the allowed options.

Example: Multiple layer visibility

// style top level meta
metadata: {
    layerControl: {
      all-pois-visibility {
           // Allow a UI label different from the layer id to be passed
           label: 'All POIs',
          // Options to match in the layers
          options: [ 'on', 'off']
      }
  }
}

...
// restaurant poi layer
metadata: {
  layerControl: {
    // Match id to top level control
    id: 'all-pois-visibility',
    // Property to target
    property: [ 'layout', 'visibility' ],
    // Palette of values that could be offered. These could also be expressions
    values: [ { name: 'on', value: 'visible' }, { name: 'off', value: 'none' } ],
  }
},
...
// health poi layer
metadata: {
  layerControl: {
    // Match id to top level control
    id: 'all-pois-visibility',
    // Property to target
    property: [ 'layout', 'visibility' ],
    // Palette of values that could be offered. These could also be expressions
    values: [ { name: 'on', value: 'visible' }, { name: 'off', value: 'none' } ],
  }
}

For discussion

Is this worthwhile to implement or would this be better served by a separate editor-like tool? I think if the functionality had to expand beyond a set of defined options, then Maperture would definitely not be the right place for this.

Additionally, the way Maperture is structured, it is difficult to persist these options when changing the number of maps and would dramatically increase the URL length to persist across re-loads. This would require some thought into what the desired behavior here is and how we would achieve that.

The need to have potentially extensive metadata on the stylesheet could definitely extend the length/size of the file, but our hope is that this would be used minimally. In our case internally, we could strip this metadata as needed on serving styles, and we would put a similar onus on users who choose to use this feature and care about file size.

cc @ebrelsford for thoughts!

[ebrelsford]

I generally like this and would support us implementing a simple version of it.

Do we know if there are existing metadata schemes around that do anything like this?

or would this be better served by a separate editor-like tool?

It seems useful enough to be able to (following your example) have two maps open, one with POIs on and one with POIs off, to justify keeping this in Maperture.

it is difficult to persist these options when changing the number of maps and would dramatically increase the URL length to persist across re-loads

Agreed, and similar to what I said above I do think it's important to persist this state in the URL so you can share exactly what you're looking at with someone else.

Finally I wonder if you've thought about what the UI for this will look like in Maperture?