Deck.gl: New Layer: Floating Solid Polygon

[chrisgervang]

Background

Sometimes I'd like to define 3D polygons floating in space.

For example, I might want to draw an extruded disk polygon that is 25km diameter, just under 4km high, centered around a random point (say, 38.8977° N, 77.0365° W) and floating a few km above the ground.

With the current SolidPolygonLayer, I can achieve all of this except for the floating bit since the "base vertices" are always set to 0, and the layer is built around the notion of lat/lng/height rather than lat/lng/floor/ceiling (shown below).

This behavior is implemented here:
https://github.com/uber/deck.gl/blob/cf9a4da6d0d70db9e0fd91c1f04af67df9da757e/src/core-layers/solid-polygon-layer/polygon-tesselator-extruded.js#L158

---

I propose a new experimental FloatingSolidPolygonLayer that is very similar to SolidPolygonLayer, with the following API differences:

+ getFloor: (polygonIndex) => void    // get the altitude of the bottom surface
+ getCeiling: (polygonIndex) => void  // get the altitude of the top surface
- getHeight: (polygonIndex) => void   // replaced by getCeiling
- extruded: boolean                   // every usage of this layer includes extrusion

These new props may be used to set start and end altitude shared by every lat/lng in a polygon, mimicking the behavior of getHeight (shown below).

Additionally, I propose adding support for 4 dimension vertex data type (up from 2 dimensions) in order to get the fine grained Z control over each vertex.
(and for feature parity, also add 3 dimension support to SolidPolygonLayer)
The change would be:

// Current vertex data type
[lng, lat], where height is always set by getHeight

// Floating Solid Polygon vertex data type
[lng, lat, floor, ceiling], with a fallback to getFloor and getCeiling if floor or ceiling are undefined, respectively.

// for parity, change Solid Polygon data type
[lng, lat, height], with a fallback to getHeight if height is undefined.

Note that all of the functions needed from polygon.js already support higher dimension data types, but the layers themselves need modifications to add this capability.

This new data type allows the user to decide the altitude(s) for every lat/lng in their polygons. Shown below, I selected random values in a range as a quick example.

This experimental layer enables a variety of previously unsupported use cases, like 3D airspace regions and floating geometries. It does so without adding complexity or any breaking API changes to the existing SolidPolygonLayer. This proposal also enables finer grained control over altitude, while preserving backwards compatibility. I've prepared an implementation, and added an example to the layer-browser. Open to suggestions, and I'm excited to know what you all think 😸

To Do List

• [ ] Add label and assign to milestone
• [ ] Coding
• [ ] Doc update
• [ ] Whats new update
• [ ] Test

[chrisgervang]

For clarity, a data set is constructed like:

type Polygon = [lng, lat, floor, ceil][]
// Where polygon's inside polygons are "cut out".
type FloatingPolygonData = Polyon[][]

// standard single polygon
const vertex1 = [lnt, lat, floor, ceil]
const polygon1 = [vertex1, vertex2, ...]
const complexPolygon = [polygon1, polygon1hole, ...]
const data = [complexPolygon]

[ibgreen]

@chrisgervang

Very cool! Yes, a new set of 3D layers is likely the way to go, at least initially.

The reason is taht full 3D support can lead to a very long tail of features, so to control the scope for the initial data vis focused layer catalog, we took a firm decision on the initial set of layers that they should be 2.5D, or "extruded" only.

This layer could be part of a "true" 3D layer catalog. Other layers that would fit is the current PointCloudLayer and the (unpublished) MeshLayer, so we have a decent starting point.

We have an experimental-layers folder, you are welcome to open a PR of your branch towards that folder.

Also, just making sure you are aware of the modelMatrix prop, using this you can "float" a layer. There is a separation slider in the layer browser where this can be tested.

@georgios-uber FYI

[chrisgervang]

This layer could be part of a "true" 3D layer catalog.

Yes! Almost everything we're doing is 3D, so I'll likely be contributing other layers for this catalog over time.

We have an experimental-layers folder, you are welcome to open a PR of your branch towards that folder.

Thanks! Will do.

modelMatrix prop

Oh! I didn't know about this. I notice that for the SolidPolygonLater though, the Z changes depending on my zoom level... I might need a crash course on this from someone in order to know how to use it properly (this is a totally new concept to me). I'd want the Z to stay constant.

[ibgreen]

The Z changes depending on my zoom level...

Ha, didn't realize that. modelMatrix is mostly use in METER_OFFSETS mode. If there is interest, we could firm up the interpretation of it in LNGLAT mode.

[danmarshall]

Hello, I'm looking for similar functionality for polygons floating space.

I propose a new experimental FloatingSolidPolygonLayer that is very similar to SolidPolygonLayer, with the following API differences:

• getFloor: (polygonIndex) => void // get the altitude of the bottom surface
• getCeiling: (polygonIndex) => void // get the altitude of the top surface
• getHeight: (polygonIndex) => void // replaced by getCeiling
• extruded: boolean // every usage of this layer includes extrusion

These new props may be used to set start and end altitude shared by every lat/lng in a polygon, mimicking the behavior of getHeight (shown below).

However, I'm not looking for the additional functionality of

adding support for 4 dimension vertex data type (up from 2 dimensions) in order to get the fine grained Z control over each vertex.

Does it make sense to just add a base property to SolidPolygonLayer?

[Pessimistress]

@danmarshall you can set the "floor" by adding a z component to your polygon coordinates:
https://codepen.io/Pessimistress/pen/MGGEYK