Details Ticket 5209


Comment | Reply | Take | Resolve


Serial Number 5209
Subject v.in.ascii table creation broken for DDD:MM:SS input
Area grass6
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status open
Last User Contact Never contacted
Current Priority 75
Final Priority 70
Due No date assigned
Last Action Wed Nov 22 05:47:46 2006 (2 yr ago)
Created Sat Oct 14 12:05:20 2006 (2 yr ago)

Transaction History Ticket 5209


Sat, Oct 14 2006 12:05:20    Request created by hbowman  
Subject: v.in.ascii table creation broken for DDD:MM:SS input

Hi,

v.in.ascii gives this error when input data is in DDD:MM:SS.SSSSSS format.

G63> v.in.ascii in=lidaratm2_100LL2.txt out=tmp_vLL fs=,
Scanning input for column types ...
Maximum input row length: 55
Maximum number of columns: 3
Minimum number of columns: 3
column: 1  type: double
column: 2  type: double
column: 3  type: double
Importing points ...
DBMI-DBF driver error:
SQL parser error in statement:
insert into tmp_vLL values ( 1, 75:37:46.5563999999961W,
35:56:58.8948000000124N, 8.898)
Error in db_execute_immediate()

ERROR: Cannot insert values: insert into tmp_vLL values ( 1,
       75:37:46.5563999999961W, 35:56:58.8948000000124N, 8.898)


The scanning step converts to double format for testing and sanitizing for the
next import step, but then the column type is wrong. If you use the "-t" flag
it imports ok, but no table is created.

workaround: specify column= values to force varchar() columns.

G63> v.in.ascii in=lidaratm2_100LL2.txt out=tmp_vLL fs=, \
        columns="x varchar(40), y varchar(40), elev double"

(works ok)


# test data:
75:37:46.5563999999961W,35:56:58.8948000000124N,8.898
75:37:16.5000000000123W,35:56:58.8948000000124N,2.457
75:37:43.6403999999914W,35:56:58.8948000000124N,5.319
75:37:19.0092000000209W,35:56:58.8948000000124N,3.553
75:37:24.1176000000155W,35:56:58.8948000000124N,6.816
75:37:25.0175999999942W,35:56:58.8948000000124N,8.541
75:37:36.1271999999803W,35:56:58.8948000000124N,3.836
75:37:25.4748000000166W,35:56:58.8948000000124N,8.722
75:37:25.6115999999781W,35:56:58.8948000000124N,9.369
75:37:17.2415999999816W,35:56:58.8948000000124N,4.605



Hamish
Tue, Nov 21 2006 04:53:02    Comments added by hbowman  
[fwd from GRASS list]

From: "Martin Landa" <landa.martin at gmail.com>
Cc: grass-dev at grass.itc.it
Subject: Re: [GRASS-dev] ps.map: scale wrong and no output
Date: Sun, 19 Nov 2006


Hi,

2006/11/16, Hamish:

[snip]

> It would be nice to fix this one too:
>    https://intevation.de/rt/webrt?serial_num=5209

I have tried to fix this bug (the attached patch). Is it OK? -- then I
will commit it to CVS...

Best, Martin

-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
[v_in_ascii_LL.diff.gz  application/x-gzip (1544 bytes)]


Index: vector/v.in.ascii/points.c
===================================================================
RCS file: /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]);
Tue, Nov 21 2006 04:53:51    Comments added by hbowman  
[fwd from GRASS list]

[...] looks good to me, but to preserve precision should "%lf"
be used instead of "%f", perhaps combined with G_trim_decimal()?


thanks,
Hamish
Wed, Nov 22 2006 05:47:46    Comments added by hbowman  
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
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request