TERRAIN_MAX_VERTEX_LEVEL

[Guest Ideas]

Okay, I am using 10Meter Data and Did the Mesh at LOD12, why is it that if I change from TERRAIN_MAX_VERTEX_LEVEL=19 to TERRAIN_MAX_VERTEX_LEVEL=21 I get these amazingly high cliffs (50,000 ft high and above)?

[Guest sgreenwood]

Sounds like a good example of the amount of additional detail you can reveal by increasing the TMVL setting!Have you looked at the bgl file with tmfviewer?Does the DEM look ok in Microdem when you Zoom in?>The Dems are a little "crooked" on screen, does the True North/Magnetic>North have to be set to a certain setting for Mesh?I assume this is because the source data is in UTM format and needs to be converted to lat/lon format. Were you able to do this?Stevewww.fs-traveler.com

[Guest Ideas]

Okay, how do I convert from UTM to Lat/Lon?(I thought that a Microdem *.dem was already Lat/Lon)

[Guest sgreenwood]

>Okay, how do I convert from UTM to Lat/Lon?Sorry I didn't get back to you sooner on your previous post :(I assume you are using SDTS data in 7.5' quadrants, probably in a .gz archive. Microdem can read these directly. * I usually begin by merging several quadrants into a single DEM file.* Then load this merged DEM file into Microdem and save it as a DTED file. You will be asked to specify the data spacing in arcsecs. I use 0.3 (I don't think Microdem supports more decimal places here.) This step will convert the data to lat/lon format.* Now load the new .DT1 file into Microdem and Save As-MD DEM. This should put your data into the required WGS84 datum, in lat/lon format.Try reloading this final file one more time and use Analyze-Header to confirm the format.At this point, you can either Save the file As 16-bit BSQ and use the BSQ data directly with the SDK or close the file and use BIGBSQ to convert the data from Microdem format to the format required by the SDK.This data often has missing values around the edges. The newest version of resample.exe deals with these, but be sure the inf file has the correct entry (probably 32767) for missing values so it can identify them.Good luck,Steve

[Guest Ideas]

Okay, Back with a New Problem. Some of the Areas that I am trying to work on, when I save them as DT1 files, crunch down into almost nothing. I end up with the whole Grid in the correct height, but about 1/50th of the width.Any Suggestions?Ken

[Guest sgreenwood]

>Okay, Back with a New Problem. >>Some of the Areas that I am trying to work on, when I save>them as DT1 files, crunch down into almost nothing. I end up>with the whole Grid in the correct height, but about 1/50th of>the width.Are you seeing the crunching in Microdem or in the bgl file/sim?When you load the DT1 file into Microdem, does it look OK, and are the boundary coordinates correct? Only some of the areas? Are the source files all the same size and type?How large an area does the DEM cover? If you are only working with one 7.5' DEM, the SDK may be trimming the sides.How are you converting the DEM to the SDK format?Have you looked at the bgl file with tmfviewer.exe?If this doesn't help, we will need more details about your source data, the steps you are taking to process it, and at what stage you are seeing this problem.Steve

[Guest Ideas]

The crunching is in MD after convewrting to DT1The top image is the DT1 the underlay is the same area in DEMN38* 15' to N37* 52'W110* 00' to W109* 07'Have not reached the SDK Stage yet

[Guest sgreenwood]

Strange. As is the large number of what appear to be coordinates listed on the left. Are you sure you entered 0.3 arcsecs for the spacing when doing the conversion.Use Analyze.Header to see what it tells you about the DT1 file. Compare this with Analyze.Header information about the source DEM, to confirm the spacing and the fact that it is in UTM format.You can load both files at the same time, then select each in turn and open the analysis dialog. This way you can compare them side-by-side.

[Guest Ideas]

Okay, for some reason it did not like 0.3, but it liked 3Now I have done other areas using 0.3 and they worked, same 10 Meter data...I am getting confused...Let me take a break and get back to you...Oh, BTW, how (After you compile the BGL) can you determine what LOD it is in IF you let the program do an AUTO on it?

[Guest sgreenwood]

>Oh, BTW, how (After you compile the BGL) can you determine what LOD it >is in IF you let the program do an AUTO on it?This is not trivial, which is just one reason why I never use AUTO. To construct my lists of default mesh LOD values, I compared screenshots of the default mesh (unknown LOD) with my own mesh (known LOD). The higher LOD data is displayed, so I can tell the LOD of the unknown by determining the LOD I need to use to override it. :)

[Guest sgreenwood]

Some time ago, Gilles Gauthier showed me another way to determine LOD, viewing bgl files with tmfviewer.exe. (Thanks Gilles)By zooming in on a feature until it is displayed at the same magnification in separate views of the known LOD and unknown LOD bgl files, we can compare the sizes of the cells displayed in each. Increasing the LOD by 1 decreases the height and width by 1/2.I have circled representative cells in the images below. The cell on the left is 1/4 the size of the one on the right, indicating that the LOD of that bgl is one step higher. Using this approach, one can determine the LOD of either bgl when the other is known.http://forums.avsim.com/user_files/40131.gifSteve