Qgis users? Qgis saving my Float 32 and/or int 16 files as 8 Bit

[N101ST]

Trying adding Terrain development to my scenery adventure! Apparently I only know enuff to get into trouble!

Im having this issue... I import SRTMs to Qgis. Everything seems to go well. When I export the files as geotiffs, they always export as 8 bit. (In FSX, the terrain appears as a bunch of points sticking out of the ground with all the airports within the area sitting on "plateaus"!) So far everything I have reserached, tells me it need to be int16 or i even saw Float 32, in order to work thru the resample process and installation into FSX. I have used the conversion/translate function in Qgis, per a "solution post" i read, to set it to float32, (even tried int16), with no compression, and translate appears to run properly, no errors or warnings, and it still exports my geotiff to "8 bit unsigned integer" If I understand what i am reading... 8 bit will not work in FSX to create terrain?

Im an old guy, so I can accept I could be so far off I need to scrap it and start the learning from step one, or could I be close enuff to be helped?!

Thanks for any direction someone may provide!

Scott

 

[GaryGB]

Hi Scott:

Personally, I do not work with QGIS, and instead use Global Mapper; but others here do use QGIS, and may lend a hand.


However, regarding a work-flow for FSX terrain mesh, one does need to use either of several GIS data types with SDK Resample.

8-Bit will do as you saw ...spiked terrain.

A 32-Bit Floating Point GeoTiff in EPSG:4326 (aka "Geographic" Lat-Lon projection / "WGS84" datum) GIS projection gives best results.


Be aware FSX' default terrain BGLs within the lower 48 states of the USA are already mostly derived from 30 Meter resolution SRTM data.

The USA lower 48 states has had a USGS 10 Meter data set for at least 10 years, and there may be a 5 Meter data set available as well.


If you tell us which area you are making your terrain mesh for, we can help you select the best data to produce a higher resolution output.


As for QGIS, perhaps rhumbaflappy (aka Richard Ludowise or "Dick") may offer some advise on how to configure QGIS for 32-Bit output.

You seem to be off to a good start.

GaryGB

 

[N101ST]

Thanks so much for your reply.
I have been messing with several ariports here in North Carolina, near my area, along the I-40 corridor from the Lake Norman to Asheville. (Not all of em!!) So far everything has been creating "as real as I can" buildings and such. Now I have started moving up the mountains. Currently working on 2NC0...Mountain Air Airport. Not much by way of airport objects but great mountain scenery! Most of the mountains here look nice in FSX, but right in the vicinity the airport they missed some elevations.

I got my SRTMs from TNM Download page, Both 1 Arc second and 1/3 Arc second DEMs. The 1/3 arc sec geotiff is filename USGS_13_n36w083_20220512. Along with other info, it reads; Float32, CRS is EPSG:4326 - WGS 84

Using Qgis because just can't justify the cost of Global Mapper, for just a hobby effort! And I am still learning Qgis as I am working on this!

Thanks again!
Scott

 

[GaryGB]

Hi Scott:

The FSX default terrain mesh file:

[FSX install path]\Scenery\0302\scenery\dem0302.bgl

...contains LODs 2-10, which is no more detailed than 38.3 Meters between elevation data points.


By combining your 1-Arc Second and 1/3-Arc Second Elevation GeoTiffs, you should be able to drop out any pits and voids, and eliminate spikes.


GeoTiff in Float32 is indeed, the 32-Bit Floating Point GIS file format that you would want to use

If CRS (aka Coordinate Reference system) is "EPSG:4326 - WGS 84", that is Geographic Lat-Lon projection / WGS84 datum.

Based on your cited info above, the file types you have are apparently already in the GIS file format that FSX SDK Resample requires.


If you do not receive a reply on how to output from QGIS, you can likely work with those files manually without too much effort.


The first thing I would recommend trying is Ollyau's GeoTiff-To-Inf utility, to semi-automatically create your *.INF file for SDK Resample:

https://www.fsdeveloper.com/forum/resources/geotiff-to-inf.119/


NOTE: Although the above utility is originally intended to process imagery GeoTiffs, the *.INF file can be modified for Elevation GeoTiffs.


I would make a few changes to the resulting *.INF file before using it to ensure you utilize both your source files for terrain mesh.


Alternatively, you can manually prepare a *.INF file for use with your GeoTiffs, as ACES made it easier to work with GeoTiffs specifically.


I shall check back to see if / when you may be prepared to proceed further with some edits to the *.INF file.

I am downloading DEM files cited above for a 2NC0 1x1 Degree area so I can compare sources and work-flows for your project area.

GaryGB

 

[N101ST]

Hey Gary,

Going to be gone next two days. Thought I would upload these for your info comparison. The "2NC0_Elevation1 and13.jpg" is a look at Qgis export dialog, what the rendering looked like after exporting, and file details after export. The red circled items are things I had to select. (BTW, the rendering pics are not "squeezed". Thats is how they look in the exported files!) The 2NC0_File info is the files I downloaded originally, the native file information, from inside Qgis. You'll notice there are 4 files but only ended up with two. One of the 1 ARC and one of the 1/3 ARC. The other two were south of the area I am working on. I do have GeoTiffTotInf downloaded and I have run both exported files thru it. I know Ill have to edit the inf's...for one I know I need to put both sources into one inf. As soon as I get back Ill edit the inf's and post em so as to see what I have done and need to do!
Again, Thank you for your time!
Scott

 

[N101ST]

Hi Gary...I'm baaaaack!

I ran the GeoTiffToInf on both of the GeoTiffs, Since I didn't know which one i should use or use both and add the source from one inf to the other. (BTW...Thought it odd, that, after running them both in GeoTiffToInf, "2nc0_Elevation13" file type says "setup information" and "2nc0_Elevation1" says "TINF"). After modifying "2nc0_Elevation1", i saved it as "2nc0_Elevation1.inf". Now reads file type; "setup information" same as the "2nc0_Elevation13" file.
I have modified them to what i have read as the desired changes to the .infs.
Posted here

Thanks,
Scott

 

[GaryGB]

Hi Scott:

If you ZIP a copy of your *.INF files and attach them to a reply here, I will post some edits that you may want to do.


FYI: I also made 2NC0 FSX Terrain from elevation GeoTiffs of 1-arc second and 1/3-arc second USGS TNM source data.

That source data for 2NC0 has been re-projected to EPSG:4326 and output to 32-Bit Floating Point elevation GeoTiffs.

Additionally, I used GeoTiff-To-Inf to output *.INF files for the (2) GeoTiffs, which I edited for Terrain via SDK Resample.

My recommendations for edits to your own *.INF files will be based on successful test compilations of 2NC0 Terrain BGLs.


Also, since FSX default 2NC0 is not properly positioned relative to the real world data, I made a Airport Background Exclude Polygon (aka "AB Exclude"), and compiled it into a CVX Vector BGL, so that you can see where to position the replacement ADE airport for FSX, in order to align it with the real world terrain data.

Download the "Airport Background Exclude" BGL below and put it in your \Scenery sub-folder with your Terrain BGL after compiled.

GaryGB

 

[N101ST]

Hey Gary,

Thanks for the bgl.

Been messin all afternoon and evening trying to get a new graphics card and power supply installed. No joy... had to order an adapter cable to deal with this dog-gone HP proprietary motherboard sockets! Threw it back together, just using the on-board graphics until Tuesday! Wont be able to run FSX until Tuesday eve

I thought the runway was off a bit. I used google earth background image in ADEX to correct the position i thought it needed to be. I'm interested to see how much it really is off!

Attached is the infs zipped. These are the ones I posted earlier. Would you prefer fresh, un-modified versions?

Scott

 

[GaryGB]

Hey Gary,

Thanks for the bgl.

Been messing all afternoon and evening trying to get a new graphics card and power supply installed. No joy... had to order an adapter cable to deal with this dog-gone HP proprietary motherboard sockets! Threw it back together, just using the on-board graphics until Tuesday! Wont be able to run FSX until Tuesday eve

I thought the runway was off a bit. I used google earth background image in ADEX to correct the position i thought it needed to be. I'm interested to see how much it really is off!

Hi Scott:

Here are your *.INFs with proposed edits.

Note that I have made a major change in how we submit (2) sources to FSX SDK Resample in (1) "Multi-source" INF.

As I stated above:

"By combining your 1-Arc Second and 1/3-Arc Second Elevation GeoTiffs, you should be able to drop out any pits and voids, and eliminate spikes."


The *.INF should combine the source data in proper sequence to allow Resample to interpolate and output into (1) BGL.

Otherwise we would likely have needed to control file loading sequence via alpha-numeric file naming for (2) BGLs.


As you may know, you can select / copy / paste the code below into Windows NotePad, and save as:

2NC0_Elevation13+1_Multi-source.inf

...by setting 'Save As Type' to: "All Files (*.*)", so that the file extension will be .INF rather than .TXT

[Source]
Type = MultiSource
NumberOfSources = 2

[Source1]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="2nc0_Elevation13.tif"
MinValidValue=0
NullCellValue=-32767
PixelIsPoint=0
ulxMap=-82.355782696
ulyMap=35.874648012
xDim=2.19095958194606E-06
yDim=1.26873973362938E-06

[Source2]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="2nc0_Elevation1.tiff"
MinValidValue=0
NullCellValue=-32767
PixelIsPoint=0
ulxMap=-82.363790643
ulyMap=35.87985322
xDim=1.04929800664463E-05
yDim=6.0762693798445E-06

[Destination]
DestDir="."
DestBaseFileName="2nc0_Elevation13+1_Multi-source"
LOD=AUTO
FractionBits=3
CompressionQuality=100

Attached is the infs zipped. These are the ones I posted earlier. Would you prefer fresh, un-modified versions?

Scott

I found direct FTP URLs for this DEM data set on a USGS web site, and should be able to find names / URLs for your files.

So if you post the original names of the TIFF files you downloaded from USGS / TNM web portal, I can verify this info also.


This Multi-source INF assumes your data is otherwise correct for submission to SDK Resample.

But I would be glad to verify your data set further.


As I do not use QGIS, I want to verify that PixelIsPoint=0 instead of PixelIsPoint=1 is correct for your source data set.

Also, I want to verify that your source is in EPSG:4326 and in 32-Bit Floating Point format.


BTW: Normally I would not personally have utilized these SDK Resample Parameter Values in the INF(s)

MinValidValue=0
NullCellValue=-32767

However, I expect that they will not disrupt the processing, and the SDK Resample Multi-source sequenced interpolation should "drop out any pits and voids, and eliminate spikes" ...that you may have seen in FSX with prior test compilations.

You should be able to see FSX render a10-Meter Terrain Mesh if your Terrain resolution slider is set at 5 Meters ...or less.


Let me know how your compilation works for you using this initial set of proposed edits.


PS: I am curious as to what your current computer hardware is (with the planned graphics card upgrade).

If it is adequately powerful, you may also wish to do a test using some 1-Meter data that I found for the 2NC0 area.

GaryGB

 

[N101ST]

Here are your *.INFs with proposed edits.

Okay...copied the inf code and saved as "2nc0_Elevation1+13_Multi-source.inf" Thanks

I found direct FTP URLs for this DEM data set on a USGS web site, and should be able to find names / URLs for your files.

So if you post the original names of the TIFF files you downloaded from USGS / TNM web portal, I can verify this info also.

File names downloaded from TNM were... USGS_1_n36w083_20220512 and USGS_13_n36w083_20220512
when I did the initial search on TNM, I got 2 files each. I eliminated 1 each as they were actually south of the area I was interested in

This Multi-source INF assumes your data is otherwise correct for submission to SDK Resample.

But I would be glad to verify your data set further.

As I do not use QGIS, I want to verify that PixelIsPoint=0 instead of PixelIsPoint=1 is correct for your source data set.

The original INFs created from GeoTiffToTnf did show PixelisPoint=0. I changed them to 1.

Also, I want to verify that your source is in EPSG:4326 and in 32-Bit Floating Point format.

Hmmmmm... USGS_1_n36w083_20220512 EPSG:4269 - NAD83 USGS_13_n36w083_20220512 EPSG:4326 -WGS 84


You should be able to see FSX render a10-Meter Terrain Mesh if your Terrain resolution slider is set at 5 Meters ...or less.

Let me know how your compilation works for you using this initial set of proposed edits.

Will do as soon as machine is completely back together!

PS: I am curious as to what your current computer hardware is (with the planned graphics card upgrade).

If it is adequately powerful, you may also wish to do a test using some 1-Meter data that I found for the 2NC0 area.

I meter would be awesome!

Machine Specs:
HP ProDesk 600 G1 Twr Windows 10 Pro (x64)
Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz 3.40 GHz
32 gb RAM
New Graphics card is Radeon RX 580 (8 gb)
Replacing PSU with 750 watt

My current hold up is that this HP motherboard is proprietary. So it has no 20 or 24 pin Motherboard power socket (ATX). It has a 6 pin power socket and a flat 6 pin socket (i understand this is basically a signal port to let the power supply know the computer has been turned on. The adapter Im waiting on adapts the ATX 20-24 pin plug to these two HP plugs.

Scott

 

[GaryGB]

Hi Scott:

You should be able to render a 10-Meter DEM with 7.5 cm/pixel resolution photo-real imagery on your new hardware.

You may see more detail with a 1-Meter DEM with 7.5 cm/pixel resolution photo-real imagery on your new hardware.

UPDATE:

FYI: Although I normally find mesh anomalies are eliminated via sequenced interpolation of multiple increasingly lower LOD DEM data sources in INFs, some persistent mesh artifacts are indeed cleaned up where the 1+10 Meter terrain mesh BGLs overlap by using:

MinValidValue=0
NullCellValue=-32767

...in each [Source (n)] subsection of the *.INF.

When your system upgrade is ready, we can add a 1-Meter DEM source to your 2NC0 Terrain Mesh BGL.

GaryGB

 

[N101ST]

Awwww...Now I'm anxious to get the machine up and running!! LOL!

 

[GaryGB]

Hi Scott:

Did you see the photogrammetry TIN monoliths (buildings derived from un-filtered 1-Meter LiDAR "return" data) ?

Apparently my *.LAZ source data file processing missed a few, so there is "extruded terrain" objects to be flattened.


AFAIK, this FSX Terrain Mesh BGL has a higher resolution custom terrain mesh than MSFS has yet to render.

If I used LOD=Auto,21 in the imagery *.INF file, that BGL would have higher resolution custom photo-real imagery than MSFS.


PS: The FSX default RWY (misaligned to IRL), is off to the left in the latter RWY-32 approach image attached above.

Notice also, FSX' clouds look translucent, unlike MSFS' clouds of artificial coffee creamer, or blasts of volcanic ashes.

GaryGB

 

[N101ST]

Gary,

Man, I love the pics! I did see the monoliths I guess if once flattened they will certainly serve as place markers for buildings...If I can make any that look correct in there!

I did notice the clouds were different. But I cant run FS to compare until I get my good parts put back in the computer! Hopefully this weekend.

About what you said about the terrain resolution, is it because the source downloads were downloading are far better than what was available when FSX came out?

The photoreal scenery looks better than anything I have generated. Im guessing because all the attention I spend on building details, they still sit on the limited FS texture backgrounds!

Now I'm sure that photoreal textures will have to be next! Looking forward to getting back to work!

Thanks again!
Scott

 

[GaryGB]

About what you said about the terrain resolution, is it because the source downloads we are downloading are far better than what was available when FSX came out?

Indeed, AFAIK, all MS-ACES had to use back then, was several old lower resolution DEM sources targeting 30 Meters output for the USA.

FSX was better than FS9, and P3D had a few demo areas that were higher resolution Terrain Mesh than most of FSX.

FSX did a proof-of-concept demo using 5 Meter mesh with Mt. St. Helen's.

GaryGB

 

[N101ST]

Gary,
The machine back up and running. Now Im catching up on the learning process.
I created a new 2NC0 Terrain/scenery under addon scenery. Put the exclude bgl in the addon scenery2NC0 Terrain/scenery folder. Resampled the multisource inf to a bgl and put it into the /scenery folder the multisource. activated the scenry in the scenery library, and...Iv done something wrong! Again, ill have to go back thru the the steps and see what i missed!
Screen shot..

 

[GaryGB]

Hi Scott:

I'm glad to see your computer is now back up and running.

If you post your new "Multi-source" *.INF for the test result shown immediately above, perhaps we can sort it out.

GaryGB

 

[N101ST]

Hey Gary,
Thought I had just copied your "inf" text from above. Have I missed something!
Scott

 

[GaryGB]

Hi Scott:

It is my understanding that the GIS industry standard is for PixelIsPoint to be used with Elevation values in GeoTiFF format.

Statements by Frank Warmerdam (chief author of GDAL routines used in GDAL as the GIS engine for QGIS) indicate GDAL uses PixelIsArea.

https://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint

https://www.usna.edu/Users/oceano/pguth/md_help/html/PixelIsWhat.html

Global Mapper uses PixelIsPoint for Elevation GeoTiffs in compliance with what AFAIK, is the preeminent GIS industry standard.


I will need to see if one can validate usage criteria with the USGS elevation data sets submitted by QGIS ...when displayed in Global Mapper.

Note that the Multi-source INF example I had posted above used the original QGIS default value of PixelIsPoint=0.

Additionally, it is my assumption that ollyau's GeoTiff-To-Inf utilizes Geo-referencing data in GeoTiff source files without any modification.


PS: Some related info on this INF parameter:

https://www.fsdeveloper.com/forum/threads/on-fraction-bits.448084/post-860824

GaryGB

 

[GaryGB]

Hi Scott:

AFAIK, USGS has not included either PixelIsPoint or PixelIsArea parameter values in metadata for any DEMs we are currently discussing,

That parameter will, IIUC, only impact the Lat-Lon, on-ground placement of elevation data points, rather than the Altitude AMSL of those points.


AFAIK, one may use a 'recent' version of QGIS or another GIS application to prepare data sets to be submitted to FSX / P3D SDK Resample.

Provided all files are processed within the same GIS application, one may achieve proper placement / alignment of terrain mesh and imagery.


I recommend initially using all files downloaded from USGS under their original names in all places while establishing a trouble-free work-flow.

This allows would-be helpers to compare results with yours, and to fine-tune procedures that may merit implementation in your work-flow.


Please post an update of your local 2NC0 project using a maximum of 2 DEM files in 1-Arc Second and 1/3-Arc second using original file names.

Then I believe I could better follow your work-flow, see what sources are being used, and fine-tune the INF file for elevation data processing.


After that is completed (and when you are ready), I can post info on how to create custom photo-real imagery to cover that mesh.


Let me know if, how, and when you would like to proceed further with your project.

GaryGB