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

[Helena Mitasova]

Michael,

my Mac definitely does not like fs=|
it imports it correctly without it (as it i the default separator)
or when it is "|"

Helena

g.region rast=elevation
  v.in.ascii schools_el_lu.txt output=schools_lutest format=point  
fs=| skip=0 x=1 y=2 z=0 cat=3
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?)

v.in.ascii schools_el_lu.txt output=schools_lutest format=point  
fs="|" skip=0 x=1 y=2 z=0 cat=3
Scanning input for column types ...
Maximum input row length: 89
Maximum number of columns: 7
Minimum number of columns: 5
Importing points ...
Populating table...
Building topology ...
167 primitives registered
Building areas:  100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids:  100%
Topology was built.
Number of nodes     :   167
Number of primitives:   167
Number of points    :   167
Number of lines     :   0
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   0
Number of isles     :   0
v.in.ascii complete.



On Feb 4, 2008, at 10: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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev