[GRASS-user] r.proj error

Well 14 hours later, my r.proj bombed. Unfortunately, I don't have an email account set up for root. Any ideas on why this bombed?

BTW, is there some easy way to keep the projected resolution from exceeding the input resolution? Given the nearest neighbor algorithm, there is nothing to be gain by interpolation (I assume).

---------------------------------------------------------------------
GRASS 6.0.2RC4 (utm2):~ > r.proj -n input=nevgdal616 location=utm
output=nevgdal616utm

Input Projection Parameters: +proj=utm +zone=11 +a=6378137
+rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000
Input Unit Factor: 1

Output Projection Parameters: +proj=utm +zone=11 +a=6378137
+rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000
Output Unit Factor: 1
Input:
Cols: 3608 (3608)
Rows: 6546 (6546)
North: 38.169444 (38.169444)
South: 36.351111 (36.351111)
West: -116.845000 (-116.845000)
East: -115.842778 (-115.842778)
ew-res: 0.000278
ns-res: 0.000278

Output:
Cols: 90240 (90240)
Rows: 201058 (201058)
North: 4224601.960000 (4224601.960000)
South: 4023544.200000 (4023544.200000)
West: 513581.640000 (513581.640000)
East: 603821.510000 (603821.510000)
ew-res: 0.999999
ns-res: 0.999999
Allocating memory and reading input map... 100%
Projecting... WARNING: error writing null row 190379
ERROR: error writing output map
You have new mail in /var/spool/mail/root

gary wrote:

Well 14 hours later, my r.proj bombed.

I'm not surprised!

Unfortunately, I don't have an email account set up for root. Any
ideas on why this bombed?

why are you running GRASS as root? That's probably not a very good idea.

FWIW, in GRASS 6.1 r.proj has been changed to be run as a normal module,
i.e. no email; has 0-100% progress meter.

BTW, is there some easy way to keep the projected resolution from
exceeding the input resolution? Given the nearest neighbor algorithm,
there is nothing to be gain by interpolation (I assume).

Remember it will likely be slighlty rotated and stretched as well.

Output:
Cols: 90240 (90240)
Rows: 201058 (201058)

     ^^^^^^^

North: 4224601.960000 (4224601.960000)
South: 4023544.200000 (4023544.200000)
West: 513581.640000 (513581.640000)
East: 603821.510000 (603821.510000)
ew-res: 0.999999
ns-res: 0.999999

90240 x 201058 = 18 billion cells, at least 72 gig of data. ouch.

set the target resolution a bit lower,

Input:
Cols: 3608 (3608)
Rows: 6546 (6546)

...

ew-res: 0.000278
ns-res: 0.000278

0.000278 deg lat * 1852m/naut mi. * 60 naut mi./degree = 30.9m

( *cos(lat) for longitude )

in target location:
g.region res=30 -a

Allocating memory and reading input map... 100%
Projecting... WARNING: error writing null row 190379
ERROR: error writing output map
You have new mail in /var/spool/mail/root

..

Unfortunately, I don't have an email account set up for root.

maybe your computer is one step ahead of you, try:

less /var/spool/mail/root

you may also try 'r.proj -n' (similar to 'i.rectify -c'?)

Hamish

I've compiled Grass 6.1. The r.proj at the lower resolution worked fine (Hamish's tip to prevent a 80GByte file!). The r.los bombed. Here are some of the warning messages:
------------
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240605900 n = 12 at
          col:row 0:201054
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240696144 n = 12 at
          col:row 0:201055
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240786388 n = 12 at
          col:row 0:201056
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240876632 n = 12 at
          col:row 0:201057
-----------------

I compiled this with and without the 64 bit flag. [System is AMD 64 4400 running Suse 10.0] The problem is the same, i.e warning messages and no output. My compilation does does not have fftw installed, if that makes a difference.

Any ideas?

r.info dump on input map:
------------------------------------
r.info map=nevgdal616proj

+----------------------------------------------------------------------------+
  | Layer: nevgdal616proj Date: Tue Jun 20 00:58:35
2006 |
  | Mapset: PERMANENT Login of Creator: root
  | Location: utm2
  | DataBase: /usr/localsrc
  | Title: ( nevgdal616proj )
  | timestamp: none

|----------------------------------------------------------------------------|
|
  | Type of Map: raster Number of Categories: 255
  | Data Type: FCELL
  | Rows: 6702
  | Columns: 3008
  | Total Cells: 20159616
  | Projection: UTM (zone 11)
  | N: 4224601.96 S: 4023544.2 Res: 29.99966577
  | E: 603821.51 W: 513581.64 Res: 29.99995678
  | Range of data: min = nan max = nan
  |
  | Data Source:
  |
  | Data Description:
  | generated by r.proj
  |

+----------------------------------------------------------------------------+

r.los command:
r.los input=nevgdal616proj output=nevlos coordinate=592418,4034706
max_dist=99999

Apologies. This is a r.los problem.
  <snip>

gary wrote:

  | Range of data: min = nan max = nan

That doesn't look very promising.

| Rows: 6702
| Columns: 3008

After you get r.proj sorted out, try r.los at say 300m res. 6700x3000
might be too big for r.los.

Hamish

gary wrote:

I've compiled Grass 6.1. The r.proj at the lower resolution worked fine
(Hamish's tip to prevent a 80GByte file!). The r.los bombed. Here are
some of the warning messages:
------------
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240605900 n = 12 at
          col:row 0:201054

200,000 rows?

If the number of columns is anywhere near that figure, the segment
file will be >2Gb, which probably won't work unless you configured
GRASS with the --enable-largefile option (it may not even work then;
it depends whether anyone has actually tested r.los with large file
support enabled).

--
Glynn Clements <glynn@gclements.plus.com>

Hamish spotted that my projected raster map (via r.proj) has "nan" data in it, which is probably the source of errors. The data on the input map is fine, but unfortunately in lat/long format, unsuitable for r.los.

I adjusted the resolution, and r.los still bombs, but again, it is due to the data.

Thanks for the tip on --enable-largefile. I noticed that the r.los analysis required 1.8Gbytes, even at the reduced resolution (30 meters). The PC has about 3.4Gbytes of ram. [Technically, it has 4G, but for some reason, the mobo can't use it all.]

Glynn Clements wrote:

gary wrote:

I've compiled Grass 6.1. The r.proj at the lower resolution worked fine (Hamish's tip to prevent a 80GByte file!). The r.los bombed. Here are some of the warning messages:
------------
WARNING: segment_seek: Invalid argument
WARNING: Failed seek in segment file for index = 240605900 n = 12 at
         col:row 0:201054

200,000 rows?

If the number of columns is anywhere near that figure, the segment
file will be >2Gb, which probably won't work unless you configured
GRASS with the --enable-largefile option (it may not even work then;
it depends whether anyone has actually tested r.los with large file
support enabled).

gary wrote:

Thanks for the tip on --enable-largefile. I noticed that the r.los
analysis required 1.8Gbytes, even at the reduced resolution (30 meters).
  The PC has about 3.4Gbytes of ram. [Technically, it has 4G, but for
some reason, the mobo can't use it all.]

r.los (and a few other programs which need to read raster maps in a
non-linear manner, e.g. r.walk) use the segment library, which creates
a copy of the map in a temporary file in a format which is convenient
for random access (essentially, uncompressed tiles).

Consequently, the size of the data will be limited to the maximum size
of a file (usually 2Gb when --enable-largefile isn't used), regardless
of the amount of RAM which is present.

--
Glynn Clements <glynn@gclements.plus.com>