• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

GeoTIFF Mesh

Does anyone know a way to convert the NAD83 to WGS84? Global Mapper can do it but I don't have the $250 to spend on registration.
 
It seems like OpenEV might do it, but I had no luck trying it. I also pulled in some Seamless NED 1/3" data in geotiff, and found it was in 32 bit float, so you have to convert to 16 bit as well for resample. But I've found from experience that Seamless gives different formats. For BIL I found that if the data is 0-255 it will ouput byte data, not 16bit.

scott s.
.
 
Hi, Skubakobe

dlgv32 Pro is a limited-feature version of commercial software called Global Mapper which was created from the original dlgv32 source code. Improved to address changes in data standards and to better meet customer requirements, dlgv32 Pro continues the tradition of providing quality viewing software for USGS data users. The USGS has obtained from Global Mapper a license to freely distribute this limited-feature version.

available at: http://mcmcweb.er.usgs.gov/drc/dlgv32pro/

Jose
 
editing of the GeoTiff header

Hi all,

there is another possibility for the seamless ned sources in GeoTiff format. The lat/lon projection with the datum NAD83 doesn’t need data transformation to the lat/lon projection with the datum WGS84, because these both are identical for FS. The only obstacle is that the FSX SDK resampler doesn’t accept the meta info from the geotiff header about the datum NAD83. There is simple tool for editing of the GeoTiff header, the program ListGeo, available with the win GUI from ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/listgeo_GUI.zip

In the metadata .gtf file there is necessary to change the NAD83 section (from the Keyed information to the prime meridian) with the WGS section, borrowed from the SRTM GeoTiff:

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
-100.250093 40.2500926 0
ModelPixelScaleTag (1,3):
9.25925926e-005 9.25925926e-005 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,218): "IMAGINE GeoTIFF Support\nCopyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved\n@(#)$RCSfile: egtf.c $ $Revision: 1.9.2.9 $ $Date: 2002/10/28 15:14:13EST $\nProjection Name = GCS_WGS_1984\nUnits = dd\nGeoTIFF Units = dd"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
End_Of_Keys.
End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)

Corner Coordinates:
Upper Left (100d15' 0.33"W, 40d15' 0.33"N)
Lower Left (100d15' 0.33"W, 40d 0' 0.00"N)
Upper Right (100d 0' 0.00"W, 40d15' 0.33"N)
Lower Right (100d 0' 0.00"W, 40d 0' 0.00"N)
Center (100d 7'30.17"W, 40d 7'30.17"N)


The modified ned geotiff is acceptable for FSX resampler, but this issue is very academic, because the resulted bgl is the same quality as from the bil format :confused:

Cheers

Vlada Stoje
 
Hi all,

I was wrong with the standard quality of the GeoTiff bgls. The 1/3s ned grids deserve better elevation precision as 1.0m, because with the horizontal resolution 10m the vertical resolution 1.0m caused only poor series of slopes: 0.0deg; 5.7deg =arctan(0.1); 11.3deg=arctan(0.2); 16.7deg=arctan(0.3) etc. So the 1/3s ned seamless geotiffs have better numerical precision about 0.3m. To keep this fine info into bgl, in the FSX resampler finally the option FractionBits works, so for example with the FractionBits = 3 the numerical precision of the elevation in the bgl is 1/(2^3) = 0.125m and it can keep sufficiently the 0.3m precision of the geotiff source. The inf file can look somewhat like this

[Source]
Type = GeoTIFF
Layer = Elevation
SourceDir = "SourceData"
SourceFile = "nad_gf.tif"

[Destination]
DestDir = "Output"
DestBaseFileName = "Seamless_ned13_tif"
DestFileType = BGL
LOD = Auto
FractionBits = 3

and the resultant bgl in TmfViewer shows values with the 0.125m precision. In FS the difference can be hardly visible and the bigger bgl mesh file will consume more PC resources, so I can’t recommend this way, it is only academic possibility for precise molehills producing ;)

Cheers

Vlada Stoje
 
The vertical accuracy of the 1/3" NED data is hard to pin down. According to USGS, the data are extracted from (in most cases) 7.5' quad DEMs. The actual quads referenced are included in the metadata. the problem is that the accuracy standards for these DEMs are classified as level 1-3. The prescribed accuracy is determined in terms of root-mean-square error (RMSE) and absolute error. It appears the original DEM data included the accuracry level and computed RMSE but I don't see that anywhere for the NED product.

The accuracy standards are:

Level------RMSE--------absolute
1............15m............50m
2............1/2 contour 1 contour
3............1/3 contour 2/3 contour

unfortunately, you would have to access the quad DLG or DRG data to determine the contour interval for the level 2 and 3 accuracy data. I think a typical contour interval for non-mountainous areas is 20 ft.

scott s.
.
 
Hi guys,

the problem I have noticed with the raw NED 1/3" data is that they don't use fractions of meters at all; the elevation data are "stepped" as 1-m layers. You may not notice this as much in Global Mapper because it defaults to "interpolation" mode (Anti-Alias Pixels), which it applies to the raw raster data.

A second problem is that the vector-to-raster conversion by the data providers retained quite obvious contour lines. Thus, in addition to the 1-m steps, which may perhaps not be obvious in FS, you also end up with larger steps at 50-m vertical intervals, which can be very visible in FS; see http://portal.fsgenesis.net/index.php?name=PNphpBB2&file=viewtopic&t=3459&highlight=

Below is a screenshot of a raw NED 1/3" section showing both the 1-m steps and the bigger 50-m bands.

In my opinion this pretty much disqualifies the "high-res" NED data and considerations about fine-scale vertical accuracy become secondary. While the 1" data lead to rounder peaks and ridges they don't have the side effects mentioned above, which is why I prefer them for my own work. Like I said in the FSGenesis thread, sometimes less is more.

Cheers, Holger
 

Attachments

  • NED10 mesh steps in Global Mapper.jpg
    NED10 mesh steps in Global Mapper.jpg
    99.1 KB · Views: 725
Last edited:
Hi,

thanks for reply! Scott, there are different vertical parameters of the dem data, for example for SRTM:

1. Vertical accuracy of the data. In the report “An assessment of the SRTM topographic products” at http://www2.jpl.nasa.gov/srtm/SRTM_D31639.pdf there is described the 90% Absolute Height Error, for example 6.2m for Eurasia and 9.0m for N. America.

2. Numerical precision: 1m for all SRTM products

3. Steps between contourlines - can be different for different maps

In the case of the seamless ned 1/3s I mentioned only the numerical precision. In the BIL format it is again 1m (like SRTM), but Holger, in GeoTiff it is better. Now I see in the Microdem, that the values are in centimeters (?). In the GlobalMapper (I have only the free version) it seemed that there were only values with the step 0.3m, but I could be wrong that this is the numerical precision of the data. Your experience with the 1s and 1/3s ned data is interesting, thanks!

Cheers

Vlada Stoje

PS: Holger, big thanks also for the BC Bella Coola for FSX, it is wonderful!
 
I think it is correct that the geotiff and floatgrid formats that provide 32 bit float values provide better quantization smoothing than the integer arcgrid and BIL formats.

Looking at the metadata from some geotiff 1/3" data, I see that the source quad dems are shown with a parameter "PMETHOD" of 5. According to the data dictionary, this means the data are level 2 using a program called Line Tracer for X-Windows (LT4X) which is a program for extracting vectors form scanned raster maps. In the case of hypsography data I found this:

"Each elevation in a DEM represents a post or point. The LT4X program uses contour information to build profiles that run in eight directions. Elevations for each post are determined by averaging the eight profiles that intersect each point. The profiles that cross contours closest to the DEM point are given more weight in this averaging. Points that are approximately 3.5 cell widths away (100-m in a 30-m DEM) from the nearest contour are filtered to reduce interpolation artifacts."

It appears that the LT4X method is currently being used to generate all the data that is used in the 1" and 1/3" NED, but I don't know if the coverage is complete. It doesn't seem like the vertical elevation resolution is directly reported in the metadata. It appears that 0.1m is common in the DEM data, but if the ZMIN and ZMAX data are looked at, they are showing 8 digits of precision. Of course, this is just interpolation data, having no relation to the actual source accuracy.

I don't think FS specifies a vertical datum? The NED is NAVD88 but I don't think anyone makes note of that.

scott s.
.
 
Hi Scott,

the FS world oceans have simplified shape of the WGS84 rotation ellipsoid, so they differ from the real oceans or from the geoid vertically several hundreds meters on some places, but this doesn’t matter for the aviation sim. About vertical datums, the modern continental or regional vertical datums (NAVD88 for US, or here in middle Europe the Balt after correction) differ from the older vertical datums just fractions of meter, so it isn’t much important for FS sceneries. Your question is rightful, when the input data can have bigger precision and SDK allows processing it. I can’t find more on internet and don’t remember precisely one interesting case, it was some new bridge perhaps somewhere on the Swiss-German borders, when Swiss engineers used for theirs end of the bridge the old vertical datum based on the Mediterranean Sea. This sea is partially isolated from the oceans and is quickly evaporated, so its water level is about 0.4m under the equipotential surface approximating the oceans. The German engineers used the modern vertical datum based on the Baltic Sea, what was the surprise then :eek:

Cheers

Vlada Stoje

(Please don’t worry about my English)
 
European vertical reference frame

Hi Horst,

thanks for this detailed picture for Austria! It is in good agreement with the last picture in this article http://www.fig.net/pub/fig_2002/Ts5-3/TS5_3_augath_ihde.pdf
describing the European vertical reference frame EVRF2000. There are illustrated the differences between EVRF2000 zero level and the zero levels of national height systems in Europe (in centimeters). I suppose in our country here are still used the datasets in the national system (the tidal gauge in Baltic sea), which have the altitudes 0.14m smaller as the unified system, but I am not sure. It is evident that this phenomenon is negligibly small for FS scenery design. To the original topic of this thread, these small differences really can be contained in the precise GeoTiff sources :)

Cheers

Vlada Stoje
 
You must log in or register to reply here.
Back
Top