Orbiter terrain elevation issues

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
I'm starting this thread in the hopes that "flaws" found in the elevation terrain can be fixed in the official terrain data. If these issues should be posted as bug reports, then mods please delete this thread.

Issue #1: there is an elevation step in the equator, very noticeable at the 0º/0º point, but also in other places. Just checked tileedit and here are the elevations being reported there at the highest resolution on the point 0º/0º:
-0.39 || +0.50
-------------- (equator)
+0.01 || -0.48


Issue #2: elevation step visible in tile 11/000039/000071, and present up to level 15.


Issue #3: several "pillars" are visible around Madeira Island. tileedit shows some clearly abnormal "dots" with extreme elevation in tiles:
15/000651/001852 (x=34, Y=115)
15/000651/001851 (x=230, Y=54), (x=246, Y=81), (x=250, Y=84)
15/000650/001852 (x=54, Y=27)
15/000650/001856 (x=36, Y=184), (x=47, Y=205)
15/000651/001856 (x=247, Y=53)
15/000651/001857 (x=108, Y=163)
15/000651/001858 (x=28, Y=99), (x=31, Y=94)
15/000652/001855 (x=112, Y=167)
15/000652/001854 (x=82, Y=120), (x=157, Y=128)
15/000653/001859 (x=228, Y=126), (x=233, Y=131)
15/000653/001860 (x=33, Y=214)
I don't know how hard it would be to create a program for this, but some other instances of these "pillars" could be caught by checking the terrain data for extreme elevations or extreme elevation changes.

I'm using Orbiter Beta r84.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I did look into this a bit and it seems that the problem is associated exclusively with tiles that use a 1-byte-per-sample data format (I.e. tiles that have a total altitude range of 256m or less). It would appear that something went wrong in the offset calculation. I'll check if I can recover the correct offset values of the affected tiles without having to re-run the entire elevation data calculation.

The bad news is that this requires an update of the tile files themselves, rather than a fix in the Orbiter code. So this might mean that a new revision of the Earth\Archive\Elev.tree file.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
The bad news is that this requires an update of the tile files themselves, rather than a fix in the Orbiter code. So this might mean that a new revision of the Earth\Archive\Elev.tree file.

I wouldn't call this bad news... as long as changes to the archives aren't made every week. :shrug: IMO, once a year or so would be acceptable.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Is there any difference in how the latest revision (84) handles terrain data over the release version? The reason why I'm asking is because of this: https://www.orbiter-forum.com/showthread.php?p=587131&postcount=2229

We're using modified terrain data for the SLC-6 area in order to fit the pad vessel. Everything is fine in the release version, but in the latest beta revision, the terrain is messed up as you can see in the screenshot.
 
Top