Visualize altitude along PathLayer

[demiantres]

I want to visualize altitude data along a PathLayer. As far as I can see all data structures have to be updated to use 3D points instead of 2D points (and of course the shader has to be updated) so that the z-coordinate can hold the elevation.

Is this correct, or is there already some implementation offering such functionality?

[devemux86]

Map library provides the API to display line overlays on the map (which is 2D).

To display different colors per elevation, you can use custom data structures and paint differently the segments of the line.

[demiantres]

Thanks for your reply.

Line drawing includes pre-processing such as simplification and clipping which means that the elevation data has to go through these steps as well so that it keeps referenced to the correct 2D point. My idea was to use a 3D point (z-axis is the elevation information) which should also work well with the JTS functions (JTS Coordinate supports a z-component). The tile clipper, geometry buffer, and many other classes have to be updated from 2D to 3D point data structure.

Or did you mean something else with "custom data structures and paint differently the segments of the line"?

[devemux86]

Let's not complicate things and keep the map library and custom app implementations separate.

Map library provides the API to display line overlays on the map (which is 2D).

So the intended function is already served fine.
Everything else is custom app implementation.

Elevation is only 1 of the many custom values that a path could have.
It could be speed, surface, etc. Too many values and far more than 3.

To paint differently the line segments based on whatever extra value,
split the path in segments and paint them based on the custom value.

[demiantres]

Let's not complicate things and keep the map library and custom app implementations separate.

My question is not a feature request but I am trying to understand the best way how to do this and how I can write an extension for this task.

Splitting the path into segments is not a solution because each point can potentially have a different value. The trivial approach would be to store the other data (elevation, speed, ...) in a separate buffer. The challenge here is to correctly access/update this additional buffer after clipping and path simplification. Do you have an idea how this could be achieved?

[demiantres]

I think you can mark the thread as answered. I implemented another drawing type "LINE_EXT" which handles a 3rd coordinate. As expected TileClipper, LineClipper, Lin(Tex)BucketRenderer, and GeometryBuffer had to be adapted for this.