[GRASSLIST:5955] Problem using r.in.ascii

[Victor Wren]

I've got a rather strange problem I can't figure out, using GRASS 5.0.1

I have a large number of sites (on the order of 176,000) that I'm trying to 
use as elevations to create a surface (they were derived from road surveys, 
control points, signposts, and miscellaneous building perimeters, scavenged 
from a DXF file by a script I wrote).  The logical way to do this would be to 
bring them in as sites, and do s.surf.rst, but the surface I get is too 
convoluted (and playing with tension values from 10 to 100 doesn't seem to 
make any noticeable difference).

My next thought was s.to.rast to surface them as a raster, but s.to.rast 
seems to die an ugly segfault death at a few thousand sites.  In desparation, 
I wrote a perl script that went through the sites and built up a raster map 
file suitable for import with r.in.ascii (averaging multiple sites that fall 
in the same cell, unlike s.to.rast, which just keeps the last value, which, 
for my purposes, is a Good Thing).

I've used this script to import two fields of sites, with no fuss.  The 
surfaces I get with r.surf.idw look very good, with very little convolution.  
Everything was going smooth as silk.  I got to the third batch of data, and 
suddenly r.in.ascii is failing.

If I look at the ascii file that I'm importing, I can see many non-null 
cells.  Searching the file for decimal points (non-null cells), there are 
almost seventy thousand.  Doing r.stats on one of the previous maps (of 
similar size and density) shows thousands of non-null cells.  But when I 
import the third map, only about fifty cells out of a million and a half are 
non-null, according to r.stats.  During import, it reports no errors at all.

I've played with region settings every which way (my script kicks out East, 
West, North and South limits, as well as Min-Z and Max-Z.  "g.region -p" 
reports exactly the same numbers when I do g.region rast=, as does "r.info")  
The location is set up as UTM, nad83, zone13, grs80. The first few lines of 
the generated raster file look like this:

north: 4402330
south: 4395940
east: 466740
west: 442750
rows: 639
cols: 2399
null: N
type: float

N N N N N N N ....
(etc, for another 639 lines of 2399 columns, many of which contain something 
other than "N" -- like 2569.481.  The column separator is a space [0x20] The 
row separator is 0x0A.  Yes, I've looked at this with hexdump to see if there 
are any bad invisible characters)

(if anybody is curious about the entire raster, it can be found at 
http://www.timension.com/GIS/I70_3.UTM.rast.gz -- this is a 273K file
{Oh, this is too cool -- I just found out that Mozilla will gunzip zipped 
files, and put it on the screen for you -- Neat!  So if you're using Mozilla, 
you can see directly how many cells are non-null}

I'm at wits end trying to figure this out, especially since it worked 
(apparently) perfectly the first two times.  Am I missing something 
fundamental?  Is my script creating flawed rasters?  Is there a file-size 
limit to r.in.ascii that only allows for small rasters to be imported (say, 
under a million cells)?

I eagerly await any help (okay, I don't await -- I keep farting with my 
scripts because I'm on deadline, but with diminishing hope of success).

Victor Wren



Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily
those of Timension Inc. or the management.  All
Rights Reserved.  No spitting.