Shift of DEM compared to other sources

deermap

Using ver 14.1, when I load DEM data based on USGS type DEM files, I am getting a shift, as compared to matching the same area USGS quad, contour shapefiles, etc.

I am working in KY Single Zone, and downloading that format from KY sites of .DEM, Quad map, and shapefile contours. The DEM is a 10m or ~30' grid, and is off at least on this site by X,Y 15,30 feet.

I tried online elevation data or SDTS DEM files with the same result.

Any ideas?

global_mapper

If your shift is only 15 or 30 feet from a 10m or 30m DEM base you are looking at a shift that is smaller than a single sample in your base elevation data, so you won't get accuracy better than that. For example with a 30m DEM your samples are over 90 feet apart, so a shift of only 30 feet is only a 3rd of a sample spacing and is likely just due to where the samples in the DEM are located versus where they were located when the contours were created for the USGS quad or contour Shapefiles.

Thanks,

Mike
Global Mapper Guru
gmsupport@bluemarblegeo.com
http://www.bluemarblegeo.com/

tjhb

Does this sound like grid-centred data being misinterpreted as cell-centred data? (Or the reverse, if the observed offsets are negative.)

global_mapper

If all of the shifts were in a single direction that could be it, but there haven't really been any shift issues in a very long time. Since he is working in State Plane and the topo quads were typically in UTM to start with, I'm guessing there have been reprojections since the contours were originally created, so the sample cells wouldn't line up at all anyway.

Thanks,

Mike
Global Mapper Guru
gmsupport@bluemarblegeo.com
http://www.bluemarblegeo.com/

deermap

It's just enough to notice. It's 10 meter or 30 foot. The shift is 15' AND 30'. I thought it might be a meters to foot conversion, but it's only half that. I thought it might be the cell origin, but if that, why is it 1/2 cell in the X, and a full cell in the Y.

i know it's on the edge of the precision of the data, but why would it be off?

deermap

While I am working in state plane, and my initial attempt was these reprojected files, I also tried in UTM and had the same issue. I figured if I got them to work in UTM, I could reproject later.

i just tried again. Started a new project, selected UTM, WGS84, meters, zone 16 northern hemisphere. The area I am looking at is KY Hwy 92 near Monticello, KY.

i have 20' contours based on USGS in shapefile, DWG, and the USGS raster. All overlay perfectly. Connect to online USA topo, good. Connect to online U.S. Elevation data, 10 meter resolution, generate contours, and the shift I describe exists?

global_mapper

It sounds like the USGS Shapefiles, DWG, and USGS topo raster were all from the same source, which may not be the same as the USGS NED 1/3rd arc second. Or even if they were, the USGS NED streaming from the server is reprojected to Web Mercator so the size and placement of the individual cell centers will not line up with whatever original source was used for the USGS topo contours, so there will be variance.

The only way that newly generated contours would line up perfectly with other vector ones would be if the new contours were generated from exactly the same source files without them being reprojected or resampled at all.

Thanks,

Mike
Global Mapper Guru
gmsupport@bluemarblegeo.com
http://www.bluemarblegeo.com/

tjhb

global_mapper wrote: »

The only way that newly generated contours would line up perfectly with other vector ones would be if the new contours were generated from exactly the same source files without them being reprojected or resampled at all.

Yes, but wouldn't you expect displacements to be evenly distributed, other things being equal? If they show a regular pattern, here apparently a half-cell shift to the east, and a full-cell shift to the north, does that suggest some specific cause?

the USGS NED streaming from the server is reprojected to Web Mercator so

Is this the most likely place for a shift to occur? I think Web Mercator effectively means storage in Geographic coordinates (in terms of Google's "special" spherical datum, using the semi-major axis of WGS84 for both axes).

Because degrees are so large (compared to feet or metres) the number of digits of decimal precision and the handling of rounding can make a large difference to accuracy.

For example, if a fraction such as 2/3 degree were expressed with only 4 decimal digits and rounded up to 0.6667, conversion to Geographic coordinates would entail displacement north or east by 0.00003333... degrees or 0.12 seconds, or roughly 3.6m or 11.8ft in the latitudinal axis. (In the longitudinal axis the linear displacement would generally be less, varying from 3.6m at the equator down to 0m at the poles.)

It would be unexpected for the USGS to express degrees using only 4 decimal digits, but it's the kind of unexpected thing that does happen, and it only needs to happen for one or two numbers--specifically for the tie points for a tile of elevation or imagery.

global_mapper

The Web Mercator conversion was actually done from the original 1x1 degree lat/lon tiles of 10m NED data. It is done at full precision so nothing is lost due to that, but because there is reprojection to an equivalent resolution, the actual location of the samples won't be the same because the exact placement of the grid cells won't be the same, even though they are approximately the same size on the ground. In Global Mapper when resampling is done by default the new sample location will have a value calculated by interpolating the 4 surrounding samples.

However we don't really know how the original contours were calculated, they could have come from the 30m NED data or something else entirely. Even if they were from the 10m NED data, they were likely calculated from original UTM NED sources, which was then converted to lat/lon, then reprojected again to Web Mercator. It's possible in one of the steps before Global Mapper converted the data there was a systematic shift somewhere, or it could even depend on the contouring algorithm used by the USGS if those contours were in fact calculated from the exact same terrain. I know a while back some of the USGS SDTS DEMs for quads had a half-pixel shift that was later fixed, the contours could have been created pre-fix.

In any case the real ground accuracy of a gridded terrain surface will likely be in the 2-3 sample spacings range, so the difference is well below the actual horizontal position error of the NED data. I would just use the contours generated from the NED data in Global Mapper since it will exactly match the terrain data to give a good visual match rather than trying to use the other contour data that will be very hard to consistently match with anything other than the original terrain files.

Thanks,

Mike
Global Mapper Guru
gmsupport@bluemarblegeo.com
http://www.bluemarblegeo.com/