Bulk SRTM optimization

[Guest Dr. Prilicla]

Hello everyone!..Sometime ago i've tried to create some small meshes from the SRTM data for my own use and followed probably the default way (BlackArt then SRTM-To-BGL). That worked quite good, so now i decided to go a little bit further and create some larger meshes, but encountered some errr... difficulties.The plan was to follow the same procedure as before. Optimize the SRTM Data to get rid of noise and faults in the file using BlackArt, then convert the optimized files into BGLs.Unfortunately, i've not figured the way the Bulk Processing for the BlackArt works, 'cause adding one-by-one file in the Add Files dialog seems to be err... quite time consuming operation. Copy-Paste the information with the location of the files doesn't help the cause, since the programme seems to ignore these pasted entries.After stumbling into this situation, i've decided to go around and first bulk-merge the SRTMs and then try to optimize it. I've tried using Microdem, but it merges the files into .dem files rather thant srtm. I've also tried FSDEM, but couldn't make it work with mutiple SRTMs. So, can you suggest me the way to bulk process the SRTM data?Probably, i simply miss the point somewhere... if someone can help me i would appreciate it. Ta,Max.

[Guest andy58]

I found the best solution was to process the files with SRTM to BGL using 20 interpolation passes, fixes all but the largest voids, then check the BGL and reprocess only those files with Blackart that really need it. Then run SRTM to BGL again.Inland lake levels, natural depressions that you want to retain and large voids were the only real problem as the sealevel is usually cropped by FS anyhow.When I made Ozmesh I devised a way of interpolating about 200 files with SRTM to BGL in a 4 high x width of continent band and manipulating the inf file to produce 3 x 3 deg. seamless BGL's. There were only 3 or 4 of the 3 x 3 deg. cells that needed reworking for the entire continent.Andy

[Guest Dr. Prilicla]

Thanks for the response, Andy. I've decided to follow your advice and see what i can achieve "SRTM to BGL" utility :)Initially i've encountered some strange behaviour of the resample module, like unexpected finish of the resampling process with no error information and final size of the .bgl around 150Ks (wrong info file i suspect)Anyway, seems to be that "reasonable" quantity of .hgt files can be processed in a reasonable amount of time with a positive result. The only question is how 700+ Meg. bgls are going to affect the FS performance... %)Cheers,Max.

[Guest andy58]

There should be no problem, FS only uses the portion you are flying over at that time.I had problems too in the early days but I think that was when I incorrectly set the destination file boundary directives northlat etc. (reversed and it tries to make everything but the area you expected and runs out of resources). You need at least 2 adjacent hgt files for SRTM to BGL to work on. Also make sure tmfcompress and tmfmerge are present, and don't use Resample Ver 1004. Check the resultant BGL with tmfviewer.Andy

[Holger 0]

Howdy,I just wanted to re-emphasize that the interpolation routines of SRTM2BGL and Blackart yield vastly different results. If you're interested in a quality add-on mesh (which means "looking good" in addition to as accurate as possible) you shouldn't use SRTM2BGL for any voids larger than 5-6 pixels in diameter.A while ago I posted comparison images in this thread - http://forums.avsim.net/dcboard.php?az=sho...ing_type=search - but they have since disappeared. I re-uploaded the images to my website so here they are again in a bit more permanent form.1. SRTM2BGL with 20 interpolation passeshttp://holger.fs-shipyards.net/images/DEM/...-%20partial.jpg2. MicroDEM, with search radius of 2000http://holger.fs-shipyards.net/images/DEM/...M_fill-2000.jpg3. Blackart, with 0 LSQR and 1000 Laplacian iterationshttp://holger.fs-shipyards.net/images/DEM/...0_LAPL-1000.jpg4. Blackart, with 1000 LSQR and 0 Laplacian iterationshttp://holger.fs-shipyards.net/images/DEM/...1000_LAPL-0.jpgAlso, keep in mind that the quality of the source data very much depends on which region your project is in. SRTM data is poorest in areas with very steep terrain, glaciers, and fjords. Thus, Australia is probably pretty good whereas New Zealand pretty horrible.Now, what I would like to find out is how to process "finished" SRTM files in Blackart that are available in the new seamless format at http://seamless.usgs.gov/ ?Cheers, HolgerP.S.: forgot to add the fifth image, the one in which I used SRTM30 data to fill the holes in the SRTM3 data:http://holger.fs-shipyards.net/images/DEM/...-%20partial.jpg

[Guest jimkeir]

Howdy right back atcha! :-waveJust out of curiosity, how about running the same source data through Slarti? Be nice to see the comparison.SRTM=1 (or higher, to enable more aggressive noise filtering)NormalMesh=trueJust a thought - Slarti will do SRTM merging too and can be used from batchfiles, so that may help to process large areas.Jim

[Holger 0]

Hi Jim,doh! My favorite design program and I don't even remember the SRTM option. x( Mea culpa.I shall proceed and post some pictures right away.Cheers, Holger

[Guest Dr. Prilicla]

mmm, another tool to test :)so far seems to be pretty straightforward and the manual is definetely a plus (memory consumption estimation, tutorials for dummies like me, like it) :9Quick question... since multithreading support's gonna be implemented in future commercial release, has anyone tried to run simultaneously, say, two instances of the current release on multiprocessor system?.. (-:Cheers,Max.

[Guest jimkeir]

Cheeky beggar :)There's nothing to stop you running more than one, but of course you'll use more memory. I've been muttering about the 'payware' one for ages without doing anything about it - I'll fix it once I get back off holiday in a few weeks. Promise. The last delay was over the name - Slartibartfast is probably copyright, so it'll need renamed.As an aside, I bought myself a dual-Xeon setup recently and Slarti is the only program I've seen which maxes out all four CPUs :-wink2 - the multi-CPU stuff does work!Anyway, Holger's pointed out that Slarti doesn't read BILs saved from Global Mapper correctly, so I'll take a look at this and try and fix it. It looks like GlobalMapper does something to the 'undefined' values that I look for, so they're not picked up and patched correctly.However, it does read unprocessed RAW, and certainly handles the GeoTIFF format downloaded from the USGS Seamless site. Here's a quick example:[H3]Unpatched[/H3][H3]Patched[/H3]The patched bits are a little on the spotty side but that looks reasonably like 'real' terrain once it's in the sim.Cheers,Jim

[Guest jimkeir]

Hi all,I've updated Slarti's mesh patching code a little. It makes the patching look more seamless and removes most of the visible spots that were there before. Also now saves .hdr and .prj files when it saves mesh out, so you can load it and view it in GlobalMapper. Changed the way that undefined mesh was handled so it will load mesh that's already been processed by something else, and last, there was an incorrect offset when working with mesh without using HQSample.Download links:- http://www.jimkeir.co.uk/FlightSim/SlartiFree.exe- http://www.jimkeir.co.uk/FlightSim/SlartiInstall.exeCheers,Jim Keir

[Guest jimkeir]

Hi again,Just noticed I've left a DLL out of the packages. Sorry...http://www.jimkeir.co.uk/FlightSim/AutoGen/index.htmlJK