Important correction: Viewfinderpanoramas.org does mostly only provide 90m (3sec) mesh for the entire planet. Only a few areas (which I already all covered with UHD Mesh Scenery v1) have 30m (1sec) elevation data ... You can see those few on this download map:

• http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org1.htm

Instead you might try to use 30m (1sec) data from NASA SRTM (which has been released in the mean time) ... but even there, you can expect some "holes" and other mess etc. .

 

Let me give you a short explanation on DEM problems:

 

Elevation data is a bit more complicated science than many imagine. Especially with higher res data, you can experience a lot of strange data "errors", like for example spikes in cities (this was a big problem for the UHD Mesh coverage in Japan for example). Those spikes - especially in cities - are a result of the way this data is collected. Most of the time - especially with all large scale projects like SRTM etc. - they rely on some kind of aerial (most of the time satellite) based measurements (usually radar or laser / lidar). And those measurements do reflect from the surface(!!) ... what ever the surface is at a given point! In cities, that surface is mostly defined by human infrastructure like buildings, roads etc. With high skyscraper or big highways you can easily get some "nice" bumps in those surfaces. Thus, in big cities, you can get "big" spikes (with easily having 100m offset to the ground) due to many high rising buildings. And those spikes can ruin any mesh scenery.

 

But this is usually the nature of most freely available elevation data. If you want real terrain model, where the ground elevation is in the DEM, you - usually - very quickly enter an area of very expensive products (simply for the reason, that its far from trivial and usually very labor / cost intensive to create them). You only alternative might be to do some kind of smoothing on yourself (and realize the complexity of this topic) ... In Japan for example I used the landclass data to determine where the cities are, and only there did I apply some smoothing (which gave a usable result ... but for sure isn't a scientifically perfect solution).

 

Add to this all the holes in the landscape. They are usually a result of measurement errors. For example having bad weather in the way or more often (and very commonly in mountainous regions) depending on the angle of the radar beams hitting ground, some parts of the landscape are shaded by others (the radar not always sees the deep valleys etc.) ... And without correct data, the data processing (because even the "raw" data you get on the net is not really raw ... it is already a complex interpretation of "really raw" radar / lidar measurements) either introduces nasty errors (another reason for spikes) or rather decides to stay with "no data" (resulting in holes). Over the time, some agencies or project groups introduce their own hole filling (if you ar lucky) ... or you can try to do it - again - yourself by back filling the holes from other source. Again, for japan - as an example - I had to back fill the fantastic (but full of holes) Japanese AW3D 1sec elevation data with a bit less detailed SRTM 1sec data AND even had to back fill SRTM 1sec data (because it sill has holes too) with SRTM 3sec data.

 

By the way, Wikipedia has a nice page about elevation data (and the implications I noted above):

• https://en.wikipedia.org/wiki/Digital_elevation_model

So you see ... even though we nowadays are very very lucky to have access to fantastic (and a few years ago unimaginably detailed) data on the internet, we should never expect (even if we wish ) it to be perfect and often need to find ways around those problems (or accept them to some extent if the work needed would not be justifiable). And yes, I really mean this to be true for ALL types of data (as ana example ... whoever worked more deeply with Openstreetmap data will immediately understand what I mean)!

 

 

Hi Andras,

 

 Thanks for this fantastic explanation and about the different SRTM data.  I will definitely try it out.

 

Yes I have those spikes and very bad heights in the .tif from the government website usually on the coast. It's a big learning process and want to make it as close as possible.  

I followed Andras advice and checked out NASA SRTM  1 arc-second from here http://earthexplorer.usgs.gov/ the same area tiles I used earlier and at least till now they are good. The main is the +17+073 lat long as that falls under the Sahyadri Mountains so let's see what I get. 

 

If they are good I may extend the mesh more to the south.

The tiles 

 

+19+072

 

+19+073 

 

 have issues because I am not getting the water areas proper hence won't be touching at the moment.  

 

These are the tiles that I have done :

 

 

+18+072  -  South Mumbai

 

+18+073  Lonavala + Pune

 

+17+073  Area of western ghats 

 

+09+076   Cochin - Kerala

 

+10+076   Cochin - Kerala

 

+10+077  Western Ghats Kodai Kanal Kerala

 

 All are NASA SRTM and ASTER GLOBAL DEM 1 arc-second which to my knowledge would be 30 DEM.

 

 Still doing some flights to check the data.  I would need a lab rat now.

I have covered the western coast of India heading south so the tile starts from :

 

 

+18 and ends at +08. These are only 1 degree tiles. I will go east once I am sure the mesh is OK.  

Made a big blunder, some of the ASTER DEM's are from 2011 and the 2014 NASA SRTM few of the tiles have holes and have no idea how to fix them, So I will not touch for now , will await better data.

 

Only if I could get the forests with the mesh areas I have done would be nice , but again I am a layman here

I don't know the if mesh will be done because lot many SRTM have holes and I have no idea how to fix those.

Well, usually with problems like this, you end up with the need for some kind of GIS tools to aid you.

The - I think - best solution with SRTM 1sec holes is, to back fill them with lower resolution - but still good enough - SRTM 3sec data.

 

In the following blog post, they describe an approach which uses the open source (command line) GDAL toolset to achieve this:

• http://fyeahgis.tumblr.com/post/118248078025/filling-holes-in-terrain-data-using-gdal

Even though I rely on GDAL a lot too (for a lot of different, other tasks) I never tried the above solution (I used some freaky, Laminar internal tools for it ...).

Well, usually with problems like this, you end up with the need for some kind of GIS tools to aid you.

The - I think - best solution with SRTM 1sec holes is, to back fill them with lower resolution - but still good enough - SRTM 3sec data.

 

In the following blog post, they describe an approach which uses the open source (command line) GDAL toolset to achieve this:

• http://fyeahgis.tumblr.com/post/118248078025/filling-holes-in-terrain-data-using-gdal

Even though I rely on GDAL a lot too (for a lot of different, other tasks) I never tried the above solution (I used some freaky, Laminar internal tools for it ...).

 

Thanks Andras , appreciate it. will have a look and hopefully it hits my gray matter.

 

Will try it tonight.

I am trying what Andras has suggested but its complicating. But will keep trying till I get it.

What problems are you having?

What problems are you having?

 

The problem is the DEM files have missing data , hence meshtool does not create dsf.

Haven't been working on this because I am doing air shows for the Indian Air  Force in the Mig 21 , but I will get back to it. 

The Mighty DCS Mig-21 !!!!

 

I'm on il-2, trying to master the P-40 E...Tricky as it is, it's becoming one of my preferred IL-2 Battele of Moscow aircraft...

@jose

 

Yes the Mig21Bis module is the best in DCS.

 

Why no Mustangs ? 

IL-2 doesn't have a Mustang yet... Maybe on the next theatre.... I would like it to be the Pacific.

 

IL-2 has the best proo flight dynamics - ahead of DCS IMO