Dynamic & Static Colored Elevation
Currently the colored elevation option allows only static coloring based on (pre)defined .cpt files. This approach has various drawbacks.
A new approach with the following options would be much better:
- user can choose between two coloring modes. Static range: user defines min max elevation. Dynamic range: coloring is dynamically applied based on min max elevation values currently on screen.
- user can customize style by defining a simple color map/palette (wich is much easier to create or find online).
What do you think of this new approach?
Technically I think it's possible. I already programmed a little python script that interpolates color palettes based on min-max elevation ranges and creates custom .cpt files for it. In this comment @Menion says that dynamic coloring would require a completely new system. Any idea why this would be so hard?
I like this idea 
Hello Martin,
I was thinking about it a little more and ...
Currently Locus Map apply coloring when preparing map tiles for the first time. Coloring is drawn directly over final version of the map tile, so directly on the bitmap itself, so no further changes are possible without loading a map tile again. Also map tile does not need to know anything about other map tiles so it may immediately interpolate elevations and draw coloring/shading.
Your request means that after every movement of the map, the app needs to:
This is quite a lot of work and mainly a lot of changes. Currently app does not keep in memory any extra data. All is just used and thrown away. Memory is precious on Android and there is no space to keep to much data at once. This complicates the whole system a lot.
I'm not saying it is not doable, but it needs to change the current "static + use and forget" system to this new "dynamic + use and keep in memory" and this really is a lot of work.
I'm not directly declining this idea, because after maybe 3-4 years, memory won't be a problem at all and this will be quite an easy task /if there still be and interest). But for the years 2022/2023, this definitely does not fit into the plan.
Thanks for understanding.
Hello Martin,
I was thinking about it a little more and ...
Currently Locus Map apply coloring when preparing map tiles for the first time. Coloring is drawn directly over final version of the map tile, so directly on the bitmap itself, so no further changes are possible without loading a map tile again. Also map tile does not need to know anything about other map tiles so it may immediately interpolate elevations and draw coloring/shading.
Your request means that after every movement of the map, the app needs to:
This is quite a lot of work and mainly a lot of changes. Currently app does not keep in memory any extra data. All is just used and thrown away. Memory is precious on Android and there is no space to keep to much data at once. This complicates the whole system a lot.
I'm not saying it is not doable, but it needs to change the current "static + use and forget" system to this new "dynamic + use and keep in memory" and this really is a lot of work.
I'm not directly declining this idea, because after maybe 3-4 years, memory won't be a problem at all and this will be quite an easy task /if there still be and interest). But for the years 2022/2023, this definitely does not fit into the plan.
Thanks for understanding.
Helle Menion,
I very much appreciate your responsive and elaborate answer! I now have a better understanding of how the coloring is done internally and I wouldn't want a feature that is so costly for you to implement and for the system to process.
Now I get it where the problem lies and why an implementation for dynamic coloring would require lots of memory and processing ‒ because some tiles are reused when moving the viewport and changing the elevation-color value pairs would mean they couldn't be reused and would have to be redrawn so all tiles use the same consistent color values and thus display smooth gradients across all visible tiles.
What to do instead?
1) It seems that only the dynamic elevation coloring is the challenging part but an option to set a custom elevation range once, at best with a slider from min to max altitude, should be feasible and provide many advantages much like the dynamic elevation coloring.
2) There is no straightforward, easy and clean way to implement dynamic elevation coloring. Since I don't have knowledge of the internal processing pipeline take the following ideas with a grain of salt.
2.1) If no tiles are reused, then there isn't a problem and you can simply apply new color values that fit the current elevation data. This happens e.g. when zooming, when searching/jumping to location, changing settings, etc.
2.2) If tiles are reused, it gets complicated. This happens when the viewport moves, e.g. when users touches to slide, navigation, guidance, etc. This is exactly where the previously mentioned problem lies. Essentially this problem stems from the unavoidable mismatch between the old and new elevation range: any viewport movement results in new elevation data on screen and thus the new and the old elevation range will always be different. Thus, after a movement the currently used elevation range might be too broad, to narrow, too low or too high (e.g. if you move from mountains to lowlands). To avoid redrawing I came up with two workarounds to reduce the risk of this mismatch.
2.2.1) Bigger sliding window: Don't take min max values from the screen only, but from a bigger window and update the values on slide, e.g. 2x times bigger area than screen, 3 tiles in any direction. This will result in a broader elevation range which gives some leeway.
2.2.2) Threshold: If the old and the new min-max value are too different, e.g. 25% threshold, use new and more suitable elevation-color value pairs and YES force a redraw of the titles that would normally be reused.
In short, an option to set a custom min and max elevation for coloring is a feasible and useful feature. A straightforward implementation of dynamic elevation coloring would be too expensive, but in some cases (e.g. when zooming) it would be simple, while for the problematic cases (e.g. moving viewport through sliding) a workaround could be to use a sliding window and threshold.
Helle Menion,
I very much appreciate your responsive and elaborate answer! I now have a better understanding of how the coloring is done internally and I wouldn't want a feature that is so costly for you to implement and for the system to process.
Now I get it where the problem lies and why an implementation for dynamic coloring would require lots of memory and processing ‒ because some tiles are reused when moving the viewport and changing the elevation-color value pairs would mean they couldn't be reused and would have to be redrawn so all tiles use the same consistent color values and thus display smooth gradients across all visible tiles.
What to do instead?
1) It seems that only the dynamic elevation coloring is the challenging part but an option to set a custom elevation range once, at best with a slider from min to max altitude, should be feasible and provide many advantages much like the dynamic elevation coloring.
2) There is no straightforward, easy and clean way to implement dynamic elevation coloring. Since I don't have knowledge of the internal processing pipeline take the following ideas with a grain of salt.
2.1) If no tiles are reused, then there isn't a problem and you can simply apply new color values that fit the current elevation data. This happens e.g. when zooming, when searching/jumping to location, changing settings, etc.
2.2) If tiles are reused, it gets complicated. This happens when the viewport moves, e.g. when users touches to slide, navigation, guidance, etc. This is exactly where the previously mentioned problem lies. Essentially this problem stems from the unavoidable mismatch between the old and new elevation range: any viewport movement results in new elevation data on screen and thus the new and the old elevation range will always be different. Thus, after a movement the currently used elevation range might be too broad, to narrow, too low or too high (e.g. if you move from mountains to lowlands). To avoid redrawing I came up with two workarounds to reduce the risk of this mismatch.
2.2.1) Bigger sliding window: Don't take min max values from the screen only, but from a bigger window and update the values on slide, e.g. 2x times bigger area than screen, 3 tiles in any direction. This will result in a broader elevation range which gives some leeway.
2.2.2) Threshold: If the old and the new min-max value are too different, e.g. 25% threshold, use new and more suitable elevation-color value pairs and YES force a redraw of the titles that would normally be reused.
In short, an option to set a custom min and max elevation for coloring is a feasible and useful feature. A straightforward implementation of dynamic elevation coloring would be too expensive, but in some cases (e.g. when zooming) it would be simple, while for the problematic cases (e.g. moving viewport through sliding) a workaround could be to use a sliding window and threshold.
Hello Martin,
thanks for the detailed thoughts. I'm thinking about it.
At least user-defined min/max values are doable. Next to it, you need to define at least two colors for these values and things start to be more complicated. This is the reason why I decided (years ago) not to create direct support for user-defined values in the UI, but rather added support for custom palettes placed into Locus/data/interpolators directory.
You are familiar with them? I agree it may be cumbersome to customize these files, on the second side it gives a huge range of flexibility that will require a lot of work on the UI otherwise. And I simply think, that this feature does not worth the time.
Thanks for understanding and if you will be playing with palette files and something won't work as expected, please let me know.
Jiří M. aka Menion
Hello Martin,
thanks for the detailed thoughts. I'm thinking about it.
At least user-defined min/max values are doable. Next to it, you need to define at least two colors for these values and things start to be more complicated. This is the reason why I decided (years ago) not to create direct support for user-defined values in the UI, but rather added support for custom palettes placed into Locus/data/interpolators directory.
You are familiar with them? I agree it may be cumbersome to customize these files, on the second side it gives a huge range of flexibility that will require a lot of work on the UI otherwise. And I simply think, that this feature does not worth the time.
Thanks for understanding and if you will be playing with palette files and something won't work as expected, please let me know.
Jiří M. aka Menion
Replies have been locked on this page!