v.in.ascii in GRASS 6.4.0 RC5 - space delimited tables are not imported

4 messages Options
Embed this post
Permalink
Milan Salek

v.in.ascii in GRASS 6.4.0 RC5 - space delimited tables are not imported

Reply Threaded More More options
Print post
Permalink
Dear all,

in GRASS 6.4.0 RC5 (run on OpenSuse 11.0) I have encountered a problem
in v.in.ascii when importing tables whose columns are delimited by
space. The option 'fs=space' (with or without the apostrophes) does not
seem to work. Only when the columns are delimited by non-space character
(I'v tested '|' and ','), v.in.ascii works well. I store the atribution
data in  dbf file.

In previous versions of GRASS the problem does not exist.

The workaround is quite easy (including some non-space delimiters to the
imported table) but I would appreciate the next version to be without
thit bug (or feature ...).

Best regards

Milan Salek

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Martin Landa

Re: v.in.ascii in GRASS 6.4.0 RC5 - space delimited tables are not imported

Reply Threaded More More options
Print post
Permalink
Zdravim,

2009/10/9 Milan Salek <[hidden email]>:

> in GRASS 6.4.0 RC5 (run on OpenSuse 11.0) I have encountered a problem
> in v.in.ascii when importing tables whose columns are delimited by
> space. The option 'fs=space' (with or without the apostrophes) does not
> seem to work. Only when the columns are delimited by non-space character
> (I'v tested '|' and ','), v.in.ascii works well. I store the atribution
> data in  dbf file.
>
> In previous versions of GRASS the problem does not exist.
>
> The workaround is quite easy (including some non-space delimiters to the
> imported table) but I would appreciate the next version to be without
> thit bug (or feature ...).

seems to work for me (6.4.0.svn)

echo -e "1 2\n3 4" | v.in.ascii out=x fs=space --o

?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Milan Salek

Re: v.in.ascii in GRASS 6.4.0 RC5 - space delimited tables are not imported - issue solved

Reply Threaded More More options
Print post
Permalink
In reply to this post by Milan Salek
FYI:

Thanks to Martin Landa, the problem is solved: The space (delimiter)
must be only one, more spaces between the items (columns) results in the
error, so it is necessary to reduce the number of spaces to one.

E.g:

echo -e "1 2\n3 4" | v.in.ascii out=x fs=space --o
does work

echo -e "1  2\n3  4" | v.in.ascii out=x fs=space --o
does not work (at least at my computer).

The problem is associated only with GRASS >= 6.4. At GRASS 6.3 I am not sure (do not have it available now), in GRASS <=6.2 there is no issue with multiple spaces (verified).

Best regards

Milan Salek

Milan Salek napsal(a):

> Dear all,
>
> in GRASS 6.4.0 RC5 (run on OpenSuse 11.0) I have encountered a problem
> in v.in.ascii when importing tables whose columns are delimited by
> space. The option 'fs=space' (with or without the apostrophes) does not
> seem to work. Only when the columns are delimited by non-space character
> (I'v tested '|' and ','), v.in.ascii works well. I store the atribution
> data in  dbf file.
>
> In previous versions of GRASS the problem does not exist.
>
> The workaround is quite easy (including some non-space delimiters to the
> imported table) but I would appreciate the next version to be without
> thit bug (or feature ...).
>
> Best regards
>
> Milan Salek
>
>  

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
hamish-2

Re: v.in.ascii in GRASS 6.4.0 RC5 - space delimited tables are not imported - issue solved

Reply Threaded More More options
Print post
Permalink
Milan:
> Thanks to Martin Landa, the problem is solved: The space
> (delimiter) must be only one, more spaces between the items
> (columns) results in the error, so it is necessary to reduce
> the number of spaces to one.

right, because e.g. if the delimiter was a comma, and a field
were empty, ",," would denote the empty field. This is intended
behaviour. Alternate wild idea: try using fs=tab without touching
your data and see what happens.


you can pipe your data though "tr --squeeze-repeats ' '" to
cleanse it.


Hamish




_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user