Shuttle Radar data as LOD9 mesh: a comparison

[Holger 0]

Howdy:Well, I couldn't resist and started playing around with the new 3-arcsec Shuttle Radar SRMT data, released for the entire North American continent and available at ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/N...America/3arcsec. :-)Below is a series of screen shot comparisons for areas near my home town, in British Columbia's Okanagan Valley.I used four 1-by-1-degree SRMT tiles, merged into one tile, filled some data holes by merging with my 250-m (LOD7) data, resampled as DTED at 3-arcsec resoultion in MicroDEM (probably an unnecessary step), transformed to .bsq format with John Childs' utility (BTW, he's got a new version that can handle files bigger than 9MB, called bigbsq.zip, available at http://www.terrainmap.com/, thanks John!), and converted into .bgl format via the FS2002 Terrain SDK tools. Took all of 30 minutes to complete.The screen shots speak pretty much for themselves. Basically, I see a massive improvement over the default mesh, a decent one over my LOD7 mesh, and even a light improvement over my LOD9 mesh in the Monashee Ranges, which could be due to the less-than-perfect source data I had for that area. What these particular images don't show is that greater detail, as usual, often leads to bigger problems with the FS2002 scenery: roads, lakes, shorelines, etc. In other words, while the initial mesh-making will be quick, the "post-production" might take a while.Cheers, Holger

[jkanold 0]

This is fantastic news for Canada. http://members.rogers.com/jkanold/jimlogo.gif

[Guest vlada stoje]

Hi Holger,thanks for very nice pictures! I agree with you, Dick and Jim Childs (the filling of the data holes from other sources, the optimum density LOD9 for 3arcsec, and namely "Earth to NASA: just give us the data!")As a broken-hearted citizen of a different continent I am just playing around with the interpolation of the potholeshttp://www.volny.cz/stoje/scen/N53W120.jpgCheers

[Holger 0]

Hello Vlada:that looks interesting - what tools/procedures are you using? And how would they work in more contiguous areas? Most of the larger holes I've seen appear to be located in lakes and inlets, probably due to the lack of reflection back to the radar's receiver. They shouldn't pose a big problem, even if just filled in with GTOPO30.More generally, I have to take back a bit about what I said regarding the coverage of the data: it's North America up to ~N61 degrees (the tiles are referenced to their SW corner), so mainland Alaska, Yukon, NW Territories, Nunavut, and parts of Northern Quebec are missing. That's because the area wasn't mapped by SRTM in the first place (see http://www.jpl.nasa.gov/srtm/coverage.html).On the other hand, the coverage extends a bit south of Mexico, up to N15, including the northern half of Guatemala and Honduras.Cheers, Holger

[jkanold 0]

I would also like to know what tool you are using.http://members.rogers.com/jkanold/jimlogo.gif

[Guest]

I just wanted to post this to drive Jim Kanold nuts! LOL ;-)This is the west end of Lake Ontario. In the bottom right-hand corner you can see the Niagara river and if you look really closely you can see the entrance to the Welland canal further west.Dark blue is missing data...-david-

[jkanold 0]

LOL.Way ahead of you. I have Detroit to Ottawa, North Bay to Buffalo done.And what a difference!!!!!Yes, the Burlington Skyway is in a hole at one end.http://members.rogers.com/jkanold/jimlogo.gif

[jkanold 0]

David,Have you made one of your tools capable of DEM editing?BTW, LOL Where have you been for the last year and a half? LOLhttp://members.rogers.com/jkanold/jimlogo.gif

[Guest vlada stoje]

Hi guys,sure the best way how to remedy the holes in SRTM files is the filling with the data from other sources, but the interpolation could be also useful, when the other data are not available. The experiment above was made in the Surfer 8 ( www.goldensoftware.com ) . There are several different methods for the gridding of the irregularly spaced source data, the very good method with reliable results in most cases is the

[Guest]

I have written a program in C to 'patch' the data using DeLaunay interpolation (where possible) and cell averaging elsewhere. While not as precise as Vlada's method above, it seems to give reasonable results. Burlington, Ontario original and patched (please ignore the colour map, I was too lazy to re-adjust it)If anyone is interested, I can make the C code available. It was written for Unix (Solaris/SPARC) not Windows, so it would require a bit of playing around with to make it work on a little-endian system (Elrond?)If you simply want a couple of cells cleaned up, drop me a line and I'll put them on my to-do list. I am processing about 640 cells over night tonight.So, what are people finding are the best values for the inf files? Is it better to combine 4 cells into a 2 by 2 grid or 16 cells into an 8x8?-david-

[Guest]

Note to self: 4 x 4 = 16 (sigh!)-david-

[Holger 0]

Hi Vlada and David:very elegant and sophisticated methods, those two. If you want to try your respective methods on a challenging tile, try N50W125, a section of the British Columbia Coast Ranges. The central part of that tile looks as if someone fired a shotgun blast at it. Most of the larger holes are water but they border steep fjord-like mountains and there's lots of smaller holes in mountainsides as well.The only tools readily available to me are MicroDEM's 'Edit DEM' feature (hand editing, good only for very small holes), and the 'fill DEM holes' function (inverse squares weighting), with a user-defined search radius and the option of 2- or 4-directional search. The latter method works well for smaller holes, even in steep terrain but does not so nice things to the borders of larger holes. I used successive increments of search radii to fill the larger holes but it's not satisfactory. Kriging or DeLaunay triangulation probably yield better results.Since most of the larger holes are water surfaces, another option might be to make a water mask from GTOPO30 data (not quite sure how since we'd need both ocean (=0m) and lake elevations) and merge that first with the SRTM tile to fill the large holes. Then use an interpolation method to fill the remaining smaller (non-water) holes.Filling holes in mountains with GTOPO30 data probably won't work well since those data tend to be lower in elevation due to the smoother surface. I have the 250-m source data for all of BC which seems to do a better job but there the problem is a slight mismatch (offset) between the two sets of data. I might be able to adjust one of the sets to create a better match but haven't checked whether the offset is constant/linear.Speaking of offset: have you people out East noticed any regular mismatches between the SRTM data and the FS2002 default scenery (rivers, shorelines, etc.)? Here in the West there seems to be a slight general offset (~100-200m) to the North, though it is less pronounced than the offsets I had to deal with for my LOD7/LOD9 BC meshes. To adjust for that, I take a few on-screen measurements and then adjust the Lat/Lon coordinates in the .inf file accordingly.So far I have used 3x3 and 2x2 sets of tiles. I wouldn't go much larger based on my experience with slighty different offsets in different areas.Cheers, Holger

[Guest]

Regarding the west/north drift.Are you adjusting for the 1 column and 1 row overlap in the data?The edges overlap the next segment. The real data is 1200 x 1200 for 3 arc-seconds.From the data description:SRTM-1 data are sampled at one arc-second of latitude and longitude and each file contains 3601 lines and 3601 samples. The rows at the north and south edges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell.SRTM-3 data are sampled at three arc-seconds and contain 1201 lines and 1201 samples with similar overlapping rows and columns. This organization also follows the DTED convention. Unlike DTED, however, 3 arc-second data are generated in each case by 3x3 averaging of the 1 arc-second data - thus 9 samples are combined in each 3 arc-second data point. Since the primary error source in the elevation data has the characteristics of random noise this reduces that error by roughly a factor of three.-david-

[Guest]

Man! That is very bad data!My interpolator does very well at patching small data areas, but you can easily see the smearing effect when interpolating over larger areas. I could add a fractal resampler to add some noise, but I think Vlada's methods make more sense in situations like these.-david-

[Guest tcable]

I was just looking at the data of my local area of Suburban Boston, namely 41-52-28.565N / 071-01-00.753W or so, I see this- Not nessecarily the best data :( most of what you see is water with lots of noise (waves? too linear for that IMHO) Plus where I live (KTAN) is missing from the NW part of the image.That's Cape Cod, Marthas Vineyard and part of Nantucket. Even the Cape Cod Canal is poorly represented- far too many fills in the canal- I can understand seeing the bridges (all 3 of them) as returns, but not this. However the areas that are consistiently land doo look great. I have not compared this to other mesh info that we already posess. Now I need to look ar toehr areas like Pittsburgh or Asheville, NC.I just went and looked at the 1sec data and it looks better, but still noisy...And as far as national security goes, Why provide teh US data, but not overseas? Do we really care about iritating the mapping agencies of other nations? I understand that the majority of this data is payware elsewhere.As we speak I'm leeching both 1 and 3 sec data :) Get it while free, even if 'raw' unprocessed data.Tim