[GRASS-user] Reading file with with space separators

[Ralf Schäfer]

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
>>> ..x..y...value
>>> 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 ' '
>>> dgm10_32292_5548_2_rp_one_space.xyz
>> r.in.xyz fs='space', in=dgm10_32292_5548_2_rp_one_space.xyz
>> out=test
> 
> 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:
http://www.sendspace.com/file/8q3vrx
Perhaps this makes reproduction of the problem easier...

Best regards
Ralf


> 
>>> 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.
> 
> 
> Hamish