Note that there is already a hard-coded terrain sampler subsystem, i.e. implemented in C++ space.
This could be used to query the terrain as needed, possibly using different heuristics/resolutions and then use those heuristics to select a suitable sub-texture from a color palette.
You would probably still want to spread out the terrain sampling over multiple frames - e.g. by going from coarse to detailed sampling, i.e. refinining the resolution of the terrain map over time.
Speaking in general, it would also make sense to allocate results into ND based volumes (center/range based) - since terrain is a static thing, you can simplify the samplig alogrithm significantly, especially once you take a look at the groundspeed and heading/direction - that way you can take into account what's going to be visible/relevant in the upcoming xx frames/seconds, based on the size/range (mode) of the display and its center - then, you can extrapolate the location of the aircraft to build a list of terrain samples that are going to be relevant, so that you sample those first, i.e. with higher priority.
Again, you don't need C++ changes to make algorithmic improvements - a simple LOD scheme can be implemented by using the existing Canvas.Group element.
This would also make sense given that multiple NDs may be showing the same terrain using different ranges and ND modes, so you would want to use a common DEM provider for this sort of thing, due to performance considerations.
https://wiki.flightgear.org/MapStructure_Optimizations