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