[GRASS-user] grass70 problem with gui

[Markus Metz]

On Thu, Dec 12, 2013 at 12:10 PM, Martin Landa <landa.martin at gmail.com> wrote:
> Hi,
>
> 2013/12/12 Markus Metz <markus.metz.giswork at gmail.com>:
>
>> I have fully reverted r58417 because with strtok, "A sequence of two
>> or more contiguous delimiter characters in the parsed string is
>> considered to  be  a single  delimiter" (man strtok), whereas the
>> GRASS routine does not merge delimiters.
>
> why? It was useful, for example national DEM/DSM in Czech Republic
> (sample data [1]) is provided in the format where coordinates are
> separated with *two* or more spaces. In other words, with the native
> tokenize function `r.in.xyz sep=space` or `r.in.xyz sep="  "`
> (double-space as user could expect that it will work) fails bacouse
> G_tokenize("x  y", " "); returns {'x', '', 'y'} and not  {'x', 'y'}.
> With strtok-based tokenizing such string works perfectly.

OTOH, v.in.ascii format=point expects the same number of tokens in each line:

1|1||name
2|2|3|other_name

must always result in 4 tokens. Here, double pipe works as expected
only if delimiters are not merged.

>
> BTW, `separator` parameter can be string with more than one character,
> but native tokenize subroutine fails to tokenize such string with
> multiple-character delimiter, eg. G_tokenize("firstSElast", "SE");
> returns {'first', '', 'last'} and not {'first', 'last'} as someone
> could expect.

Someone else would expect that with "SE" as delimiter argument, the
delimiter can be either "S" or "E".

I would leave G_tokenize() as it is because it is used at too many
different places which expect the current behaviour.

It is not uncommon that ASCII input data need a bit of pre-processing
(tr, sed), e.g. when fields have fixed lengths. Alternatively, add an
option (to respective modules, not to G_tokenize()) to expect fixed
length fields defining the field lengths?

Markus M