Contours show up in BaseCamp, but not on 62stc

[hwstock]

...  I have compared the USGS DEM-derived contours, in the region around Picacho del Diablo, Pico Risco, and Cerro Pescadores, with the maps from 2 commercial vendors who used INEGI sources.  The contours were quite similar, down to the same misregistration.

I take this to confirm USGS's release note saying 'The data were provided and quality control conducted by INEGI. Topographic staff at USGS EROS processed the data to improve edge matching, making the dataset seamless within itself and along the U.S. / Mexico border.' which I included in my post on June 28th.

I remember that post. That was part of my motivation to use the USGS data, as it seemed much easier to access.  If the USGS took the data, regridded it, and went to a new geoid model, that could explain how basically 1 m data got a fine "correction"  that causes the odd contours in mainly flat areas.

It's hard to say what is the test of similarity here; qualitatively, the contours look similar, but little changes in the contouring software change the appearance.  However, INEGI topo maps (which I have available as TIFFS) show more detail (perhaps not real) than my USGS-based contours (or the two INEGI-derived commercial Garmin maps) show.

In any case, my efforts to make a more accurate map are getting a bit like putting lipstick on a pig, especially given the USGS LIDAR vs. NED comparison.

[maps4gps]

That was done in 2004, 9 years ago.  More recent info on LIDAR indicates that it is not as accurate as one believed.  The RMSE for ASTAR is considerably more than for SRTM.

[maps4gps]

My understanding is that INEGI created 1 arc sec gridded elevation data from their 1:50,000 paper maps.  One file per printed topo sheet; if I remember correctly these are 20x30 minute in size.  USGS took these files and put them into their standard 1x1 degree structure.  I expect the edge matching was along the original file boundaries; although I remember an instance where there was a difference of 150 meters (yes meters) along the boundary.

USGS's agreement was to make the data provided by INEGI more readily available and not 'correct' it.  Likewise for the data on Canada from RNCAN.

[hwstock]

I'm not saying LIDAR is absolutely correct; I'm pointing out the large and systematic differences between LIDAR and NED (which , I'd hazard, are mainly errors in NED), and what that could mean for contouring the DEMs.  We earlier discussed why so many DEM chunks seem to show a shift of 50 meters or more; that particular figure shows a possible reason... and also indicates why it may be a futile task to quibble over a few meters.  I am biased to "correcting" the DEM so the mountain peaks are aligned; but if the "real" correction is slope- and aspect-dependent, no simple affine mapping will get it right for the entire region.

[hwstock]

Maybe we are quibbling over what "correct" means.  If you regrid data and change the reference for sea level, you will invariably end up with z values that don't exactly match the original data set.  Going to a new geoid involves some long range, substantial corrections, and some lower amplitude, shorter-range corrections.

For heuristic purposes, try a 2D example.  Suppose the original grid has z to just 1 meter, and looks like this:
^
|z

4o
3ooo
2oooooo
1ooooooooooooo
  123456789ABCD ->x

...and you must regrid to an x-value that is offset by 0.01. Linear interpolation among the z values will invariably make the new values non-integral -- in fact they will be off-integral by small fractions of a meter. That's just the grid "correction," not a geoid "correction."  I guess it might be better to call these adjustments; no one is saying the original data were "wrong."

This article is from 2006:
http://www.ngs.noaa.gov/CORS/Articles/OPUSMexico.pdf
The article talks about constant improvements in the geoid, but I have no idea how one would track what the reference status was when the data were transferred to noaa/usgs.  Around here in NV, the geoid change (since surveying) caused shifts of about +1 meter or more for benchmarks -- but there are some areas that "lost" elevation.

[maps4gps]

I think it is time to get an authoritative opinion on the issue; as you mentioned in one of your earlier posts, ask USGS.  The telephone contacts at ned.usgs.gov have me send in issues to [email protected]   

[hwstock]

I guess we differ on that.  I don't think it is an issue they can "solve" -- it's a natural outcome of data being adjusted so there appears to be more precision than there really is.  Few people will ever care; it's just a case of caveat emptor.  And we aren't even buying... we can just warn other people of the pitfalls.  The data are as good as they advertise.