[GRASS-user] Reading file with with space separators
senator at ecotoxicology.de
Wed Apr 17 07:26:10 PDT 2013
Thanks for your help!!!
Am 17.04.2013 um 13:25 schrieb Hamish <hamish_b at yahoo.com>:
> Ralf wrote:
>>> I have xyz files with the format
>>> where <.> stands for white space. The spacing is
>>> two spaces between x and y and three spaces to data column.
> Markus Metz wrote:
>> [ rather difficult to produce a file with different kinds of
>> spacing between columns ]
yeah, some governmental institutions are really funny
>> You could try
>> cat dgm10_32292_5548_2_rp.xyz | tr -s ' '
>> r.in.xyz fs='space', in=dgm10_32292_5548_2_rp_one_space.xyz
> Yes, I think using 'tr -s' is the best way.
> (you can pipe the result directly into r.in.xyz too if you like)
The idea is very well and I should have thought about this myself.
However, I still get an error, although I now have 1-space delimited file.
r.in.xyz fs='space', input=dgm10_32292_5548_2_rp_one_space.xyz out=test
I already achieved the task with the help in R now, but from academic point would really be interested why is not working. I obtain the error message:
ERROR: Not enough data columns. Incorrect delimiter or column number? Found
the following character(s) in row 1:
[293220.000 5550000.000 311.432]
> if it really is _always_ two,three spaces between columns,
> you could set x=3 y=5 z=8. But maybe a .0 is left off somewhere
> and the number of spaces between columns changes?
Although it looks strictly regular, this did also not work...
I uploaded sample files here:
Perhaps this makes reproduction of the problem easier...
>>> In R it is no problem - the simple read.table with
>>> sep="" for any whitespace works. And with rasterFromXYZ
>>> (raster package) I can create a raster without problems.
> r.in.xyz (and most GRASS modules) split by each literal sep= char,
> not until it finds another number the way glibc funtions or awk
> might. An offshoot of this (mostly for importing .csv tables
> from spreadsheets with v.in.ascii) is that empty data columns
> are supported as containing NULL, and not messing up the placement
> of columns to the right.
More information about the grass-user