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

[Helena Mitasova]

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
>>
>