I am currently using 76m US mesh from FSGenesis, and while the mountainous and desert regions do look much better, I have noticed more "anomolies" in the more urban areas. I understand the issues with "plateauing" of airports, but I have also noticed more "cliff" like shorelines, and in some cases valleys have step plateaus or rivers cut deep gorges when they should only be valleys.Overall, these litle things really draw me out from the sim, and I am thinking of actually going back to Microsoft Default mesh because I can deal with rivers running down hill easier than a big Canyon.But here is a question. Will 38m mesh correct this phenomonon, or just make it worse. I am thinking with 38m mesh, the valleys will now look more like valleys because of added points on the hill, but I'm wondering if 38m is still too coarse. I'm debating on buying the 38m landclass for the US and want to know if I will be pleased. The 78m is really a mixed bag in my book. Yes, it is more mathematically accurate, but in some cases, not as asthetically accurate.The FS Landclass, on the other hand, is a real keeper, and I'm seriously considering dumping the 78m and stay with the default 152m mesh. Will 38m help or hinder?

I'd suggest checking out the new utility srtm_to_bgl available in the library. I've never created mesh, but within minutes I had made 1 arc-sec mesh for all of western washington from srtm data. I beleive that's about 38m resolution. Its not perfect, but the price was right! Others have written about some anomolous data that's caused by radio wave reflections around cities, but overall, its great.I have noticed the cliff syndrome...and I wonder if it may be due to misplaced shorelines? In western Washington, there is usually a pretty steep hill leading down to the Sound, so fs may just have trouble seperating a steep slope from a cliff.Bob B

Large bodies of water, lakes, large rivers, and oceans use flattening polygons to lay the water down at a specific elevation. It's actually not this simple (water is actually holes in the landclass showing the underlying water class, yes even on land). In any case, the flattening polygons are set at a preset elevation. The elevation files at Justin's web site provide elevation data only. The default data that provides the rivers, shorline and lakes are not accurate enough and cause cliffs (for lack of a better word) where the elevation and the flatten polygon do not meet together very well. However, more accurate polygons can be made. Take a look at the scenery design forum if your interested. Here is an example of work that I'm doing as an upgrade to my West Coast scenery that is on Justin's web site. The penninsula behind the airplane and the inlet to the left don't exist using the default scenery. And using the default scenery on the terrain create cliffs along the lake edge. But not when using this kind of detail.http://forums.avsim.net/user_files/37247.jpgBut in answering your question.... the higher accuracy mesh will make it look a little better. But your still going to get the cliffs and such. Just not as much. I don't like them either and I am working on methods to make the overall appearance of the scenery much better. Leland Steffensen.

Howdy:if I may add my 2 cents...Based on my experience, there are two basic problems that prevent good fit between the default FS linework (coasts, lakes, rivers) and add-on meshes.1. There's that error due to the low resolution of the hyrdological data FS used to generate the coastlines and rivers. As Leland points out, this error is essentially random and a result of the generalization or coarse approximation of the real-world coastlines.2. In almost any places and with most add-on meshes there are systematic displacements in a specific direction (say NW) of the mesh relative to the coastlines and it becomes most obvious when slewing around in top-down mode. The image below shows a drastic example where the mesh is shifted to the North (left) relative to the coastline, creating 'cliffs' on most North shores. The reason for this offset can be either a mistake by the mesh designer or, more likely, a problem with the default data. In either case, an appropriate adjustment can be made at the time of the mesh compilation (and only then!!!) to minimize the displacement. The second image shows that the displacement in the first image wasn't Ed Denney's fault but happens with any source data (in this case Shuttle Radar 90-m data). However, the lower panel shows how an adjustment can make most of those cliffs disappear and place the inlet in its correct basin.As to the question whether higher resolution meshes have fewer problems: in my experience, the higher the resolution, the more problems will arise, simply because a more accurate terrain mesh is more likely to expose the inaccuracies with the default coastlines and lake or airport elevations and locations. In my first example image you can see that Ed's high-res mesh definitely does not improve on his mid-res mesh.Cheers, Holger http://forums.avsim.net/user_files/37266.jpghttp://forums.avsim.net/user_files/37269.jpg

Holger, with SRTM LOD9 do you find a need for south and east offset as a matter of course using the HGT files of 1 arcsec data?Bob B

Hi Bob:Unfortunately, the systematic displacement is inconsistent in both direction and extent. Otherwise, bulk corrections would be easy and it would become more popular with mesh designers (as far as I know, none of the payware mesh designers do this type of correction).For my BC LOD7 mesh, I split the entire 1 mio sq-km area into 14 tiles (~ 3 degrees lat by 6 degrees lon) and each tile required a slightly different offset. The actual offsets (0.001 to 0.01 of a degree) seem small but translate into several hundred meters, which makes all the difference.To find out whether your particular area could benefit from an offset, compile the mesh as is, then open it in TMFViewer and put the shorelines (HYL*.bgl in FS8, HL*.bgl in FS9) of the same area on top. Unfortunately, TMFViewer has a limited number of elevation colors and the SRTM data are quite noisy over water but the display will reveal an obvious displacement. For lack of a screenshot of my own, I borrow one from Gilles Gauthier that came with his displacement-adjusted SRTM mesh files of Quebec and Atlantic Canada. Look at the peninsula in the two left panels, as-is at top and corrected at bottom. If you find an offset, you'll have to use slew mode in FS and the coordinates display to measure/estimate the numerical value and correct the Lat/Lon coordinate in your .inf file. I know it's tedious but I can vouch for the positive results. Cheers, Holgerhttp://forums.avsim.net/user_files/37281.jpg

Holger, great thread....trying to check the shores against my mesh as you suggest, but I've never used tmfviewer for this kind of file. Not sure the code, how do we decode the hl*.bgl file names to get the right file for the area of interest? I assume NAMW is North America West, but how do I find the right file to correspond with my mesh at N47W123, for example.B

Hi Bob:errr... didn't know the answer yesterday so I did a search in the forums and looked through the SDKs but ... came up empty. Thus far I always did the trial and error approach: keep on loading HL* files until you get the right one. However, your question prompted me to do the math and this is what I've got.I know from the Terrain Vector Data SDK that each of the vector/polygon files covers a LOD5 grid cell, i.e., 2.8125 degrees of latitude (90 / 2power5) and 3.75 degrees of longitude (120 / 2power5). The FS world has a coordinate system that starts at 90N, 180W and increases to the South and East. For the LOD5 grid resolution there are 64 cells N-S and 96 cells W-E.Based on that I could figure out that the first two digits following 'HL9' depict the longitudional cell number and the two after those the latitudional cell numbers. To derive the file name for a specific area the math (for the northern hemisphere west of Greenwich!) is as follows:cell No. Longitude = TRUNC((180-long)/3.75)cell No. Latitude = TRUNC((90-lat)/2.8125)In your case: W123 = 15, N47 = 15, so the file in question is HL915150.bglTa-da! Hope I didn't mess up somewhere but it worked for me. If a file doesn't show up right away in TMFViewer use the Jump > LatLong menu function to go to the center of your area.Cheers, Holger

very nice! I agree with your conclusions!thanks,B

its VERY close...the actual hl file for N48.5 W123 was hl915140, not hl915150, but heck....it gets you very close! I can tell you that the first number looks like longitude cell, cuz hl915140 was the next cell north of hl915150

"the actual hl file for N48.5 W123 was hl915140, not hl915150, but heck....it gets you very close!"hey - a moving target ;-) In your post above you asked for N47 not N48.5; according to my formula the value for 48.5 is indeed 14!Anyway, I'm glad it works.Cheers, Holger

Hi Holger,this is perfect! Only perhaps the plus in upper formula would be better, in agreement with the FS coordinate convention - we are positive, and you are negative!!!Cheers Vladahttp://forums.avsim.net/user_files/37684.jpg