[GRASSLIST:10772] Re: SRTM data transformation

Maciek Sieczka werchowyna at epf.pl
Mon Mar 6 15:17:24 EST 2006


On Mon, 06 Mar 2006 19:42:19 +0100
Wolfgang Zillig <wollez at 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




More information about the grass-user mailing list