What you describe, Jim, seems like a likely explanation for large scale
offsets. A good check of a location like Felipe's which shows large
absolute errors between GPS and SRTM would be to compare two points with
a large know relative difference in elevation and then compare that
difference with the relative elevation difference predicted by the SRTM
data. If the relative differences agree between GPS "truth" and the SRTM
data then it's probably some sort of problem with the reference geoid.
And, of course, Jim, you are right about the general area where I
surveyed. It has probably been measured to death with various radars
over the years. The particularly area I checked is probably a good 15 to
20 miles east of the area where JPL sets up their calibration targets.
Unlike the cal target area that survey location was at a much higher
elevation and a portion of it is pretty rough terrain. Also, it is not
the secret lair. I passed on that particular piece of land as it was a
little too far from civilization. Only Alfred and Robin know the
location of the real secret lair :-)
73, Mike W4EF/6...............
On 8/21/2011 4:22 PM, Jim Lux wrote:
> On 8/21/11 2:55 PM, Michael Tope wrote:
>> Using the Radio Mobile program, I found the SRTM 1 arcsecond elevation
>> data to match very well with GPS readings I took in the high desert area
>> just north of Los Angeles (to within a few feet typically). The 1
>> arcsecond data set has a pixel size of about 30 meters x 30 meters, so
>> for any given pixel the reported elevation is the average of the
>> elevation over that pixel. For gently sloped terrain this average
>> elevation should be a very good approximation. In areas where the
>> elevation changes rapidly over the pixel area, there will be more
>> disagreement between the elevation reported in the SRTM data and the
>> actual elevation. IIRC the requirement on the SRTM instrument was 16
>> meter absolute elevation accuracy and 10 meter relative accuracy, but
>> the folks I recall talking to who worked on the instrument were elated
>> that the performance was typically much better than the minimum
> If there's a big discrepancy between SRTM and "on the ground", I'd look
> for mismatches between the reference ellipsoid that SRTM uses and local
> sea level datum. There can be surprisingly big differences. If the
> ellipsoid happens to be 100 meters above local sea level, then SRTM data
> for the beach is going to show -100m.
> The mean sea level of the earth is not smooth to 100s of meters with
> respect to a perfect ellipsoid. (e.g. the Gulf stream sits several
> meters above the surrounding ocean, and the ocean surface over deep
> trenches is depressed)
> Not only that, but there's both a WGS84 ellipsoid and a WGS84 geoid
> which can differ by 10s of meters in a given location. SRTM data has
> been published with both references.
> These kinds of things are large scale offsets, so they basically make
> all the elevations high or low for 10s of km, and wouldn't have much
> effect on HFTA, which is more about relative elevation.
> For places with poor radar reflectivity (water!) with poor SNR, the
> original processed data is known to have spurious peaks/holes on the
> order of tens of meters.
> There's also the well known "tree canopy" problem with radar data sets.
> In dense forest, the surface appears to be the tops of the trees.
> W4EF's secret lair in the high desert is located in an ideal location
> for SRTM to work well (aside from being within a few km of some of the
> calibration targets, I'll bet). It's relatively smooth terrain, has no
> forest (not even a whole lot of trees), and there's no significant body
> of water more than a couple meters across within 100km, except for
> aqueducts and drainage ponds. It has probably been SAR'ed by
> researchers more than any other few square km in the world.
> TowerTalk mailing list
TowerTalk mailing list