Design proposal: Add elevation to symbol layer

[HarelM]

This still needs a bit more refinement, but the general idea is that a symbol layer should be allowed to be presented above the ground, this isn't only for when terrain is on but should also be applied when extrusion is shows to show markers, icons, and text above the ground.

The original request was described here: https://github.com/maplibre/maplibre-gl-js/issues/644

Since this is somewhat related to 3D visualization I think it can be linked to the following bounty: https://github.com/maplibre/maplibre/issues/189 Once this is refined and approved we can split this into specific issues and assigned bounties.

[ovivoda]

TSC meeting on April 12 notes:

Action points:

• Please add comments in the above issue and we can discuss this further in the next meeting
• There’s a need to better define how this would look like in the style-spec, if this is something someone would like to push forward, please do so.

[pietervdvn]

For MapComplete, this would be really great to have - e.g. if a POI is located at a higher floor (or to do indoor maps).

I see two approaches for this:

• Include the 'height' in the geojson-coordinates, e.g. {"type": "Point", "location": [51.1,3.1,2]}
• Define the height as a layout property.

My first instinct is that using the coordinate from the geojson would be the most versatile (but I have not experimented with this)

[lseelenbinder]

Another potentially use for this is using a raster-dem source to elevate labels (potentially with additional exaggeration) and also render lines from labels -> ground points (extruded or not), similar to how you'd show a mountain range in relief form.

I think limiting this to only GeoJSON sources would be too limiting.

[HarelM]

In maplibre-gl-js geojson is converted to mvt which doesn't have elevation, so this proposal is less about adding elevation to geometries and more about adding a field in the spec

[cns-solutions-admin]

Having an attribute would work for points, but it wouldn't for lines. Thus it would be better to support 3D coordinates:

• In the stale 5 year old branch for a MVT 3.0 (https://github.com/mapbox/vector-tile-spec/blob/v3.0-3d/3.0/vector_tile.proto) a dimensions attribute was added to the tile. The spec though (https://github.com/mapbox/vector-tile-spec/blob/v3.0-3d/3.0/README.md) still only mentions 2D for the moveto/lineto commands. However, maplibre could internally support such a dimensions = 3 parameter and then read 3 parameters for each point.
• alternatively, internally maplibre could support additional commands moveto3d/lineto3d (currently only moveto/lineto/closepath - 1/2/7 of possible 8 values - are specified), which would currently only be generated when converting a 3d geojson for rendering

As mapbox currently seems to ignore all 3D point/line issues (e.g. https://github.com/mapbox/vector-tile-spec/issues/111) this could be a major feature of maplibre.

[HarelM]

We are actively working on the next vector tiles format, but it will take time... Search for COM and COVTiles.

[andrewharvey]

We are actively working on the next vector tiles format, but it will take time... Search for COM and COVTiles.

Wow didn't know about these, super impressive.

Google wasn't working for me but I did eventually find the repos:

https://github.com/mactrem/com-tiles https://github.com/mactrem/cov-tiles