Hi all,
does anybody know, how I can transfer a SRTM file to an other ellipsoid? My target region is within MGI-M31 (EPSG 31285)
Many thanks
Wolfgang
Wolfgang, import with r.in.srtm or r.in.gdal depending on the original format. Set up your new location with your desired ellipsoid, and use r.proj from your new location.
Hope this helps,
Ian
On Mar 6, 2006, at 10:42 AM, Wolfgang Zillig wrote:
Hi all,
does anybody know, how I can transfer a SRTM file to an other ellipsoid? My target region is within MGI-M31 (EPSG 31285)
Many thanks
Wolfgang
>
What happens if a big asteroid hits Earth? Judging from realistic simulations involving a sledge hammer and a common laboratory frog, we can assume it will be pretty bad.
- Dave Barry
-------------------------------------------------------------
This message has been scanned by Postini anti-virus software.
On Mon, 06 Mar 2006 19:42:19 +0100
Wolfgang Zillig <wollez@gmx.net> wrote:
Hi all,
does anybody know, how I can transfer a SRTM file to an other
ellipsoid? My target region is within MGI-M31 (EPSG 31285)
Setup target location, eg. using the EPSG code you mention.
In source latlong location set the region properly first, using
g.region, to avoid your output missplacement - due to SRTM cells are
not alligned to the resolution. If you use d.zoom, use g.region
afterwards to correct the region; see:
https://intevation.de/rt/webrt?serial_num=3961.
Now you could reproject the SRTM raster using r.proj. But an optimal
method, which disturbs the input data less, would be:
1. Transform your srtm to vector points r.to.vect.
Note. Grass vector engine is very memory consuming, so setup the region
only for your very area of interest. Otherwise r.to.vect might use all
your memory. System shouldn't freeze, but might get extremely slow
when all memory and swap are gone. Give it few days then ;).
2. Reproject the vector file to your EPSG 31285 location v.proj.
3. Interploate DEM. v.surf.rst should do fine for such a regulary
spaced input as srtm. Or use other interpolation method you prefer.
Note. If you decide for v.surf.rst then in step 1. you could speed up
the process by using r.to.vect -z. This avoids building the datable and
stores elevation as Z coordinate. This would save you a lot of memory,
especially if using DBF. However, if you prefer v.surf.idw you would
need the elevation stored in datable as v.surf.idw can't use Z
coordinate for input.
Cheers,
Maciek
---------------------
http://www.visanen.pl/ - Zapakujemy wszystko!
Produkcja i dystrybucja torby foliowe, papierowe, reklam?wki, opakowania kartonowe, ekskluzywne pude?ka
It seems that this was what I did, but I think that the height values did not change during r.proj. It is a bit difficult to prove, but I will start from the batch again that there is no error included.
Wolfgang
Maciek Sieczka schrieb:
On Mon, 06 Mar 2006 19:42:19 +0100
Wolfgang Zillig <wollez@gmx.net> wrote:Hi all,
does anybody know, how I can transfer a SRTM file to an other
ellipsoid? My target region is within MGI-M31 (EPSG 31285)
Setup target location, eg. using the EPSG code you mention.In source latlong location set the region properly first, using
g.region, to avoid your output missplacement - due to SRTM cells are
not alligned to the resolution. If you use d.zoom, use g.region
afterwards to correct the region; see:
https://intevation.de/rt/webrt?serial_num=3961.Now you could reproject the SRTM raster using r.proj. But an optimal
method, which disturbs the input data less, would be:1. Transform your srtm to vector points r.to.vect.
Note. Grass vector engine is very memory consuming, so setup the region
only for your very area of interest. Otherwise r.to.vect might use all
your memory. System shouldn't freeze, but might get extremely slow
when all memory and swap are gone. Give it few days then ;).2. Reproject the vector file to your EPSG 31285 location v.proj.
3. Interploate DEM. v.surf.rst should do fine for such a regulary
spaced input as srtm. Or use other interpolation method you prefer.Note. If you decide for v.surf.rst then in step 1. you could speed up
the process by using r.to.vect -z. This avoids building the datable and
stores elevation as Z coordinate. This would save you a lot of memory,
especially if using DBF. However, if you prefer v.surf.idw you would
need the elevation stored in datable as v.surf.idw can't use Z
coordinate for input.Cheers,
Maciek---------------------
http://www.visanen.pl/ - Zapakujemy wszystko!
Produkcja i dystrybucja torby foliowe, papierowe, reklam?wki, opakowania kartonowe, ekskluzywne pude?ka
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.
Regards
Wolfgang
Hamish schrieb:
does anybody know, how I can transfer a SRTM file to an other ellipsoid? My target region is within MGI-M31 (EPSG 31285)
Load into a lat/lon wgs84 location with r.in.srtm
exit grass and restart in a MGI-M31 location
r.projHamish
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.
r.proj acts in 2D only AFAIK. You will want to use the r.to.vect trick:
export all the cell midpoints coordinates & reproject individually with
PROJ4's cs2cs software*. Then reimport, and convert back to a raster
with v.to.rast. I don't know if there is an easier way.
[*] hint: OUT_PROJ="`g.proj -jf`"
Hamish
Hi,
an easier solution would be welcome, as I'm not a GIS specialist at all!
Wolfgang
Hamish schrieb:
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.
r.proj acts in 2D only AFAIK. You will want to use the r.to.vect trick:
export all the cell midpoints coordinates & reproject individually with
PROJ4's cs2cs software*. Then reimport, and convert back to a raster
with v.to.rast. I don't know if there is an easier way.[*] hint: OUT_PROJ="`g.proj -jf`"
Hamish
On Tue, 07 Mar 2006 08:52:30 +0100
Wolfgang Zillig <wollez@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/
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@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/