deck.gl philosophy: basic layer types + styling

[ibesora]

Looking at the deck.gl v8.4 release notes I saw that some helper functions were added to @deckgl/carto but unfortunately they only work on Carto*Layers which require a Carto account. Now, I can understand Carto's point of view on limiting that to their own layers but it would be awesome if we could use something that's not a Carto SQL sentence to populate those layers.

Having said that, in a more general sense, wouldn't it be great if deck.gl had something like the nice CARTOFrames data-driven styling options? You can create a choropleth map with automatic binning with just 2 lines of code
That brings up the question of why isn't there more basic layers that work automagically, like a choropleth one, instead of having the user compute all the binning, etc.

What's the rationale about not having them? Is this not the right project for something like this? Would that be a welcomed contribution to the project?

[Clebal]

Hello @ibesora, CARTO helper functions can be used in any layer. If you have data that it isn't GeoJSON you can use the attr as a function.

Here you can see an example:

import {PolygonLayer} from '@deck.gl/layers';
import {colorBins} from '@deck.gl/carto';

    new PolygonLayer({
      id: "polygon-layer",
      data: [
        {
          contour: [
            [-122.4, 37.7],
            [-122.4, 37.8],
            [-122.5, 37.8],
            [-122.5, 37.7],
            [-122.4, 37.7]
          ],
          population: 100
        },
        {
          contour: [
            [-123.45, 37.73],
            [-123.47, 37.76],
            [-123.47, 37.71],
            [-123.45, 37.73]
          ],
          population: 10000
        }
      ],
      pickable: true,
      stroked: true,
      filled: true,
      wireframe: true,
      lineWidthMinPixels: 1,
      getPolygon: (d) => d.contour,
      getFillColor: colorBins({
        attr: d => d.population,
        domain: [200, 500],
        colors: 'Temps'
      }),
      getLineColor: [80, 80, 80],
      getLineWidth: 1
    })

[ibgreen]

What's the rationale about not having them? Is this not the right project for something like this? Would that be a welcomed contribution to the project?

The rationale for keeping these in the carto module is that adding such features to a big complex API requires quite a bit of thought, styling could be done in several ways. The leads decided that for the initial version we would let carto iterate on these helpers in their module and as we get some experience we might consider moving these, or some evolution of them, into the core.

I don't think we have tech lead bandwidth at the moment to make immediate decisions on this, but as @Clebal said you can still use these functions in the general layers.

[Pessimistress]

To build on @ibgreen's comment - the deck.gl core and layer catalog are designed to be generic and flexible. In the future we want to keep them atomic and not opinionated towards one particular syntax/dependency, so that they remain as performant as possible. Meanwhile, we have considered and are working towards one or more new, standalone packages that offer convenient utilities similar to the CARTO styling functions. These will be especially useful when deck.gl is used with non-JavaScript bindings such as pydeck.

[ibesora]

Thanks for your input @Clebal and @ibgreen .
It's great those work on other layers, their documentation being under @deckgl/carto made me think they only worked on those.

Another question: Looking at the differences between the CARTOFrames data-driven styling and the current usage of the helper functions, you now need to be explicit on the domain of the colorBins, colorCategories and colorContinuous while in CARTOFrames you don't need to. Is that need to be more explicit something that deck.gl endorses? That goes hand in hand with having more layers that involve less work like a choropleth one.

By the way @Clebal, congratulate everyone involved in bringing the helper functions to deck.gl

[VictorVelarde]

CARTOFrames data-driven styling is based on transparent metadata calculations (mostly stats / samples that allow the use of different classifiers for the colors / sizes: quantiles, standardDeviation...).

That metadata and how/when to calculate it is very tied to the type of 'source' you are using. In general terms, it could be either calculated once for the whole dataset client-side (if it's something like a geojson), or with different methods if bigger / chunked datasets like MVT tiles are used (server-side stats for static tiles, client-side calculations just for the tiles in the viewport...). IMO to apply a similar approach here for any type of layer, more thought would be required around that metadata calculation