New SRTM to BGL v1.03

[Guest]

Just uploaded v1.03 of SRTM to BGL to the libraryNow supports both 1 arc second and 3 arc second data.Also added command line options for following :-- LOD (Level of Detail)- Don't interpolate (ie use the SRTM data as is without fixing holes)- Number of interpolation passesfor futher information type HELP at the command lineegSRTM_1ARCSEC_TO_BGL HELPAlso in 1.03 I have changed the way that the interpolator works so that now it fills holes from the outside of the hole to the inside of the hole in series of "passes". So specifying 5 passes would fix holes that are radius of 5 (assuming those holes are perfectly round). Any data that is not interpolated is left as is.In the next version (v1.04) I will try to make the interpolator use GTOP30 data to fill in any remaining holes.Matthew.

[Holger 0]

Hi Matthew:wow, you're cranking out the updates real fast ;-) Thanks for all your work!I'm actually not working with meshes right now and don't have the time to test-drive your utility but was wondering...Even if people manage to deal with the incorrect lake elevations there's still going to be the issue of horizontal (i.e., positional) offset. I've been going on about this for quite a while already so I won't get into details. However, maybe your utility could include an option for defining an offset to the Lat/Lon parameter in the .inf file? For example, my BC mesh tiles are offset by between 0.002 and 0.01 degrees each - doesn't sound like much but translates into several hundred meters. I figured out the offset myself (the procedure is described in one of my previous posts here) and then changed the .inf file accordingly. Since this involves quite a bit of trial and error, a semi-automated process as part of your utility would help a lot.Waddayathink?Cheers, Holger

[Guest]

Took a while to get registered in the file library but here's the linkhttp://library.avsim.net/esearch.php?CatID...02sd&DLID=31148Matthew.

[Guest]

hello Matthewgot problems with interpolation in your NEW version:Comparing the old 1.02 with 1.03, the interpolation does now reach to 0 meters or below.that means, what in old version rest on a "similar" altitude it creates now deep holes in the mesh... may it be a bug or not?for now, i use v1.02 altough it get 'good' results... oh da.... i delete it without having a copy... hmmm. well ok... waiting for a solution!greetingsFrancisattach 1 shows old version (with version 1.02) , 2 the new one... i tried with interpolation steps from1 trough 20, no good results, this one is default... out of a LOD9 mesh

[Guest sgreenwood]

Hi Francis,A much larger step value may help here.If so, think of those holes as a warning sign. While there may be a problem with the program, another explanation may be the size of those areas of missing data. I use Microdem to merge my data and fill the holes, and I have had to set the radius to over 100 to fill some of them. Others are much too large to fill well using interpolation techniques. (At least I prefer not to.) I fill the larger areas with data from other sources. Microdem has an Edit mode which allows you to select the area of missing data and determine the exact dimensions of the holes. Very helpful. And if you decide to use Microdem to fill the holes, you can then reload the patched dem and see what the patches will look like.I highly recommend supplementing the use of batch processing of data with the use of Microdem or a similar tool which allows you to see what the data looks like before processing it. This way you will be aware of what is being done during the processing, and which areas you may want to check out in the sim after installing the new mesh. Regards,Steve

[Guest]

I think you've said that you tried this already :- SRTM_3ARCSEC_TO_BGL InterpolationPasses=20And it still leaves holes?Ok, the holes must be pretty large. I will allow more passes in the next build, say 50,100,200,500. I'll upload it today or tomorrow.But beware that interpolating such large holes is not really going to give you good results.Interpolation with small holes (say passes=5) seems to work well, but trying to fill large holes by interpolation is not a real solution, since the filled holes will not actually resemble reality.In a future build I am intending to add filling of large holes from GTOP30 or other data. This is a much more accurate way to deal with large holes.Matthew.

[Guest rafaelds]

Matthew:The task of filling void data with anouther source is rather easy, perhaps even easier than you may think. Resample can do it for us. The only actual needed change in srtmInterpolate is that non-interoplated data should not be left as-is, but replaced with a standard value (-32767 would be good). Right now there are several different negative values in voids (I don't know why... It shouldn't).When one generates the INF file for processing, another 'source' section must be defined for the 'emergency' data, and the SDK says it must be the last one. With the field 'nullcellvalue' correcty set in the SRTM sources, resample will then look the value in the following source if it tries to read a null value.I also noticed you changed the cell dimension value to 1/1201 , but I think it should really be 1/1200. Let's imagine we have a DEM with a 10 minute resolution, for longitude 30W. Then we would have a file with 7 x 7 values, one row for lon 30'00, one for 30'10, 30'20, 30'30, 30'40, 30'50 and one last for 31'00. But the distance between the data values is 1/6 degrees (10 minutes), not 1/7 deg. The same applies to our SRTM data.I would also ask you another function in srtminterpolate, to raise negative elevation values to zero. Sometimes in oceans there are places with almost -100 meters and in my case the FS coastline is poor, making the hole appear on the ground. If you implement it don't forget to make it possible to switch off, for people making meshes of places below sea level.

[rhumbaflappy 113]

Hi rafaelds.The cell dimensions are dependant on the span divided by the number of verticies, minus 1. The elevations are assigned to verticies, just like landclass. But the cells are between the verticies. What is confusing is that the text that calls for "NumOfCellsPerLine" should actually read "NumOfVerticiesPerLine". There are always 1 less cells than verticies in the matrix. CellXdimensionDeg = ({longitude degrees span} / ( {number of verticies} - 1 )) CellYdimensionDeg = ({latitude degrees span} / ( {number of verticies} - 1 ))So, it's my belief that the cell dimension value should equal 1/1199!Dick

[Guest rafaelds]

I completely agree with you.So, our data spans for 1 degree, and we have 1201 vertices.That means dimension = 1 deg / (1201 - 1) vertices = 1/1200 = 8.333333e-4Rafael S

[Guest]

Thanks for that. I'll make the following changes to the next version1) Set null data to -327672) Add an option to SRTM_INTERPOLATE to set negative values to 0(eg SRTM_INTERPOLATE ZERONEGATIVES=Y)3) You said"When one generates the INF file for processing, another 'source' section must be defined for the 'emergency' data, and the SDK says it must be the last one."Can you just give me an example of how my INF should look? And i'll update the program to write the correct INF4) Cell dimension value... Im not really sure what it should be! Let me know whether its 1/1200 or 1/1199 (as suggested by rhumba) and Ill change.Also can you tell me the correct value for 1 arc sec data?Thanks,Matthew.

[rhumbaflappy 113]

Hi Matthew and Rafael.Rafael is right. I wrongly assumed the data was 1200 x 1200 when in fact it is 1201 x 1201. Sorry for the confusion.The correct formula is 1/1200.Dick

[Guest rafaelds]

Here's the end of the sources section in an INI:(Source45)Type = ElevS16MSBSourceDir = "."SourceFile = "S33W054.hgt_interpolated"NullCellValue = -32767Lat = -32Lon = -54NumOfCellsPerLine = 1201NumOfLines = 1201CellXDimensionDeg = 8.33333333333333333333333333e-4CellYDimensionDeg = 8.33333333333333333333333333e-4(Source46)Type = ElevS16MSBSourceDir = "."SourceFile = "S34W053.hgt_interpolated"NullCellValue = -32767Lat = -33Lon = -53NumOfCellsPerLine = 1201NumOfLines = 1201CellXDimensionDeg = 8.33333333333333333333333333e-4CellYDimensionDeg = 8.33333333333333333333333333e-4(Source47)Type = ElevS16LSBSourceDir = "c:gamessdkterrainBrasil"SourceFile = "br_s_g.raw"Lat = -16Lon = -60NumOfCellsPerLine = 8640NumOfLines = 7200CellXdimensionDeg = 0.00277777778CellYdimensionDeg = 0.00277777778You can also put a 'nullcellvalue' in the last section, but it would pretty useless as resample would fill voids with sea level in the absence of data, and it's better to be able to check the red areas in tmfviewer. Notice that sources up to 46 are SRTM data, and source 47 is my 'background' data. I like to use GLOBE data, because it is much better than GTOPO30 (GTOPO30 has most places derived from raster sources for south america) and it's also 30sec resolution. But this personal data has more resolution because I enlarged it 300% in photoshop using bicubic interpolation (this gives incredible results!).As you can see, there's a lot of information that would be necessary to put in the command line to define the properties of the background data and all other program options. So I would suggest using a 'SRTM.cfg' file instead. It could be like this:(Main)LOD=8Interpolate=YInterpolationPasses=10NullValue=-32767 (unnecessary, maybe)ZeroNegatives=Y(BackgroundData)FileName=DataType= {LSB/MSB}NorthLat=WestLon=NumCells=NumLines=XDim=YDim=It's just an idea, something I thought that could be handy.About the cell dimension of SRTM value, as Dick said, it should be the span of the data in degrees (in our case one degree) divided by the number of samples minus one ( 1201 - 1 = 1200 , for us). I guess he thought each 3sec data chunk carried 1200x1200 samples. But in my oppinion it should be 1/1200 (8.333333e-4).Thanks for your wonderful program. It's making it easy for me to make meshes for Brazil (using hundred of data chunks), places where the default mesh was totally wrong due to the absence of data good enough even for 30sec data.Rafa

[rhumbaflappy 113]

Hi Matthew.The 1 arc second data is 3601 x 3601... so the celldim value should be 1/3600 ( 2.7777777777777777777777777777778e-4, or perhaps 2.7777777e-4 would work as well ).Dick

[Guest]

Thanks, will put it in next version (today/tomorrow hopefully).Matthew.

[Guest]

Thanks Rafa for those ideas. I like the INF file idea especially. I will try to make these changes for the next build, hopefully today or tomorrow.Matthew.