[GRASSLIST:6816] struggling with v.in.ascii

Hi,

since I am still struggling with v.in.ascii, I had a closer look at the
code and made some weird observations (meaning: I don't understand what I
see).

to set the scene:
I am using GRASS on a debian/testing system, but grass compiled from source.
s.in.ascii in grass54 is reading the file (see below) without problems.
v.in.ascii in grass61cvs from today is checking the file and comes up with
the right conclusions about the number of columns and the respective data
types (see below), but is not writing anything to the resulting vector
dataset (it contains only a database link).

Looking at the code:
The function points_analyse (called in in.c, line 195) goes through the
input file and should write, amongst other things, the lines containing
actual data to the file tmpascii.

But, I found tmpascii to be empty after this function call (printed ascii
and tmpascii to stdout => ascii: copy of input file and tmpascii: nothing)

That's why the function points_to_bin (called in in.c, line 385) cannot
fetch any data.

The while-loop in (points.c, line 172) is never entered, because the file
G_getl2 is supposed to read is empty.

What I don't understand is that writing of a dataline to tmpascii in the
function points_analyse (points.c, line 90) seems to be successful. The
return value of fprintf states 29 chars were written. When I write the
same to stdout it looks okay, as well. What happens to tmpascii ?

v.in.ascii works just perfect, if I put "ascii" instead of "tmpascii" in
the call of the function points_to_bin (in.c line 385).

Clues are more than welcome.

Robert

=======================================================================

more points.txt

248445.02 700247.69 39.31 66
248445.02 700247.88 39.36 56
248445.02 700248.06 39.22 50
248445.02 700248.00 39.13 50
248445.02 700248.00 39.12 50

GRASS 6.1.cvs (aberfoyle61):~ > v.in.ascii in=points.txt format=point \
fs=' ' out=test1
Maximum input row length: 29
Maximum number of columns: 4
Minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
Building topology ...
0 primitives registered
0 areas built
0 isles built
Attaching islands:
Attaching centroids: Topology was built.
Number of nodes : 0
Number of primitives: 0
Number of points : 0
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

GRASS 6.1.cvs (aberfoyle61):~ > v.in in=points.txt format=point \
fs=' ' out=test2
Maximum input row length: 29
Maximum number of columns: 4
Minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
Building topology ...
5 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 4
Number of primitives: 5
Number of points : 5
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

since I am still struggling with v.in.ascii, I had a closer look at
the code and made some weird observations (meaning: I don't understand
what I see).

to set the scene:
I am using GRASS on a debian/testing system, but grass compiled from
source.

Same here.

32bit i386 standard everything? compile time optimizations?

Did you try the Debain 6.0.0 package? (v.in.ascii has been updated
since then for MacOS9 input file support [ie G_getl2()]).

s.in.ascii in grass54 is reading the file (see below) without
problems. v.in.ascii in grass61cvs from today is checking the file and
comes up with the right conclusions about the number of columns and
the respective data types (see below), but is not writing anything to
the resulting vector dataset (it contains only a database link).

It works fine for me using the sample data below.
Adding '-z z=3' makes nodes=5, points=5 (last two points share same
x,y).

> more points.txt
248445.02 700247.69 39.31 66
248445.02 700247.88 39.36 56
248445.02 700248.06 39.22 50
248445.02 700248.00 39.13 50
248445.02 700248.00 39.12 50

can you send this file to me as a gzip'd attachment? (to preserve any
weird newlines, etc)

Looking at the code:
The function points_analyse (called in in.c, line 195) goes through
the input file and should write, amongst other things, the lines
containing actual data to the file tmpascii.

Yes; I don't know how necessary it is to write out the entire datafile
as an intermediary step but that's the way it is right now.

But, I found tmpascii to be empty after this function call (printed
ascii and tmpascii to stdout => ascii: copy of input file and
tmpascii: nothing)

That's why the function points_to_bin (called in in.c, line 385)
cannot fetch any data.

why "w+" and not "w" on line 190 of in.c?

   tmp = G_tempfile();
   if (NULL == (tmpascii = fopen(tmp, "w+"))) {

*** ==> Does the following work? <== ***

GRASS> g.tempfile pid=$$

The while-loop in (points.c, line 172) is never entered, because the
file G_getl2 is supposed to read is empty.

yup.

What I don't understand is that writing of a dataline to tmpascii in
the function points_analyse (points.c, line 90) seems to be
successful. The return value of fprintf states 29 chars were written.
When I write the same to stdout it looks okay, as well. What happens
to tmpascii ?

temp files are stored in $MAPSET/.tmp/$HOST/ anything in there?

Clues are more than welcome.

g.gisenv set="DEBUG=5"

v.in.ascii works just perfect, if I put "ascii" instead of "tmpascii"
in the call of the function points_to_bin (in.c line 385).

Is that what these next two cases represent?

GRASS 6.1.cvs (aberfoyle61):~ > v.in.ascii in=points.txt format=point
\ fs=' ' out=test1
Maximum input row length: 29
Maximum number of columns: 4
Minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
Building topology ...
0 primitives registered
0 areas built
0 isles built
Attaching islands:
Attaching centroids: Topology was built.
Number of nodes : 0
Number of primitives: 0
Number of points : 0
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

GRASS 6.1.cvs (aberfoyle61):~ > v.in in=points.txt format=point \
fs=' ' out=test2
Maximum input row length: 29
Maximum number of columns: 4
Minimum number of columns: 4
column: 1 type: double
column: 2 type: double
column: 3 type: double
column: 4 type: integer
Building topology ...
5 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 4
Number of primitives: 5
Number of points : 5
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

?
Hamish

I am using GRASS on a debian/testing system, but grass compiled from
source. s.in.ascii in grass54 is reading the file (see below) without
problems. v.in.ascii in grass61cvs from today is checking the file and
comes up with the right conclusions about the number of columns and
the respective data types (see below), but is not writing anything to
the resulting vector dataset (it contains only a database link).

don't know. Same data file works fine for me on a similar system.

Maybe try more modules that use G_tempfile() to see if the problem is
there. e.g. r.digit or r.average.

Hamish