[GRASSLIST:16] Re: SRTM data transformation

[Wolfgang Zillig]

Hello Maciek,

thanks for your explanation! I don't need need an increased x/y accuracy 
but I was curious about the difference in altitude because I'm 
displaying also additional data which is based on this Austrian grid. 
But as the results show I can ignore (at least for the moment) this 
shift. If needed I can adapt my other data that it "lays on the surface" 
again. With the coarse grid of the SRTM data set it is probably not 
worth to think about it (especially in mountain area). The result is 
already quite impressive even if some details are  under expressed.

Thanks for all your help!

Wolfgang


Maciek Sieczka schrieb:
> On Tue, 07 Mar 2006 08:52:30 +0100
> Wolfgang Zillig <wollez at gmx.net> wrote:
>
>   
>> OK, one final question: are the z-Values also adapted to the new
>> region?  I was told, that in my case the difference should be about
>> 40-50m.
>>     
>
> I'll try to share what (I thik) I know. ANYBODY PLEASE CORRECT ME. Paul?
>
> In SRTM "Heights are in meters referenced to the WGS84/EGM96 geoid"[1],
> which is roughly an equivalent of the mean sea level [2,3] (the
> difference between MSL and geoid could reach several meters, but it is
> not an issue considering SRTM accuracy). If you reproject SRTM into a
> coordinate system based on ellipsoid other than WGS84 or GRS80 (like
> Bessel in this case) you still want your elevation to be referenced to
> the mean sea level - the same DEM in different coordinate systems
> should have the same elevation (cosider elevation as an attribute,
> rather than as a coordinate in this case). And this is well achieved
> using 2d only transformation.
>
> Now please note that if you use 3d transformation for your SRTM,
> your Z coordinate will be shifted down about 40 m (as you are
> transforming to from WGS84 to Bessel ellipsoid - EPSG 31285), which you
> propably don't want. You propably would rather preserve the SRTM's
> elevation, the "real one".
>
> What 3d transformation would improve however, is be the 2d positional
> accuracy - reprojectiong in 3d would give you few centimeters better.
> Thus if you need it, the way to go could be: extract SRTM rasters'
> midpoints with elevation to a text file (r.stats -g > output.txt), use
> cs2cs to transform it, then replace the output's Z coordinate (as it is
> now shifted circa 40m down after 3d transformation) with an original
> elevation (UNIX text tools), import such an ascii data set into Grass
> (v.in.ascii) and trasform into raster (v.to.rast) or interpolate
> (v.surf.rst). But, as the actuall 2d position accuracy improvement
> would be circa 3-4 cm for mountainous area and even less for lowlands,
> it might be not worth the effort, at least not in case of SRTM.
>
> Again, I only wrote what I think I know. Please correct me if anything
> is wrong with my thinking. I'd be glad to sort this issue out for good
> for me too.
>
> Maciek
>
> [1]
> ftp://e0srp01u.ecs.nasa.gov/srtm/version2/Documentation/Quickstart.pdf
> [2]
> http://en.wikipedia.org/wiki/Sea_level
> [3]
> http://www.esri.com/news/arcuser/0703/geoid1of3.html
>
> --------------------
> W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
> http://katalog.panoramainternetu.pl/
>
>
>