M-value storage thoughts

[nyurik]

I have been thinking further about the M-values storage. One aspect of that storage is that if a tile geometry shares certain verticies or segments, it should be possible (but not required!) to share those extra M values too. For example, if that M value is the elevation or lane width, and two different geometry features share a segment, it should be possible for both segments to share both of those extra values too. At the same time, even if a geometry segment is shared, some M values may be required to be specific per-feature rather than per vertix.

[mactrem]

Good point. When a vertex dictionary based on ICE encoding is used, this must be taken into account. One M-value per vertex offset must be supported.

Whether the elevation should be encoded generically as an additional M-value basically also depends on whether the elevation should be part of the rendering in the future or only used as an attribute for example for analytic use cases, styling or things like displaying in a pop-up/on hover, etc.
If in the future 3D rendering of the geometries of a vector tile should be supported in MapLibre, a Array of structures approach with interleaved x,y,z values would be more performant as they are processed in one place. @nyurik Whats the primary usage of the elevation in the future in MapLibre in your opinion?

[nyurik]

I'm not an expert in this. There are multiple aspects:

Hillshading

Hillshading was done by @prozessor13 in maplibre/maplibre-gl-js#1022 (initially implemented in maplibre/maplibre-gl-js#165) - and to my understanding (i haven't worked with it), it uses PNG images to indicate per-pixel elevation
. See demo

Simple 3D elements

At the moment, MapLibre does not support any kind of data coming from the z axis of the data sources AFIK. Technically geojson could have 3d data, but I am not aware of any way of using it in drawing / as part of the styling language. Note that maplibre styling does allow one 3d feature -- fill-extrusion - this is commonly used to make 3D buildings by computing their height from the floor count, but this is not the same as visualizing elevation data. cc: @HarelM

True 3D

I am not sure this would be part of this spec, but instead should use one of the existing 3D model data format which will be either stored separately or as a binary blob inside the tile.

[nyurik]

P.S. Ideally it should be possible to have multiple M values per segment of the geometry (i.e. M would be a tuple)

[HarelM]

Current MVT format doesn't have z, geojson is converted to MVT and this information is lost.
This is the current implementation ATM.

Having said that, the following is an interesting discussion about next gen js API:
mapbox/vector-tile-js#79

It doesn't aim to solve some of the things highlighted here, but I think we should understand the current pain points and the extent of what it means to replace the underlying tile data model.