P3D v4 Elevation Data including "missing data"

[crushnik]

I didn't know you could get null value numbers from gdalinfo! And I know there's no way around the visible line where terrain resolution changes LOD.

It never fails: when reading through the linked posts from Gary's comments I always seem to learn something new I can do, or come across an answer to something unrelated to my original problem that I've spent countless hours trying to figure out. Or at least I get a better understanding of something I couldn't quite grasp before (still trying to wrap my head around the triangular polygons/TIN files). Here goes nothing... thank you gentlemen!

EDIT: There seems to be two different levels to my Mexico terrain, immediately south of San Diego: You can see one section along the coast in the picture that probably is about 575 feet below sea level. Then there is a massive drop-off beyond that. Once I changed NullValue to -999999, that brought the section that was -575 up to where it should be, with visible hills and terrain features, but the area east of that is still about a million feet down. /EDIT

 

[GaryGB]

Hi Jim:

Indeed, that use of NullValue = -999999 makes sense (and of course 'works') with SDK Resample as it is a common GIS NO_DATA fall-back value.

Global Mapper Metadata for the (2) GeoTIFFS I created shows: "GDAL_NO_DATA_VALUE=-32767", the numeric value from which would likely also 'work' in the *.INF.


I first compiled the BGL with no NullValue = parameter value to see if we could identify what Chris saw (since he initially posted no screenies above).

I may try another (2) compiles later, 1 with your NullValue = -999999 parameter value, and 1 with the NullValue = -32767 inferred by the GM Metadata.

[EDITED]

PS: IIRC, the legacy parameter value for SDK Resample "NullCellValue = -9999" would likely also be honored even by P3D SDK Resample.

[END_EDIT]

GaryGB

 

[crushnik]

It looks like the incredibly sunken portion is from the adjacent tile to the right. I am not used to working with the "missing data mask," which made it look like I had a lot more Mexico to go before the end of the scenery tile.

I think it's safe to say I've got this problem licked, by simply changing my INF files to -999999 and resampling the files. I can't thank you guys enough!

 

[GaryGB]

Hi Chris:

After some additional testing in FSX of the (2) merged layers of elevation source data with- or without- use of a NullValue *.INF parameter value, I have concluded that there may be some significant issues of compatibility involving the example DEM tiles cited above in relation to your project.

While you 'can' indeed achieve a workable result using a single layer of 10 Meter DEM data with a NullValue *.INF parameter value which allows a 'clipped' fall-back to the lower LOD resolution default FSX terrain mesh to the South in the area along the USA - Mexico border, IMHO, some further troubleshooting alignment of data set edges by elevation and Geographic coordinates relative to FS quad grid vertices would otherwise be required to make processing of the (2) merged DEM sources feasible.

Whereas I might find it preferable to maximize detail with use of available resources, others may not share my values when extra effort is required.

The issues seen in this scenario used to occur with nearly all tiles in the USGS DEM data set years ago before they launched a "seamless" NED.

It is disappointing to see that even the current SRTM v3.0 (SRTM Plus) SRTMGL1 data set has apparent compatibility issues with the USGS 10 Meter data set that require significant extra work to achieve satisfactory results if used to blend terrain at edges of the CONUS in the area under discussion here.


Certainly I understand the practicalities of minimizing work-flow complexity, and the need to finish your project after grappling with such a massive undertaking over many months of effort; thus, I respect your preference to move ahead by using only a single layer DEM blend into FS default mesh.

As I also have limited available free time, I must set this particular line of inquiry aside in order to focus on some other priorities at the moment.

Perhaps when I am better able to allocate more time to investigating ways of working with the (2) sources cited above at / near KSAN, I may do so.

So for now, I shall wish you good luck with completing your project, and happy holidays.

GaryGB

 

[crushnik]

So for now, I shall wish you good luck with completing your project, and happy holidays.

You too, sir! I'm just tickled pink that the United States data is now only a few tiles away from completion. I couldn't have even started this without you getting my feet pointed in the right direction. If people want good-looking Mexican or Canadian scenery, there are good freeware packages that will surely layer nicely underneath my LOD12 United States mesh.

 

[crushnik]

If anyone else runs into this same problem, know that there are (at least) three different types of Null Data values in USGS 10m digital elevation files. I don't know why most are -999999 and others aren't, but in my experience, using the wrong value creates a mess.

To find the correct value, create a Gdalinfo text file, open it, and look near the bottom. Typically the value is -999999, but you'll also run into -9999 and the occasional -3.40282306073709653e+38