• 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.

QGIS export issues. I need to export from 32 bit to 16. How?

Messages
93
Country
us-washington
I am having QGIS export issues. It seems as though every trick in the book to either convert or export the newly-minted pre-1980 terrain as a Complex Integer 16 bit file (the type needed for 30 meter mesh) is not working. Efforts to do so either corrupt the data or the layer does not show up in QGIS.

Is there a way to accomplish this?
 
Messages
7,450
Country
us-illinois
Hi Steve:

Based on what I see here:

https://www.fsdeveloper.com/forum/t...helens-pre-1980-experience.444992/post-893590


...you intend to use FractionBits=6 in your SDK Resample *.INF; 32-Bit Floating Point (not 16-Bit integer) values are required to do that.


See: FS Terrain SDK Doc... "Using Scaled Elevation Values"

https://docs.microsoft.com/en-us/pr...rectedfrom=MSDN#using-scaled-elevation-values


I would recommend you create an additional clean data set copied from your existing data set, which has been purposely resampled via a GIS application, so that the derived data set is gridded at an interval between elevation data points of ...no 'closer' than 30 Meters (1 Arc Second).

That 'clean' lower resolution data set can be interpolated with your original custom data set, to generate a new data set to eliminate spikes / pits.

https://docs.qgis.org/3.4/en/docs/gentle_gis_introduction/spatial_analysis_interpolation.html

https://www.google.com/search?q=qgi...LjKYAQCgAQHIAQ_AAQE&sclient=gws-wiz#cobssid=s


The merged, interpolated data set can then be output to a elevation raster 32-Bit Floating Point GeoTIFF for a FSX / P3D SDK Resample mesh.


Alternatively, the merged, interpolated data set can then be processed / output into a elevation vector TIN *.SHP file to append into SBuilderX.

SBuilderX can compile the *.SHP as a CVX vector BGL via SDK SHP2VEC, containing a airport boundary flatten-only terrain mesh-modifying TIN.

GaryGB
 
Last edited:
Messages
93
Country
us-washington
Hi Steve:

Based on what I see here:

https://www.fsdeveloper.com/forum/t...helens-pre-1980-experience.444992/post-893590


...you intend to use FractionBits=6 in your SDK Resample *.INF; 32-Bit Floating Point (not 16-Bit integer) values are required to do that.


See: FS Terrain SDK Doc... "Using Scaled Elevation Values"

https://docs.microsoft.com/en-us/pr...rectedfrom=MSDN#using-scaled-elevation-values


I would recommend you create an additional clean data set copied from your existing data set, which has been purposely resampled via a GIS application, so that the derived data set is gridded at an interval between elevation data points of ...no 'closer' than 30 Meters (1 Arc Second).

That 'clean' lower resolution data set can be interpolated with your original custom data set, to generate a new data set to eliminate spikes / pits.

https://docs.qgis.org/3.4/en/docs/gentle_gis_introduction/spatial_analysis_interpolation.html

https://www.google.com/search?q=qgi...LjKYAQCgAQHIAQ_AAQE&sclient=gws-wiz#cobssid=s


The merged, interpolated data set can then be output to a elevation raster 32-Bit Floating Point GeoTIFF for a FSX / P3D SDK Resample mesh.


Alternatively, the merged, interpolated data set can then be processed / output into a elevation vector TIN *.SHP file to append into SBuilderX.

SBuilderX can compile the *.SHP as a CVX vector BGL via SDK SHP2VEC, containing a airport boundary flatten-only terrain mesh-modifying TIN.

GaryGB
When you say "clean data set" are you inferring that everything be done from scratch again? That is a route I would rather not take.

Also, for whatever reason, attempts to merge the custom GeoTIFF with a post-eruption DEM I have have at 30-meter resolution seems to fail as well as attempts to reproject the post-eruption DEM from UTM10 NAD27 to EPSG4326 WSG84 datum FS requires.
 
Messages
93
Country
us-washington
These are the artifacts I am currently experiencing (images attached below), and I believe it might be because the DEM is exporting as a 32 bit DEM.

I noted in one YouTube tutorial, specifically this one here: (
) that DEM data above 10 meter resolution should be expported as a 16 bit GeoTIFF. Indeed, in the first few test exports, I was able to export it as a 16 bit GeoTIFF and these artifacts were not present.

Worthy to note here, that the upper contour elevation to which I am creating my DEMs from, is sourced from a 1958 topographic 15-minute quadrangle map. Those elevations noted on the contour line data (which are spaced at 80 foot intervals) in the areas that I am experiencing these artifacts at, were in elevations that were not changed by the May 18, 1980 eruption, and it is peculiar that I am experiencing these.

Subsequent to a test export of one phase of testing contour line data to export to DEM, I lost the ability in QGIS to export out to 16 bit.

With respect to the use of FractionBits, I have that set at 6 because any number less than that (much less its complete removal from the INF file), results in stair stepping at close range. In fact in the very first test of this DEM in which I was successful in reestablishing pre-1980 elevation data west of Spirit Lake, a FractionBits setting at 3 resulted in stair stepping that was visible in the mesh even when at Harry Truman's Mount St. Helens Lodge. That FractionBits setting of 6, is in fact what I used in the pre-1980 cone DEM. I am going to try a couple things tonight and see where things go, but I do look forward to your expertise, as well.

Of particular note, I wanted to highlight the center image... The rocky feature in that center image just slightly above left center is a rock quarry, that when you are right next to it at ground level, resembles half a blast crater. It is this quarry that Dr. David Johnston would be stationed at.

One alternative to avoid these artifacts entirely, would be the complete retracing of that 1958 contour data, but then I would lose the quarry's detail in the existing underlying ORBX mesh.


2021-11-13_1-15-44-737.jpg

2021-11-13_1-17-8-628.jpg

2021-11-13_1-17-38-716.jpg
 
Last edited:
Messages
7,450
Country
us-illinois
When you say "clean data set" are you inferring that everything be done from scratch again? That is a route I would rather not take.

Also, for whatever reason, attempts to merge the custom GeoTIFF with a post-eruption DEM I have have at 30-meter resolution seems to fail as well as attempts to reproject the post-eruption DEM from UTM10 NAD27 to EPSG4326 WSG84 datum FS requires.

Hi Steve:

By "clean", I mean fixing specific areas where you see any spikes / pits; this can sometimes be done by 'back-filling' with another data set.

It is possible to do this by interpolation of the original with another data set; "re-gridding" may be a way to do this without "re-tracing".


If you specifically describe the types of failures and any associated error messages you see when using QGIS, perhaps others here may help.

My work-flow is based on Global Mapper, so I may not be able to help identify an alternate work-flow from that of QGIS without specific info.


FYI: It may be at least another day until I can reply further as I shall be traveling today.

[EDITED]

With respect to the use of FractionBits, I have that set at 6 because any number less than that (much less its complete removal from the INF file), results in stair stepping at close range.

In fact in the very first test of this DEM in which I was successful in reestablishing pre-1980 elevation data west of Spirit Lake, a FractionBits setting at 3 resulted in stair stepping that was visible in the mesh even when at Harry Truman's Mount St. Helens Lodge.

That FractionBits setting of 6, is in fact what I used in the pre-1980 cone DEM. I am going to try a couple things tonight and see where things go, but I do look forward to your expertise, as well.

Hi Steve:

Based on what I see here:

https://www.fsdeveloper.com/forum/t...helens-pre-1980-experience.444992/post-893590


...you intend to use FractionBits=6 in your SDK Resample *.INF; 32-Bit Floating Point (not 16-Bit integer) values are required to do that.


See: FS Terrain SDK Doc... "Using Scaled Elevation Values"

https://docs.microsoft.com/en-us/pr...rectedfrom=MSDN#using-scaled-elevation-values

GaryGB

NOTE: Although the FS Terrain SDK docs section cited above does not mention that 32-Bit Floating Point elevation data is essential for elimination of contour interval "terracing" artifacts in terrain mesh, FS developer community user experience has shown that for maximal elimination of such "stair-stepping" artifacts as may be seen in FS at run time with your custom terrain mesh actively displayed, 32-Bit Floating Point (not 16-Bit integer) values are required to be used in one's source data, along with a 'peak altitude correlated' "FractionBits" *.INF file parameter value ...when submitted to SDK Resample for compilation.

If working with DEMs otherwise natively rendered in FS at run time without "terracing" artifacts, use of 16-Bit Integer elevation source data sets is preferred; however, AFAIK, use of FractionBits does not visibly alter the terrain mesh output when utilized with such 16-Bit Integer data sets.


I would recommend testing FractionBits=7 as used in the SDK docs worked example, in conjunction with a 32-Bit Floating Point source data set, to see if the additional BaseValue parameter is also required to yield SDK Resample results you seek for the local data set in question. :idea:


BTW: To minimize 'aliasing' in CVX vector roads, SBuilderX has functions that can "smooth" Appended RDX*.SHP poly-lines by editing vertex points.

SBuilderX Help > {Contents} tab > Working with SBuilderX > Working with Points, Lines and Polygons > Smooth > [Line or Poly Smoothing dialog]


[END_EDIT]

Good luck with your further troubleshooting. :)

GaryGB
 
Last edited:
Messages
93
Country
us-washington
I'd have to say that the amount of knowledge I've gained thus far on this project could probably exceed a couple lifetimes.

In the process of creating this terrain I've learned one of the reasons as to why I am having that artifacting (e.g. the cliffs and sudden rises in terrain that drop off, especially near Spirit Lake's divide ridge) is largely due to the Resample process. I ended up crosschecking my elevations with current topographic elevations for that same contour lines affected at the anomaly, and they ended up matching.

The other cause: Working with 80-foot contour intervals and subsequently meshing that DEM up with current 5-meter DEM.

Another thing I've noticed, and I tested this out extensively after having reached a major milestone in the development of this project last night, is that sometimes the use of FractionBits can have often unintended, and very undesirable, consequences if you're using it on low-res mesh.

Case in point: This compiled terrain BGL as seen in TMFViewer.exe.

Last night, after several days of weary contour tracing (and believe me, my right hand hurts from all that mouse usage!) I finally completed the contour tracing of all pre-1980-eruption elevations within the project area. The completed contour elevations extend 17 statute miles from the summit of Mount St. Helens to just above Kid Valley, a small hamlet east of the town of Toutle on Highway 504.

As an aside, Kid Valley was nearly decimated on May 18, 1980. Over twenty five homes in the area were lost due to volcanic mudflows and lahars, and a Weyerhaeuser sorting yard (not Camp Baker, but their 19-Mile Camp) got wiped off the map. The only sole surviving structure in the area was an A-Frame cabin, just three days from being completed. Today it is an eruption landmark. The elevation change in this area was well over five feet, which is not noticeable in the SIM, but definitely noticeable when you walk up to the A-Frame and realize its front patio was four feet below you!

Anyways, in the first test compile of the completed terrain, I saved the generated GeoTIFF as a 32-bit floating integer file (as I couldn't in the version of QGIS I was using, which was 3.6 Noosa)... After writing a test INF file, I did the usual drag-and-drop of the INF over Resample.exe and let it do its thing. I had the code written as follows:

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="test_BGL_SpiritLake11.tif"
MinValidValue=260
NullCellValue=-32767

[Destination]
DestDir="."
DestBaseFileName="test_Pre_1980_SpiritLake01"
DestFileType=BGL
LOD=6,16
FractionBits=6
BaseValue=1000

Upon testing it in the SIM, I noticed immediately the appearance of a plateau at an elevation of 9,670 feet (just shy of the pre-eruption elevation of Mount St. Helens), that extended for a distance of 7 miles and was approximately three quarters of a mile wide at its widest. The uppermost elevation of this plateau had every bit of elevation data that the compiled DEM had shown in SAGA and in QGIS, so I was a bit confused. (That plateau shows up as the lighter green areas in the first TMFViewer screenshot). Basically, every bit of elevation that was supposed to be valley floor, was at the top of the plateau.

Upon a further test I was able to eliminate this plateau entirely by adjusting the use of FractionBits and altering the MinValidValue portion of the code, however in doing that I lost the entire last mile of the DEM in the SIM. Smaller plateus happened where existing mesh would pop through the custom-compiled mesh. This happened at Camp Baker (a Weyerhaeuser log sort and transfer yard), and the area where a failed sediment retention structure was built just upstream from the Camp Baker site in the mid-1980s.

Subsequent to that development, and some cursing profanely at the issues that kept appearing, I sought the advice of a Reddit community devoted to QGIS to see where things kept going wrong and why I had been having issues exporting in 16 Bit Signed Integer instead of the 32 Bit Floating Point Integer it kept exporting.

As it turns out, one of 3.6 Noosa's difficulties is indeed the ability to export properly in 16 bit (it had been a fork development as open-source applications go). A user there on the QGIS subreddit had given me advice on what I needed to do, to fix the issue. That fix? Download QGIS 3.16.13 Hannover, as it is the most current release of the application. I'd already downloaded it before but it had no featureset so what did I have to lose? So, I uninstalled the previous install and then subsequently re-downloaded the MSI and set to work...

Once in QGIS 3.16.13, I was then able to convert the 32-bit Floating Point Integer to 16 bit Signed Integer format and then recompiled a test DEM using the same parameters. In that code I re-added FractionBits, and restored the MinValidValue call, as well.

The result? A success.

However, as it is still in the phases of self-testing and trial-and-error I can't call it too much of a success, but it is one nonetheless. To make sure DEM mesh matches, I am going to add the 30-meter resolution pre-eruption DEM to a post-eruption DEM by way of merging the two. This will ensure a flawless mesh when complete, and to restore the lost detail of the quarry on Johnston Ridge where geologist David Johnston was stationed, I am going to resample a 1-foot LIDAR DEM I have of the entire area, to 10-meter mesh in QGIS, then clip it to just the quarry and the location of Johnston Ridge Observatory.

Contours.jpg

Oopsies..jpg

Oopsiesfixed.jpg
 
Last edited:
Messages
7,450
Country
us-illinois
Anyways, in the first test compile of the completed terrain, I saved the generated GeoTIFF as a 32-bit floating integer file (as I couldn't in the version of QGIS I was using, which was 3.6 Noosa)... After writing a test INF file, I did the usual drag-and-drop of the INF over Resample.exe and let it do its thing. I had the code written as follows:

[Source]
Type=GeoTIFF
Layer=Elevation
SourceDir="."
SourceFile="test_BGL_SpiritLake11.tif"
MinValidValue=260
NullCellValue=-32767

[Destination]
DestDir="."
DestBaseFileName="test_Pre_1980_SpiritLake01"
DestFileType=BGL
LOD=6,16
FractionBits=6
BaseValue=1000

Upon testing it in the SIM, I noticed immediately the appearance of a plateau at an elevation of 9,670 feet (just shy of the pre-eruption elevation of Mount St. Helens), that extended for a distance of 7 miles and was approximately three quarters of a mile wide at its widest. The uppermost elevation of this plateau had every bit of elevation data that the compiled DEM had shown in SAGA and in QGIS, so I was a bit confused. (That plateau shows up as the lighter green areas in the first TMFViewer screenshot). Basically, every bit of elevation that was supposed to be valley floor, was at the top of the plateau.

Upon a further test I was able to eliminate this plateau entirely by adjusting the use of FractionBits and altering the MinValidValue portion of the code, however in doing that I lost the entire last mile of the DEM in the SIM. Smaller plateaus happened where existing mesh would pop through the custom-compiled mesh. This happened at Camp Baker (a Weyerhaeuser log sort and transfer yard), and the area where a failed sediment retention structure was built just upstream from the Camp Baker site in the mid-1980s.

Subsequent to that development, and some cursing profanely at the issues that kept appearing, I sought the advice of a Reddit community devoted to QGIS to see where things kept going wrong and why I had been having issues exporting in 16 Bit Signed Integer instead of the 32 Bit Floating Point Integer it kept exporting.

As it turns out, one of 3.6 Noosa's difficulties is indeed the ability to export properly in 16 bit (it had been a fork development as open-source applications go). A user there on the QGIS subreddit had given me advice on what I needed to do, to fix the issue. That fix? Download QGIS 3.16.13 Hannover, as it is the most current release of the application. I'd already downloaded it before but it had no feature set so what did I have to lose? So, I uninstalled the previous install and then subsequently re-downloaded the MSI and set to work...

Once in QGIS 3.16.13, I was then able to convert the 32-bit Floating Point Integer to 16 bit Signed Integer format and then recompiled a test DEM using the same parameters. In that code I re-added FractionBits, and restored the MinValidValue call, as well.

The result? A success.

Hi Steve:

By default, either 16-Bit Integer or 32-Bit Floating Point (not "Integer") elevation values are submitted to FS SDK Resample via raster files.

The range of supported values in FS Terrain SDK Resample is -32767 to +32767 Meters; increased bit-depth is required for 'fractional' Meter elevations.

https://desktop.arcgis.com/en/arcma...t-depth-capacity-for-raster-dataset-cells.htm


AFAIK, a 32-Bit Floating Point number is a "Single-precision floating point format" numeric value.

https://www.quora.com/What-are-32-bit-floating-point-numbers


https://en.wikipedia.org/wiki/Single-precision_floating-point_format

"A floating-point variable can represent a wider range of numbers than a fixed-point variable of the same bit width at the cost of precision."


AFAIK, a "32 Bit Floating Point Integer" GeoTIFF is a 'Raw' raster format requiring explicit input parameter values to identify it when submitted to FS SDK Resample.

https://www.dummies.com/programming...e-between-integers-and-floating-point-values/



As I use Global Mapper, I am not certain what is actually output by 'forks' of QGIS out in the wild ...when exporting elevation raster GeoTIFFs.



If QGIS outputs "Raw" elevation data files, you may need to specify the exact format of the source file submitted to SDK Resample in your *.INF file:

https://docs.microsoft.com/en-us/pr...v=msdn.10)?redirectedfrom=MSDN#source-section


BandGapBytesintegerNumber of bytes between bands
(BSQ - Band Sequential layouts only).
0optional
BandLayoutBIL

BIP

BSQ
Band interleaved by line

Band interleaved by pixel

Band sequential (separate bands)
required
BandRowBytesintegerNumber of bytes per band per rownCols * sizeof( SampleType)optional
ByteOrderIntel

Motorola
Least significant byte first

Most significant byte first
required
nBandsintegerNumber of bandsrequired
SampleTypeUINT8
SINT8
UINT16
SINT16
UINT32
SINT32
UINT64
SINT64
FLOAT32

FLOAT64
8 bit unsigned integer
8 bit signed integer
16 bit unsigned integer
16 bit signed integer
32 bit unsigned integer
32 bit signed integer
64 bit unsigned integer
64 bit signed integer
32 bit IEEE floating point
64 bit IEEE floating point
requiredrequired
SkipBytesintegerNumber of bytes to skip at start of file0optional
TotalRowBytesintegerTotal number of bytes per row BIL: nBands * BandRowBytes

BIP: nCols * nBands * sizeof( SampleType)

BSQ: BandRowBytes


IIRC, use of the additional *.INF parameters above, is also required when submitting SRTM *.HGT format source files to FS Terrain SDK Resample.

GaryGB
 
Last edited:
Messages
93
Country
us-washington
Hi Steve:

By default, either 16-Bit Integer or 32-Bit Floating Point (not "Integer") elevation values are submitted to FS SDK Resample via raster files.

The range of supported values in FS Terrain SDK Resample is -32767 to +32767 Meters; increased bit-depth is required for 'fractional' Meter elevations.

https://desktop.arcgis.com/en/arcma...t-depth-capacity-for-raster-dataset-cells.htm


AFAIK, a 32-Bit Floating Point number is a "Single-precision floating point format" numeric value.

https://www.quora.com/What-are-32-bit-floating-point-numbers


https://en.wikipedia.org/wiki/Single-precision_floating-point_format

"A floating-point variable can represent a wider range of numbers than a fixed-point variable of the same bit width at the cost of precision."


AFAIK, "32 Bit Floating Point Integer" GeoTIFF is a 'Raw' raster format requiring explicit input parameter values to identify it when submitted to FS SDK Resample.

https://www.dummies.com/programming...e-between-integers-and-floating-point-values/



As I use Global Mapper, I am not certain what is actually output by 'forks' of QGIS out in the wild ...when exporting elevation raster GeoTIFFs.



If QGIS outputs "Raw" elevation data files, you may need to specify the exact format of the source file submitted to SDK Resample in your *.INF file:

https://docs.microsoft.com/en-us/pr...v=msdn.10)?redirectedfrom=MSDN#source-section


BandGapBytesintegerNumber of bytes between bands
(BSQ - Band Sequential layouts only).
0optional
BandLayoutBIL

BIP

BSQ
Band interleaved by line

Band interleaved by pixel

Band sequential (separate bands)
required
BandRowBytesintegerNumber of bytes per band per rownCols * sizeof( SampleType)optional
ByteOrderIntel

Motorola
Least significant byte first

Most significant byte first
required
nBandsintegerNumber of bandsrequired
SampleTypeUINT8
SINT8
UINT16
SINT16
UINT32
SINT32
UINT64
SINT64
FLOAT32

FLOAT64
8 bit unsigned integer
8 bit signed integer
16 bit unsigned integer
16 bit signed integer
32 bit unsigned integer
32 bit signed integer
64 bit unsigned integer
64 bit signed integer
32 bit IEEE floating point
64 bit IEEE floating point
requiredrequired
SkipBytesintegerNumber of bytes to skip at start of file0optional
TotalRowBytesintegerTotal number of bytes per row BIL: nBands * BandRowBytes

BIP: nCols * nBands * sizeof( SampleType)

BSQ: BandRowBytes


IIRC, use of the additional *.INF parameters above, is also required when submitting SRTM *.HGT format source files to FS Terrain SDK Resample.

GaryGB

I will definitely keep all of that in mind for when it comes to compiling the final terrain BGLs and at this point, I hope I don't mess things up! For now, however, I have to figure out how to get the DEMs to even produce accurately, much less find out how to merge the pre-eruption elevation DEM with post-eruption 7.5m-minute quadrangle mosaic I do have so that the terrain doesn't have much conflicts in the sim (e.g. the cliffs and mesh conflicts I illustrated earlier.)

My biggest issue right now, is that the DEMs are not producing accurately based on contour data. Instead of a gentle-sloping valley floor, there are gentle peaks marking the separation distance between contour lines throughout the entire valley floor west of Hoffstadt Bluffs. This occurs regardless of which interpolating method I use to test the data. These peaks aren't noticeable at elevations above 4,000 feet, but when flying at treetop level they do present some serious accuracy concerns.

Also of issue is getting the DEM to model the slope between Mount St. Helens and Spirit Lake accurately. As the contour interval in the source quadrangle topographic maps I have is 80 feet, the interpolating process to create the DEM skips over two contour lines in the adjacent region close to present-day Windy Ridge and doesn't even interpolate the point data. It should be noted here, too, that the only resolution to which greater detail can be achieved are those 15-minute, 80-foot-contour-inverval quads. 7.5 minute quadrangles that were done pre-eruption apparently have been lost or destroyed, which had a contour interval of 40 feet. Oregon State University has a copy of a mosaic of those 7.5 minute quadrangles, but it is a paper poster 20x30 inches in size. One final issue is that the interpolated DEMs don't match contour lines in the Coldwater Creek valley. Apparently for whatever reason I am not even certain of, the interpolating methods I am trying apparently cannot even recognize contour data as being a gentle sloping plain or a U-shaped valley floor. Instead, it takes large gaps between contours and produces hills as a result. The Coldwater Creek Valley is one example. Spirit Lake is another (it produces hills in the final DEM instead of a flat lake, in spite of the contour being a set elevation), and the Castle Creek marsh is another. At Castle Creek marsh, what is supposed to be a flat marsh is a gentle sloping hill. Thankfully I have overcome the gentle peaks in Spirit Lake with a lake flatten in SBuilderX, but for the other areas, SBuilderX fails to append the ESRI contour shapefile (it gives an error when attempting to import the data).

For reference, I've attached a series of three screenshots illustrating the issues I mentioned above. The first is the raw contour data tracing, shown as vertice points, in QGIS. The second is the finalized DEM of that contour data, and the third is a hillshade analysis of the DEM, illustrating the peaks that are occurring.

One other issue I am having, is a basic understanding of working with GIS software in general. I cannot seem to find good assistance no matter what source of help I try. There have been few who have been of great help (you and Holger Sandmann included, to which I've named both of you in the final installation documentation's acknowledgements), but for the most part I am finding that people who do this stuff and work with this software more often than I, are less often likely to render genuine assistance. Three times now in the course of this project's last month of development, I've had questions be shut down on the QGIS StackExchange site. The first two questions were closed by a moderator there before anyone had a reasonable opportunity to answers my questions. Over on Reddit's QGIS subreddit, it is no different. I am told to go "Google it!" or link pasta is given to multiple tutorials that I have already read, that haven't helped at all.

This is because in most tutorials and end-user manuals that I have seen for open source software, it is written very poorly or written for an understanding of those who actually use the software in their day-to-day lives. It isn't written with novices (or part-time users like me) in mind and as such I have been unable to decipher which cell size should be used for the interpolating of the DEM, which pixel settings to use, let alone which interpolating methods are best for this type of contour data. As a result I am struggling, quite immensely, with even creating DEMs of this magnitude.

I have a pretty stout laptop. It's a commercial edition HP EliteBook with an Intel Core5i processor, 8gb of RAM and Windows 7 (I'm a luddite in a way, and cannot stand Windows 10's kids'-construction-paper-project-like interface). Back in its day it was a $2,500 commercial edition laptop for business and industrial use. It runs FSX with ease. However, interpolating a simple DEM of this coverage area has taken up to six hours to compile. Working with SAGA and QGIS in the interpolation process has at times had ill effects on both my laptop and my sanity. One attempt to interpolate a DEM using Inverse Distance Weighting (the same as illustrated in a PDX study I've linked before), actually resulted in my laptop overheating to the point it shut down.

ContourIssue1.jpg

ContourIssue2.jpg

ContourIssue3.jpg
 
Messages
7,450
Country
us-illinois
Hi Steve:

Most of us here 'attempting' to work with freeware / payware GIS applications / utilities share your pain, as we have all been there / done that. ;)

Even my more powerful desktop GIS computers have also been brought to their knees, being frozen for many hours ...only to eventually crash. :banghead:


I am in the midst of attending to a number of time urgent matters IRL which require a preponderance of my available time and energy.

But, when I get some more time free, I shall continue to try and offer what help I am able to.


I might gain some insights to better understand your challenges if I had a pre-1980 'St.H' eruption DEM data set to process via Global Mapper (aka "GM").

If we compare specific Topo map versions as digital files downloaded at URLs shared via PM here at FSDev, perhaps I can derive a similar data set via 'GM'.


Then I may be able to identify an alternate work-flow while verifying the work-flow you have been describing in several threads here at FSDev.

Perhaps as well, others here with experience working in both Global Mapper and QGIS might offer additional observations and suggestions for your project.


BTW: It may prove helpful to the troubleshooting process if you attach a screen capture of the error you see in SBuilderX when:

"SBuilderX fails to append the ESRI contour shapefile (it gives an error when attempting to import the data)."


PS: IMHO, "link pasta" will inevitably lose its appeal, if it is not served with a choice of Alfredo or Marinara sauce, and access to a grated cheese garnish. :laughing:


Hang in there, Steve; you have come a long way already, and some further effort will in time, yield more successful results to be proud of. :)

GaryGB
 
Top