Editable deck layers approach

[romaxa]

I'm exploring an option to make Deck layers editable with mouse interaction.

The general approach is to handle mouse/pointer down/move/up on the layer feature and update geometry of picked feature during mouse move.

The current implementation of deck mouse handler (onLayerHover) is blocking mouse events on the feature here: https://github.com/uber/deck.gl/blob/master/modules/core/src/lib/deck.js#L527

I see couple of options to make deck layers editable:

• Expose mouse events with button pressed in deck, so external users can handle generic mouse events up/move/down to implement whatever they want
• Create Editable layer which simply connects to deck canvas and provide these generic event callbacks, and extend all deck layers from that class. Event listeners should be attached only when callback is set in layer props. (similar to what EditableGeoJsonLayer does but in more generic way)
• No deck/layers changes, just do everything on client-side, like extend existing deck layer class, override initialize/finalize state methods, and implement event listeners there.

@ibgreen @georgios-uber @supersonicclay thoughts?

[georgios-uber]

Nebula provides an Editable Layer that does exactly that.

We plan to refactor to use mjolnir which will work even better.

Are you familiar with nebula edit modes? You can use editable geojson layer and create your own modes for use cases not currently covered.

[georgios-uber]

similar to what EditableGeoJsonLayer does but in more generic way

Actually: class EditableGeoJsonLayer extends EditableLayer

[romaxa]

Yes, I was looking at EditableGeoJsonLayer and EditableLayer, Idea here is to make other layers editable, like ScatterPlot, PathMarkerLayer e.t.c, so question what whould be the standard approach to make these segments editable, without duplicating events handling code again and again

[ibgreen]

Just some thoughts:

First let me say that I like the current setup where editing is handled by nebula.gl, would prefer not build this into deck, it is already big and complex enough.

And it may be tricky to make every layer editable (what would an editable Tile3DLayer even do?).

Next, we should ask ourselves: How would a "generic" editing system work?

• Most deck.gl layers work against a "table" of data.
• That table can be a JS array, where each row is an object, but it can also be a binary columnar table.
• Perhaps designing an generic editing solution that can update rows in tables of different types, and then some mapping for each layer from geometric space to data indices.
• that mapping could be done by nebula.gl. It may require unique sublayers of each layer, or just a CompositeLayer that renders the sublayers and handles their data tables.

[supersonicclay]

The vision with nebula.gl has always been to provide editability atop deck.gl and provide editable versions of deck.gl layers that make sense. So far, we have GeoJSON. But there's also a desire to have editable h3 cells as well (where you are painting or filling in polygons with h3 hexagons).

[ibgreen]

But there's also a desire to have editable h3 cells as well (where you are painting or filling in polygons with h3 hexagons).

This is a neat idea. Maybe we should create a ROADMAP or RFC doc collecting ideas for how to make other layers editable?

[romaxa]

And it may be tricky to make every layer editable (what would an editable Tile3DLayer even do?).

Tile3DLayer - can be extended from editable layer in a generic way, let say you want to draw something on top of it or generate another layer based on mouse events coming with a mouse button press. We don't need to enable event handling on all deck layers by default if callback is not provided.

The vision with nebula.gl has always been to provide editability atop deck.gl and provide editable...

Probably this is the right approach, and whenever folks willing to get another deck layer editable, they will add one more to nebula repository for others.

In general, I was thinking to extend existing layers from very generic Editable layer which will be silent if edit abilities are not requested. Based on generic events which are very close to just browser events, clients could build whatever behavior and the move common functionality to nebula or so.

RFC, or roadmap would be nice too, so we have a single source of truth with explanations about an editable approach of deck layers

[ibgreen]

I was thinking to extend existing layers from very generic Editable layer which will be silent if edit abilities are not requested.

I see the appeal of this idea, so I need to explain why I am (rather strongly) opposed:

There are a lot of feature extensions we want to do to all layers, not just editing. Making all layers inherit from a base layer, while reasonable from the perspective of each of these features, means we are pushing all this upstream into deck.gl.

I'd rather build generic mechanisms that allows nebula to inject what it needs into existing layers.

For shaders we already developed an extension system so that additional features can be plugged in without adding more to the base layers.

That system most likely can't be used for this purpose but illustrates that we have ways to architect this in a flexible way that shares code and that does not involve adding new base layers.

[ibgreen]

Apologies for this abstract feedback.

My 2 cents: let's focus on what we want to make editable and how that editing should work and we'll come up with a design that satisfies your concerns.

Implementing a few more examples of editable layers would likely be very helpful as one usually starts to see the patterns after about three examples. Once we see the patterns we can generalize the design and settle on the architecture.

So an editable H3 layer, and an other layer like scatterplot layer, point cloud or arc layer where one can edit positions?

[romaxa]

Ok, so my simple solution looks something like this:

export class EditablePointLayer extends ScatterplotLayer {
  onFeatureEvent(event: FeatureEvent) {
    this.props.onFeatureEvent(picks, sourceEvent, groundCoords);
  }
  initializeState() {
    super.initializeState();
    this.setState({ ...this.state, _layerHandler: new EditableLayerHandler(this) });
  }
  finalizeState() {
    super.finalizeState();
    this.state._layerHandler.finalizeState();
  }
  updateState(state) {
    super.updateState(state);
    this.state._layerHandler.updateState();
  }
}

Where EditableLayerHandler - just contains events listener logic, similar to nebula editable layer Does it make sense?

[supersonicclay]

I would encourage you to look further into how EditableLayer, EditableGeoJsonLayer, and EditMode work together in nebula.gl.

There is already a DrawPointMode in nebula.gl along with many other GeoJSON-based editing modes. The edit-modes module is setup so that additional edit modes can be implemented without having to change EditableGeoJsonLayer. Consuming applications can even define their own custom mode in their own application code without having to put that mode into nebula.gl.