Edges in adjacent DEM files

[sanewcomb]

The problem I am having with using DEM data is the seams between DEM files are visable. To my surprise, this even happens when viewing adjacent DEM files from original UTM files, such as those from the site from Tom Harvey. It is a bigger problem in files obtained from the National DEM seamless set, even though this set should be "seamless". Since TF does not recognize geographic coordinates, the files from NDEM must be converted. This ends up in large gaps when the area is broken up by the server:

http://mywebpages.comcast.net/steve_n....ver.jpg

Even when it is overlapped, by selecting overlapping areas on the NED server it is visible:

http://mywebpages.comcast.net/steve_n....ver.jpg

The DEM files in the original UTM format also are discontinuous between files:

http://mywebpages.comcast.net/steve_n....all.jpg

Presumably this problem could be fixed by allowing TF to read DEM files saved with geographic coordinates. I believe the only seamless DEM data set is the national one, which is available in 1 degree resolution across the whole country. It's also available in 1/3 degree for much of it.

Steve

[Alan]

I didn't make mention of it for the last two betas, but I'm not finished with the interpolation methods.  What you're seeing on the original DEM files is the bicubic (either) giving up when any one of the 16 points is not entirely within a DEM, at that point it switches back to bilinear and doesn't match too well.

How much are you overlapping on the 2nd one?  I guess I'll have to try it out myself.

[Alan]

Regarding the overlapping data:  The code makes assumptions that you don't have duplicate data for any area, it's one of the reasons that it's fast.  It was really intended for the classic 7.5 minute NAD27 ascii dem files.  After I finish fully supporting them (with respect to edges) I'll look into other data sets.

[sanewcomb]

Quote (Alan @ Feb. 29 2004,2:09)

Quote

The code makes assumptions that you don't have duplicate data for any area, it's one of the reasons that it's fast.

For the most part I think you have made good decisions when it comes to performance and I would continue to opt for speed over perfect display.

Quote

It was really intended for the classic 7.5 minute NAD27 ascii dem files.

I don't think you'll be able to completely eliminate edge effects with the separate UTM files unless you create some sort of topo generator to create realistic elevations where the data is missing. Even this would create artifacts that the eye could pick up. This, I believe, is one reason they created the seamless NED dataset.

Quote

After I finish fully supporting them (with respect to edges) I'll look into other data sets.

Thanks. I've tried the different methods for getting data and I still think the seamless server is the easiest. You don't have to know the names of anything, just zoom in on the topographic area of interest and download it. The only disadvantage so far is you can get such a large area that the DEM files takes awhile to load. I downloaded the entire Grand Canyon area in one shot and it created a 177 MB DEM file.

In other words, the DEM data cache works better with smaller individual files, which makes complete sense. Most programs that can convert the data, however, can also break up the files into smaller areas, as well as the server itself.

I don't consider the overlap a major problem and I'll restate that between the two, I would choose speed over making the edges look perfect (unless of course it could be done with little penalty). It's not that noticeable when map data is overlayed anyway.

[mikewager]

I have had pretty good luck with subsetting NED data.  I downloaded all the DEM data for Colorado and cut it into 1x1 deg blocks with about a 1/10 of a degree overlap per DEM.  After some trial and error, I found the best results came from subsetting from a larger DEM.  This seems to eliminate gaps and the overlap data is identical.

The Blue dot sits at the junction of 4 DEM's.

http://www.rooney-eng.com/images/dem-only.jpg

Mike

[Alan]

After playing with overlapping data from the NED converted with 3DEM I found a few surprising things.  First, 3DEM doesn't do a very good job in converting to UTM.  The main problem is that after conversion some profile lines are not full length.  This is as it should be since it is UTM now, but the empty data should be marked VOID (-32767), but 3DEM is just filling in the minimum elevation.  This is a huge problem because it confuses TopoFusion into thinking that this DEM has the data for this area, when in fact it doesn't (because it should be found on the 'other' (overlapping) dem).  This is most unfortunate.

Anyway, I have gone to the trouble of adding in support for the geographic reference system.  In order to do it properly so that it doesn't get distorted away from the primary corner, there are some conversions taking place on each 'getElevation'.  Bottom line, it's a bit slower, but not much.

Don't convert to UTM using 3DEM!!!

Also, TF only supports WGS84 and NAD27 datums (does anyone have a DEM that's not in one of those two).  It's possible that NAD27 DEMs are slightly distorted the further from the northwest corner you get (for a 7.5 minute dem this is much much less than one meter).  But very large NAD27 grids could suffer.  For this reason, prefer WGS84 if possible (the NED stuff I downloaded is all WGS84).

[sanewcomb]

Quote (Alan @ Mar. 12 2004,2:06)

Anyway, I have gone to the trouble of adding in support for the geographic reference system.  In order to do it properly so

Hey, thanks for adding the geograhic coordinate format. I did not look what 3DEM was doing, but would agree just putting in min elevations is very bad. When the converted data are displayed in 3DEM, it doesn't show these min elevation points. I thought it was just throwing that info away.

The gaps between sets appeared in other programs as well, like dlgview, so when the grid is rotated I guess at least one line of elevation data is lost.

The seamless NED set uses the NAD83 datum, so this may be one reason it doesn't quite line up with the DRG data, although I thought most of that was based on the NAD27 datum, which would also cause problems I suppose with WGS84. I have found the individual DEM files line up the best with the DRGs from terraserver, although it will be interesting to see how well the original, geographic referenced NED files, line up.

BTW, if TF is ever ported over to a different data system that doesn't use UTM zones, then the geographic coordinate system would be a better way to show the entire data set, without gaps across zones.