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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
