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

[Helena Mitasova]

I just emailed you the response - it is the fs=|
try to skip it to see what happens. It does not seem to have anything  
with the data in the file

Helena


Helena Mitasova
Associate Professor
Department of Marine, Earth
and Atmospheric Sciences
1125 Jordan Hall, Campus Box 8208
North Carolina State University
Raleigh NC 27695-8208
http://skagit.meas.ncsu.edu/~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
>>
>