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

Tue Feb 5 00:00:10 EST 2008

Hi Helena,

It looks like the '|' is partly to blame, but not entirely.

If I use the original file with missmatched numbers of fields between  
records AND use the '|' separator, I have trouble on my Mac.

However, if I fix the file so that all records have the same number  
of fields (keeping '|' as separator) OR I leave the file with messed  
up fields but replace '|' with ',' it works fine.

So it seems more a problem of reading the '|' separator in the text  
file in some circumstances than it does having it in the command string.

I'll have to try this out with Windows and see if switching to commas  
fixes things.

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 9:22 PM, Helena Mitasova wrote:

> I did few more experiments (with a different file, but still
> generated by GRASS - this time using v.out.ascii)
> and it indeed looks like the fs=| is responsible
> for the truly erratic behavior - I think that without quotes it is  
> represented as
> pipe(?) so depending on where you put it you get different response:
>
> at the end of the command:
> GRASS 6.3.cvs (nc_spm_sed):~/grassdata/indata/ncdata > v.in.ascii  
> ftest.txt out=test2 fs=|
> >
> and nothing happens
>
> or in the middle, before output (it never gets to it)
>
> GRASS 6.3.cvs (nc_spm_sed):~/grassdata/indata/ncdata > v.in.ascii  
> ftest.txt fs=| out=test2
>
> ERROR: Required parameter <output> not set:
>     (Name for output vector map).
>
> I am wondering whether there are other commands that would need to  
> have this fixed
> (at least on man page).
> fs=| is default so it is probably rarely used (at least on command  
> line), but apparently
> in needs quotes
>
> Helena
>
>
> On Feb 4, 2008, at 10:46 PM, Michael Barton wrote:
>
>> 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
>>>
>>
>