Create super high resolution artificial elevation data around known destinations

[mokun]

Is your feature request related to a problem? Please describe.

• Elevation affects movement of a vehicle. When elevation data is of low resolution, there's quite a bit of guesswork in calculating elevation between two given points.

Describe the solution you desire to see

• Create a separate elevation data double array that will encircle around known destinations such as settlements.
• The elevation data will be super high resolution, say, one data point per meter.
• They will be pseudo-randomly generated upon the start of a settlement.
• The height boundary of this double array on all four sides should be seamless with the actual MEDGR data which is also a elevation double array with global data.

Describe the rationale

• When returning a vehicle from mission to a well-known, well explored destination such as a settlement, settler should know exactly which route to take to get home at fastest and most efficient manner

Specifications (please complete the following information):

• pre 3.6.0 build 8180

Additional context

• Having super high resolution height data will lead to creation and placement of a road network in future around a settlement.
• This is somewhat related to #901, where the ability of choosing which resolution of elevation data matters.

[bevans2000]

I still believe that if we implement loading the high resolution map on the fly for a region around the target we can also achieve this purpose. Also we need to consolidate the various tickets around this area.

[mokun]

One problem is that for a MEGDR image file with 5760 x 2880 pixels, it spans as much as 3.705 km per pixel at the equator.

If we are to consider paving the surface of a road network near a settlement or placing a foundation and constructing a building, no elevation data set with enough precision would suffice.

We may as well assume the surrounding area of a settlement as flat.

Or we could artificially and procedurally generate a terrain profile around a settlement.

Imagine in future if mars-sim becomes 3D, a player would experience in first person what it feels like doing a EVA walk right outside the settlement.

But for now, I'll be happy if we manage to generate, say, 0.1 km per pixel artificial elevation data for piloting vehicle around a settlement.

[mokun]

implement loading the high resolution map on the fly for a region around the target

Yes I like to implement this idea as well, in conjunction with the approach above.

The MEDGR website has higher resolution data set but they are by quadrants only.

We can modify TerrrainElevation class to try to read and cache by quadrants, shall we ?

One problem is that each quadrant defined by MEDGR is still too big for us.

It's even better if we find a way to partition these quadrant data set into smaller regions.

[mokun]

@bevans2000

The current elevation caching mechanism uses index for reading elevation data.

What does it take to modify it to support "artificial" elevations ?

We currently bundle megt90n000eb.img. The elevation data is NOT exactly good enough for piloting vehicles.

At this level 1 elevation resolution, there's a distance of 3.7 km that separate between two adjacent pixels, namely, pixel A and pixel B.

Say, on pixel A, the elevation is 1.0 km. As a vehicle reaches pixel B, suddenly, the elevation can bump down to 0 km. Thus it can have a 1 km change of elevation.

I'd love to generate and fill in some artificial elevation data in between these two pixels.

//	LEVEL 0 :
//  File name: megt90n000cb.img  
//	Pixels: 1440 x 720
//	Resolution: 4 pixels per degree (or 0.25 by 0.25 degrees)
//	Scale: 14.818 km per pixel (=1/4)
//  File size: 2.025 MB
//	
//	LEVEL 1 :
//  File name: megt90n000eb.img
//	Pixels: 5760 x 2880
//	Resolution: 16 pixels per degree (or 0.0625 by 0.0625 degrees)
//	Scale: 3.705 km per pixel (=1/16)	
//  File size: 32.4 MB
//	
//	LEVEL 2 :
//  File name: megt90n000fb.img
//	Pixels: 11520 x 5760
//	Resolution: 32 pixels per degree (or 0.03125 by 0.03125 degrees)
//	Scale: 1.853 km per pixel (=1/32) 	
//  File size: 129.6 MB

In MEGDRCachedReader.java,

    protected MEGDRCachedReader(int maximumEntries, int maxIdleMinutes) {
		
		cache = CacheBuilder.newBuilder()
								.maximumSize(maximumEntries)
								.expireAfterAccess(maxIdleMinutes, TimeUnit.MINUTES)
								.build();
	}

	/**
	 * Gets the elevation at a certain index into the map data. This will check the cached value first.
	 * 
	 * @param index Index to the data.
	 */
    protected short getElevation(int index) {
		short result = 0;
		requests++;
		Integer value = cache.getIfPresent(index);
		if (value != null) {
			result = value.shortValue();
			hits++;
		}
		else {
			result = loadElevation(index);
			cache.put(index, Integer.valueOf(result));
		}

		if (requests % 10000 == 0) {
			logger.fine("MEGDR Cache hit rate " + ((100 * hits)/requests)  + "%, requests="
						+ requests + ", size=" + cache.size());
		}
		return result;
	}

[bevans2000]

Interesting, I think the best way to do this is to create a new map later implementation that can convert a low res map into a high res map. So the implementation would work out the elevation as the gradient between the two points of the low res map. Should be fairly easy to do, just some maths.