SRTM Eurasia available !!!!!!!

[Guest schampi]

HI, allSRTM Eurasia is being released today there: ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/Eurasia/regards, Jean-Pierre

[Holger 0]

Hi Jean-Pierre:thanks for the heads-up - nice find!It's pretty exciting to have those data available and for many countries and places of Eurasia we can expect to see great add-on meshes. However, the 90-m SRTM data are in the same 'preliminary' state as the files released for the Americas, with the same vast void areas (missing data) in steep valleys, on ice-covered mountains, and other sites. Below are snapshots of the raw data for western Switzerland (guess where Mt. Blanc is, or rather should be?) and the Mt Everest region (Everest is the half-eaten red area in the center).http://forums.avsim.net/user_files/46464.jpghttp://forums.avsim.net/user_files/46465.jpgObviously, we are in serious need of better merging (with low-res data) algorithms to make these areas look realistic; simple (or even high-tech interpolation won't do for the large void areas). I've done a few more trials with some of those algorithms but with limited success. Anyone out there having good results?Just so you don't get too scared/disappointed, some areas look really good, as this shot of SW Ireland proves. Go, mesh designers!http://forums.avsim.net/user_files/46469.jpgAnyone making SRTM-based meshes (and willing to share the results), please consider the issue of potential systematic displacements. You can easily check for and adjust this with the help of TMFViewer and an overlay of the default stream or lake .bgl files; making these adjustments, where necessary, can make a huge difference with respect to lake elevations and ocean/lake shorelnes. Keep in mind that mesh files are the "foundation" that other FS designers will use to place their scenery add-ons and other enhancements.Also, we have new tools and methods for 'batch' corrections of lake elevations, like Gilles Gauthier did for his eastern Canada SRTM meshesand I for my western Canada SRTM files. Gilles and I have been working on a tutorial of the two alternative methods and plan to make it available at avsim and elsewhere within a few days.Cheers, Holger

[rhumbaflappy 113]

Hi Holger.The SRTM30 data is the attempt to compile an improved version of the GOTOPO30 data, and would be the best bet for filling the voids.Meanwhile....The Eurasia data isn't perfect, but it would be the best we've had for free for Europe and Asia. :)Here's a pic of the coverage... the Yellow is the data:http://forums.avsim.net/user_files/46488.gifDick

[Guest vlada stoje]

Thanks Jean - Pierre! Uaaah, guys I am happy, now also all little hills in the surrounding of the airfields are finally visible, miam miam!!!CheersVladahttp://forums.avsim.net/user_files/46534.jpg

[Holger 0]

Howdy:Dick, very nice reference image - thanks for sharing (you don't give a source so I assume you have some spiffy tool of your own to read the file names?).Vlada, I thought that you'd be happy about this release :-) And that image DOES look like eastern Europe (or, at least, like my mental image based on my limited travels to the region). I wonder whether you'd be able to even improve on a few areas by merging with ASTER data, where available?It will also be interesting to compare the SRTM data with the mesh files compiled by Nanucq Faitman (available at avsim), as the DTED1 data used as their base have the same cell spacing (3 arc-sec; http://www.globalsecurity.org/intell/systems/dted.htm) but is compiled from more traditional geodetic data collections.Similarly, the great freeware mesh for Japan (http://members.at.infoseek.co.jp/fsclubnet/index.html) will provide another base for comparison, though I assume that the 50-m data used for the high-res version will prove superior to SRTM. I agree that SRTM30 data are probably our best bet for merging with SRTM3 data but my point is that a simple merge will often not look better or be more accurate than simple interpolation algorithms: the "smoothing" (i.e., less pronounced ridges and valleys) of the SRTM30 data almost always leads to unsightly cliffs at the boundaries of a merged area. I don't have any picture handy of this problem but the ASTER DEM thread in this forum has some images of those obvious edges too. I have looked into alternative methods and the following is the one that seems to have good potential. It predicts the elevation in the void areas from the difference of known values between the SRTM3 and the SRTM30 data. I'll try to explain it with a simple example of three neighboring cells in an elevation raster (the unit doesn't matter but you can think of it as meters or feet ASL):70-100-80 -> this is the true elevation profile; note the 'peak' in the center70-n/a-80 -> these are the SRTM3 data, with the center value void (missing)70-75-80 -> using a standard interpolation (the mean of the neighbors), the hill has become a gentle slope60-80-70 -> these are SRTM30 data (resampled to 3 arcsec); note the lower overall elevation values due to the generalization/smoothing inherent in the data70-80-80 -> merging the SRTM30 data with the SRTM3 data gives a more accurate result than the interpolation but still not the true 'peak' (more typical would be even lower SRTM30 values, which would result in a dip instead of a slope)10-n/a-10 -> this is the difference between the SRTM3 and the SRTM30 data for the grid cells we have data for70-90-80 -> this is a new 'predicted' elevation model, derived from adding the average difference values to the SRTM30 values70-90-80 -> this is the final elevation model after merging the predicted model with the SRTM3 data. It's still not 100% accurate but the 'peak' is visible.What works nicely in this example turns out to be more complicated when trying to apply it to a full grid. An algorithm that uses only immediate neighbors of the void areas for the prediction might be ideal but is not easily implemented (due to the irregular shape of the void areas). More typical, one would use a global (i.e., the average difference computed for the full image) or local (i.e., a moving window of a specified size, say 12x12 cells) measure of the difference. I have tried the global approach but that didn't improve much on a simple merge because the difference values are more or less normally distributed (think 'bell curve') and thus the global mean is too small for the big differences that characterize the ridge areas typically missing in SRTM3. Also, the measure of difference between the two data sets could, alternatively, be a ratio or even a regression, all with their own pros and cons.Anyway, since those first trials, I've got distracted by other projects but am interested in hearing about other people's ideas and tests. I hope that my rambling wasn't too confusing ;-)Cheers, Holger

[rhumbaflappy 113]

Nice possibilities.Default FS2004 mesh:http://forums.avsim.net/user_files/46575.jpgSrtm Eurasia merged to SRTM30, resampled for LOD8:http://forums.avsim.net/user_files/46576.jpgI'll need to check some data for the placement of roads and rivers to determine if an offset is required... but the Alps look much better with the new data.Dick

[rhumbaflappy 113]

Hi all.The SRTM mesh doesn't align with the default design elements any better then the default mesh. My first test with more accurate roads, streams, and lakes is very encouraging. Now that we've found that data is in LOD5 chunks in the default LWM and VTP BGLs, we could replace them on an LOD5 basis, and add SRTM based mesh to the packages. It will result in a MUCH greater degree of accuracy. Default:http://forums.avsim.net/user_files/46953.jpgStream added from MapPoint map:http://forums.avsim.net/user_files/46954.jpgSRTM with the new stream:http://forums.avsim.net/user_files/46952.jpgThis image was oversampled SRTM Eurasia ( LOD9 ) with Ground2K4 added streams from Microsoft's Mappoint website maps ( reprojected to Geographic ). Even that crude method was close, and much better than the default. The picture was with the -10 offset in the terrain.cfg file changed to "offset=0".More care with the drawing in G2K4 might have resulted in an even better fit for the stream.Dick

[Holger 0]

Hi Dick:very nice! that's exactly the approach I took with the scenery enhancements (new roads, shorelines, and streams) in my SRTM/scenery package of the Canadian Rockies. Each of the two packages covers two full LOD5 sections, which allows users to remove the default LWM HP9*.bgl files. BTW, the fact that these files have very similar names (letter/number combinations) proved a problem for a few users - they renamed/deactivated the wrong ones.I was quite sceptical at first whether my Landsat 7 ETM base images (in Ground2K4), which came orthorectified, would match up well with the SRTM data but was blown away by the perfect overlap of my digitized linework and the STRM mesh. I don't know whether satellite imagery is available for free for other countries but can highly recommend their use for this kind of work.Obviously, some utility that takes existing digital vectors or polygons and translates/compiles them into a FS-ready LOD5 section would be even better.Cheers, Holger

[Guest vlada stoje]

Hi Holger,this is clever idea! In 1D case with 2-point border of the void I can imagine it clearly, but in the 2D case with irregular shape of the border it is little bit complicated. The voids in SRTM 3sec in the area of Czech Republic are quite small (water tables) and the simple interpolation looks to be sufficient. The experts of local airfields are reporting good fit with reality after 2 days of the uploading of the betaversion on http://vfr.meinlschmidt.org/ I think that the short waves in SRTM represent the reality and it isn

[Guest roman2109]

Hi all.Can anyone tell me what program can merge and export SRTM file format? Using SRTM_3ARCSEC_TO_BGL.exe I have a missed LOD row and cell on the border between my projects, so I need to expand border SRTM-files for overlaying with existing projects.

[Guest vlada stoje]

Hi Roman,this utility uses only original 1 arc degree SRTM files and the multisource option. It is possible to add another column/row of data files into the work directory and probably also change the coordinates in the destination section of the inf file. From other hand, the programs 3DEM and MicroDEM can merge the data and preprocess them for the terrain SDK.CheersVlada

[Guest PAtom]

hi vlada,do you know a freeware tool that supports that kind of interpolation you are using? ive tried srtm-to-bgl, fsterrain and mircodem but without aceptable results. even filling the "holes" of the 90m srtm with 30arcsec data doesnt give a good result special on very lage areas like the everest himalaya region. i dont expect to get a 100% realistic result until the final srtm data will be released, but i want to have a "procedure" which can fill those holes with nice looking "could-be" data.cheerstom

[Guest roman2109]

Thanks for reply.But I found the isier way. We have the ability to modify border coordinates in SRTM_3ARCSEC.inf. So the only problem is to add neighbour to your current project SRTM-files and calculate LOD coordinates.

[Guest vlada stoje]

Hi Tom,sorry I can

[Guest PAtom]

randomizing the gtopo30 data a little bit? thats a nice idea........until nasa releases the processed srtm data next year. but for now i am interested to compile large areas very quickly. srtm-to-bgl does a very good job in converting many srtm tiles in one step, just that the interpolation for big voids is not as good as the one, you are using. i can live with that since most of the voids are limited to icy high mountain areas while the rest of the world seems to be ok. thankstom