[GRASSLIST:4162] Re: Map import cluelessness

C.S. Cornuelle bob at xmission.com
Tue Aug 10 17:55:33 EDT 2004


Thus spake Glynn Clements (glynn.clements at virgin.net):

> C.S. Cornuelle wrote:
> 
> > Thanks for the succinct description.  It allowed me to get as far
> > as i.rectify, where this ancient (according to some web searching) 
> > problem arose courtesy of my mailbox:
> > 
> > 	GIS ERROR: error while writing to temp file
> > 
> > As per a recommendation I tried this:
> > 
> > 	watch df -h 
> > 
> > and then some of this:
> > 
> > GRASS:/data/grassdata > date;df /data
> > Mon Aug  9 17:02:19 MDT 2004
> > Filesystem           1K-blocks      Used Available Use% Mounted on
> > /dev/hdb4             24590712  11836772  12753940  49% /data
> > GRASS:/data/grassdata > date;df /data
> > Mon Aug  9 17:02:34 MDT 2004
> > Filesystem           1K-blocks      Used Available Use% Mounted on
> > /dev/hdb4             24590712  11026744  13563968  45% /data
> > 
> > While the first call of df /data probably did not catch peak disk 
> > usage, the difference is around 810M, not nearly large enough to 
> > fill the disk or the partition.  
> > 
> > Any ideas on what might be going on here?  Is there a malloc set 
> > in i.rectify which is causing this?  FYI this map has 7500 rows and
> > 15600 columns, so it is rather large.  10 points were identified in
> > i.points, and the rms value was somewhat high, nearly 100.  
> 
> On 32-bit architectures (e.g. x86), files are limited to 2Gb; it may
> be that you are exceeding that limit.
> 
> Although Linux supports files larger than 2Gb, the code which deals
> with such files has to use "off_t" instead of "long", so the code
> would need to be updated to allow for this.
> 
> Actually, the GRASS code often performs offset calculations using
> "int"s so, even on platforms where "long" is 64 bits, a lot of GRASS
> would still have problems with files larger than 2Gb.

This problem does indeed go away when the region is limited to a smaller
subset of the map.

However, I have another bonehead problem now.  :^)

Not one but two emails are sent to me by i.rectify for this smaller 
region:

Date: Tue, 10 Aug 2004 15:39:12 -0600
GIS WARNING: WARNING lote_wholeworld_base at PERMANENT: projection don't
match current settings.

and then:

Date: Tue, 10 Aug 2004 15:39:12 -0600
Subject: i.rectify
***********************************************
Rectify [lote_wholeworld_base at PERMANENT] (LOCATION LOTEWHOLE_MERC)
into  [lote_wholeworld_baserec in PERMANENT] (LOCATION GLOBAL_30)
complete
-----------------------------------------------
 600 rows, 600 cols (360000 cells) completed in 0:05
 4320000.0 cells per minute

I have tried this with several different regions, to no avail.  And 
searching about did not turn up any references to the GIS WARNING 
message above.

The sequence of actions was to set up a Mercator location, read the
scanned map file in with r.in.png, then i.group, i.target, i.points,
and finally i.rectify into a lat-lon location.

Any ideas?

-- 
Adios,
Chris Cornuelle
bob at xmission dot com




More information about the grass-user mailing list