What the mesh "numbers" mean
The realism of terrain elevation in the simulator is determined primarily by the accuracy (source resolution) of the source data used
and the final resolution of the mesh created from that data. Resolution refers to the horizontal distance between data points.
Source data (why arcseconds or meters?)
The locations of the real world elevations available in digital format are usually specified using one of two reference systems: Geographic and UTM.
The Geographic system, a two dimensional spherical system, is the most common and the one we are all familiar with (latitude and longitude).
Locations are specified using angular distances from standard reference points.
These are expressed as fractions of the circumference of the globe - degrees, minutes, seconds and fractions thereof are most common.
60 seconds = 1 minute, 60 minutes = 1 degree, 360 degrees = circumference of globe.
Other units of angular measure are also used: grads, radians, minutes of arc, seconds of arc (1 arcsec = 1/3600 degrees).
Longitude is the angle (East or West) between the Prime Meridian (Greenwich, England) and the point of interest.
The linear distance varies with latitude.
Latitude is the angle (North or South) between the Equator and the point of interest.
The linear distance also varies with location because the true shape of the earth is an eccentric ellipsoid, not a sphere.
The UTM system (Universal Transverse Mercator), divides the globe into zones and sub-zones, with boundaries specified in degrees.
Within these sub-zones, locations are specified using linear distances (e.g. meters) from reference points. These distances do not, of course,
vary with location.
Mesh source data resolution is therefore generally specified in units of arcseconds or meters, depending on the source of the data.
Final data (what is LOD?)
Source data is converted to FS-compatible format mesh files using the resample.exe program provided in the Microsoft SDK
(Software Development Kit). The developer specifies the LOD (Level of detail) the resample.exe program uses to convert the data;
this LOD value specifies the horizontal distance between elevation points in the sim.
For example, LOD10 produces elevation data at horizontal intervals of 38.2 meters; Higher LOD => closer spacing/higher resolution.
resample.exe calculates elevation values for these points in the mesh file by interpolating from the source data;
the closer the source and final resolutions match, the smaller the error introduced by this process.
For example, 30m source data matches well with 38.2m (LOD10) or 19.1m (LOD11) final resolution, and
1000m source data (e.g. GTOPO30 data) matches best with 1223.0 (LOD5) or 611.5 (LOD6) final resolution.
Oversampling - confusion (or abuse?)
Not all mesh is created with a final resolution that closely matches the source resolution. This is easily accomplished by specifying a higher LOD
value than is appropriate. The result is larger files, slower loading of data in the sim, and greater processing demand. I'll provide two real-world examples.
1 - freeware example: FSTerrain is often used to create mesh with GTOPO30 (30 arcsec resolution) data, and provides the ability to oversampling this data to
as much as 3.75 arc seconds (115m). This means that each original data point is used to create 64 points using interpolation. If the developer then
uses LOD10 to convert this to 38.2m, each data point is used to create 9 points in the final mesh. As a result of these two steps,
a single point in the source data is converted into about 576 data points in the final mesh file! Motivation?: To provide more detail, but hardly accurate.
2 - payware example: 3-arcsec (90m) source data was converted using an LOD of 10 (38.2m). In this case, a single point in the source data is converted
into about 6 data points in the final mesh file! Motivation?: Take advantage of confusion to claim higher resolution data in a competitive market.
Common data sources
Name | Spacing Meters | Spacing Arcsecs | Reference System |
NED | 30m | 1* | Geographic |
DEM | 90m | 3* | Geographic |
SDTS | 30m* | 1 | UTM |
SDTS | 10m* | 0.33 | UTM |
DTED0 | 1000m | 30* | Geographic |
DTED1 | 90m | 3* | Geographic |
GTOPO30 | 1000m | 30* | Geographic |
* actual resolution |
|
From the FS Terrain SDK LOD table
LOD | Sample Size Meters | Deg Boundaries Lat | Deg Boundaries Lon | Span Meters |
0 | 39136.2 | 90 | 120 | 10018863 |
1 | 19568.1 | 45 | 60 | 5009431 |
2 | 9784.0 | 22.5 | 30 | 2504716 |
3 | 4892.0 | 11.25 | 15 | 1252358 |
4 | 2446.0 | 5.625 | 7.5 | 626179 |
5 | 1223.0 | 2.8125 | 3.75 | 313089 |
6 | 611.5 | 1.40625 | 1.875 | 156545 |
7 | 305.8 | 0.703125 | 0.9375 | 78272 |
8 | 152.9 | 0.3515625 | 0.46875 | 39136 |
9 | 76.4 | 0.17578125 | 0.234375 | 19568 |
10 | 38.2 | 0.087890625 | 0.1171875 | 9784 |
11 | 19.1 | 0.043945313 | 0.05859375 | 4892 |
12 | 9.6 | 0.021972656 | 0.029296875 | 2446 |
... | ... | ... | ... | ... |
|
|