[GRASS-dev] Re: v.in.ascii [bug #5209] DDD.MM.SS failing to fit in a double column

[Hamish]

  https://intevation.de/rt/webrt?serial_num=5209
  DDD:MM:SS -> xxx.xxxxxxx  breaks during DB population stage

Martin:
> > I have tried to fix this bug (the attached patch). Is it OK? --
> > then I will commit it to CVS...
Hamish:
> The following looks good to me, but to preserve precision should
> "%lf" be used instead of "%f", perhaps combined with
> G_trim_decimal()?
>
> Index: vector/v.in.ascii/points.c
> =================================================================
> /home/grass/grassrepository/grass6/vector/v.in.ascii/points.c,v
> retrieving revision 1.21 diff -u -r1.21 points.c
> --- vector/v.in.ascii/points.c  18 Oct 2006 05:09:22 -0000     
> 1.21 +++ vector/v.in.ascii/points.c  19 Nov 2006 16:45:25 -0000
> @@ -368,7 +368,15 @@
>                 if (strlen(tokens[i]) > 0) {
>                     if (coltype[i] == DB_C_TYPE_INT ||
>                         coltype[i] == DB_C_TYPE_DOUBLE) {
> -                       sprintf(buf2, "%s", tokens[i]);
> +                       if (G_projection() == PROJECTION_LL &&
> +                           (i == xcol || i == ycol)) {
> +                           if (i == xcol)
> +                               sprintf(buf2, "%f", x);
> +                           else
> +                               sprintf(buf2, "%f", y);
> +                       }
> +                       else
> +                           sprintf(buf2, "%s", tokens[i]);
>                     }
>                     else {
>                         db_set_string(&val, tokens[i]);


In 6.3-cvs I have committed the above with "%.15g" replacing "%f".
DBF limits double columns to .6 precision, so I had to switch to SQLite
to see any difference. I think .9 is enough with lat/lon to get to
roughly 1mm precision, but cranked it up to .15 anyway.

However --- is it a better solution to change the column type to
varchar() rather than store the decimal equivalent in a double? ie
preserve the input data in its original form in the database.
(after checks that x,y,z post-conversion can all be stored as doubles
in the vector geometry)

[keeping bug open]


Hamish