[GRASS-user] problems using r.proj with large data set

I am working with SRTM elevation for the Horn of Africa. The data comes in
chunks, which I have patched together to cover all the countries I'm
interested in (South to Uganda and west to Ethiopia). The data are
originally in lat-long but I want to calculate slope so my understanding is
that I need to project. I choose utm 37N as being roughly in the center of
the region and then extend the bounds of the working region to include all
the countries.

I'm using grass63 that I compiled on a machine running CentOS, which is a
version of Redhat. The machine has 2 gb of memory. The command runs for
awhile and then stops, sometimes with a complain about memory or sometimes
with the word Killed. Any suggestions greatly appreciated!

Jerry

r.proj input=AfricaHornElev location=world mapset=PERMANENT
output=AfricaHornElev method=cubic

Input Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563
+no_defs Input Unit Factor: 1

Output Projection Parameters: +proj=utm +zone=37 +a=6378137
+rf=298.257223563 +n o_defs Output Unit Factor: 1

Input:

Cols: 25128 (25200)

Rows: 24696 (27600)

North: 15.580000 (18.000000)

South: -5.000000 (-5.000000)

West: 31.000000 (31.000000)

East: 51.940000 (52.000000)

ew-res: 0.000833

ns-res: 0.000833

Output:

Cols: 19262 (20328)

Rows: 19223 (19507)

North: 1722315.000000 (1722315.000000)

South: -566189.703183 (-600000.000000)

West: -393095.238095 (-520000.000000)

East: 1900000.000000 (1900000.000000)

ew-res: 119.047619

ns-res: 119.050341

Allocating memory and reading input map...

Further to this message.

I did a cvs update and compiled the result with --enable-largefile option.
The make process worked ok and it is possible that the r.proj ran a bit
longer before it crashed with the message Killed but it still died.

Is this a problem with large files that I will just have to work around or
is it something to do with my setup?

Any help appreciated.

Thanks, Jerry

JerryNelson wrote:

I am working with SRTM elevation for the Horn of Africa. The data comes in
chunks, which I have patched together to cover all the countries I'm
interested in (South to Uganda and west to Ethiopia). The data are
originally in lat-long but I want to calculate slope so my understanding
is
that I need to project. I choose utm 37N as being roughly in the center of
the region and then extend the bounds of the working region to include all
the countries.

I'm using grass63 that I compiled on a machine running CentOS, which is a
version of Redhat. The machine has 2 gb of memory. The command runs for
awhile and then stops, sometimes with a complain about memory or sometimes
with the word Killed. Any suggestions greatly appreciated!

Jerry

r.proj input=AfricaHornElev location=world mapset=PERMANENT
output=AfricaHornElev method=cubic

Input Projection Parameters: +proj=longlat +a=6378137 +rf=298.257223563
+no_defs Input Unit Factor: 1

Output Projection Parameters: +proj=utm +zone=37 +a=6378137
+rf=298.257223563 +n o_defs Output Unit Factor: 1

Input:

Cols: 25128 (25200)

Rows: 24696 (27600)

North: 15.580000 (18.000000)

South: -5.000000 (-5.000000)

West: 31.000000 (31.000000)

East: 51.940000 (52.000000)

ew-res: 0.000833

ns-res: 0.000833

Output:

Cols: 19262 (20328)

Rows: 19223 (19507)

North: 1722315.000000 (1722315.000000)

South: -566189.703183 (-600000.000000)

West: -393095.238095 (-520000.000000)

East: 1900000.000000 (1900000.000000)

ew-res: 119.047619

ns-res: 119.050341

Allocating memory and reading input map...

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
View this message in context: http://www.nabble.com/problems-using-r.proj-with-large-data-set-tf2775725.html#a7746318
Sent from the Grass - Users mailing list archive at Nabble.com.

JerryNelson wrote:

Is this a problem with large files that I will just have to work around or
is it something to do with my setup?

Propably the same, very old issue:
http://intevation.de/rt/webrt?serial_num=241

Maybe use gdalwarp instead - faster, doesn't require too much memory,
more flexible.

Maciek