Add getCoverage accessor to ColumnLayer

[felixpalmer]

For #7333

Change List

• Add getCoverage in place of coverage prop
• Deprecate coverage prop
• Render tests
• Doc update

[Pessimistress]

We never use accessors for multipliers. It's counter intuitive given that coverage is a percentage. Why not add a getRadius instead?

[felixpalmer]

Why not add a getRadius instead?

How would this work with H3HexagonLayer? This has no getRadius/radius prop so the only way to achieve a varying size for the columns is by using coverage

[ibgreen]

We never use accessors for multipliers. It's counter intuitive given that coverage is a percentage. Why not add a getRadius instead?

I don't really have an opinion on that statement, but I can offer a few WebGPU observations:

• Today we split our layer props into props that map to uniforms (same value for all rows) and props that map to accessors (unique value for each row).
• Since WebGL allows the app to set a constant value for attributes, any "attribute prop" can effectively be used as a uniform prop, but not the reverse.
• However, in WebGPU, there is no support for constant attribute values, so we may need to regenerate the layer shaders based on which attributes are constant.
• If so, we might as well support that flexibility for any property, and drop the division of props we have today.

[Pessimistress]

How would this work with H3HexagonLayer?

H3 hexes have a defined geo boundary, which we should never arbitrarily offset from. Besides, the layer only renders ColumnLayer sometimes, and PolygonLayer in regions containing pentagons/multiple zones. How are you defining "coverage" for polygons?

[felixpalmer]

@ibgreen thanks, interesting input - I think we should discuss this as part of the broader WebGPU migration

@Pessimistress yes the PolygonLayer special would have to be handled differently. I tried changing ColumnLayer.getCoverage in order to have a 1-to-1 mapping with H3HexagonLayer.

How about this approach:

• ColumnLayer adds getRadius instead of radius
• H3HexagonLayer adds getCoverage instead of coverage. When rendering its sublayers:
  • H3HexagonLayer.getCoverage is used to calculate getRadius in the ColumnLayer case
  • H3HexagonLayer.getCoverage is used in h3ToPolygon() to calculate getPolygon in the PolygonLayer case

H3 hexes have a defined geo boundary, which we should never arbitrarily offset from.

I don't understand this comment. If we shouldn't offset from the true H3 boundary, why is there a coverage prop at all?

[Pessimistress]

If we shouldn't offset from the true H3 boundary, why is there a coverage prop at all?

Good question. Maybe we should remove it since it doesn't work in the high-precision (polygon) case...

[felixpalmer]

coverage does work with high-precision case: https://github.com/visgl/deck.gl/blob/master/modules/geo-layers/src/h3-layers/h3-hexagon-layer.ts#L71

I think that having coverage/getCoverage on H3HexagonLayer is a valid prop, even if the resulting H3 polygons do not match the H3 indexing system. The purpose of the prop is for visual styling, e.g. to emphasize certain hexagons or to make it easier to see the boundary between the hexes