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