[GRASS-dev] erratic behavior of v.in.ascii with WinGRASS

[Michael Barton]

Yet additional information.

The file is messy because not all records have the same number of  
fields. Here is an example of 2 records.

628658.81149001|226880.93032087|9|-9999|-9999
636555.15570527|224580.64987627|10|125.6878585815||4|Managed  
Herbaceous Cover

In fact these *should* be

628658.81149001|226880.93032087|9|-9999|-9999|
636555.15570527|224580.64987627|10|125.6878585815|4|Managed  
Herbaceous Cover

My Mac will import the file in its original form, but crashes the  
TclTk when I use v.in.ascii from the GUI dialog. Another student's  
Mac imported the file with no problem.

If I clean it up so that it is formatted like the 2nd pair of records  
above, it imports on my Mac fine.

That said...

1) v.in.ascii should not crash any system if it encounters a bad  
file. It should exit with an error message
2) v.in.ascii in WinGRASS also crashed with a clean file on another  
student's computer today. It was a small one of 5 points. So there is  
still a problem under Windows.

I tried running it from the command line with the messy original  
file. It did NOT import the points and output an error message to the  
terminal...

Scanning input for column types...
Maximum input row length: 89
Maximum number of columns: 1
Minimum number of columns: 1
ERROR: y column number > minimum last column number
        (incorrect field separator?)

So... why does v.in.ascii go ahead with importing the points when run  
through the TclTk GUI when it does not import the points when run  
from the command line? The TclTk GUI has pretty robust error trapping  
now. So why does v.in.ascii bring it down? Could it be the  
'formatting' of the error message? Something else going on internally  
so that it's not getting a message back to itself to NOT continue  
with importing?

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>



On Feb 4, 2008, at 8:23 PM, Helena Mitasova wrote:

>
> On Feb 4, 2008, at 9:45 PM, Michael Barton wrote:
>
>>
>>
>> On Feb 4, 2008, at 7:23 PM, Hamish wrote:
>>
>>> Michael Barton wrote:
>>>> I've run into a problem running v.in.ascii for WinGRASS  
>>>> importing an
>>>> ASCII points file. Sometimes it works OK. Other times, it causes a
>>>> Windows dbf.exe error but still gets the job done. In most  
>>>> cases, it
>>>> causes a dbf.exe error and only imports the first point--with a  
>>>> coor
>>>> error.
>>>>
>>>> Here are a couple of other pieces of information.
>>>
>>> can you 1) run it with 'g.gisenv DEBUG=5' and 2) make the input file
>>> and exact command line used available.
>>>
>>> how about if you skip DB creation with '-t'?
>>>
>>>
>>> Hamish
>>>
>>
>> We've used several files to test. But the main one is from the N.  
>> Carolina demo data set, external files for import <http:// 
>> skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ncexternal/ 
>> schools_el_lu.txt>.
>
> that file was actually output from GRASS - this is the command:
>
> r.what -f elevation,landuse96_28m null=-9999 < schools.txt >  
> schools_el_lu.txt
>
> the original file is here (I assume that one works):
> http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat07/ 
> ncexternal/schools.txt
>
> Apparently I haven't tried to import it. It was probably generated  
> on Mac.
> I can try it out and report back,
>
> Helena
>
>>
>> This is a messy dataset, which may be part of the cause. But OTOH,  
>> it should behave the same way on all platforms and not cause a  
>> Windows dbf.exe error.
>>
>> v.in.ascii input=/Users/cmbarton/schools_el_lu.txt  
>> output=schools_lu format=point fs=| skip=0 x=1 y=2 z=0 cat=3
>>
>> I just tried it and saw it flash a malloc and dbmi error before it  
>> crashed the GUI
>>
>> I'll try the debug on my Mac. I don't think that will work on  
>> Windows.
>>
>> Michael
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>