[GRASS-user] Vector import combo: db.in.ogr/v.in.db data type casting problem

GRASS GRASS user
1

hi,

here is an issue (probably float/integer typcasting related) issue when importing a large CSV dataset of vector points into GRASS6.4.2.

The data set contains hundreds of columns, so v.in.ascii is not an option (the columns option-string would be ungodly long).

Instead, the data is transformed into a DBF and ingested as a table:

db.in.ogr dsn=FOO.dbf output=BAR key=the_id [works]

The integrity of the column data types is confirmed by:

db.describe -c BAR

Result:

column:N1 [X column]
description:
type:DOUBLE PRECISION
len:20
scale:6
precision:18

column:N2 [Y column]
description:
type:DOUBLE PRECISION
len:20
scale:6
precision:18

Now a VECTOR is created from the table:

v.in.db table=BAR x=N1 y=N2 key=the_id output=BAZ --o

[**Something strange happens at this point: Typecasting bug ? **]

Running a v.db.select over the new vector shows __INTEGER__ values for the X/Y columns N1 and N2 (which were originall EPSG lat/lon FLOAT values):

N1|N2|N3|N4
-9293467|43013833|33.4|1
-9293815|43004851|34.3|1
-9294164|42995869|41025|1

The data in column N3 is CHAR, so it only mimicks float values.

Does anybody know of a working recipe to avoid this FLOAT->INTEGER problem ?

peter

Peter
--
Dr. Peter Löwe
<peter.loewe@gmx.de>

2

On Mon, Aug 20, 2012 at 3:56 PM, "Peter Löwe" <peter.loewe@gmx.de> wrote:

hi,

here is an issue (probably float/integer typcasting related) issue when importing a large CSV dataset of vector points into GRASS6.4.2.

The data set contains hundreds of columns,

Note that the default DBF driver does not support an "unlimited"
amount of columns
(the specs suggest 128 columns max).

so v.in.ascii is not an option (the columns option-string would be ungodly long).

Instead, the data is transformed into a DBF

Please use SQLite instead, also as DB backend for such operations
(ideally, due to recent fixes, the current 6.4.svn).

Best,
Markus

3

Hi Markus,

Note that the default DBF driver does not support an "unlimited"
amount of columns
(the specs suggest 128 columns max).

Please use SQLite instead, also as DB backend for such operations
(ideally, due to recent fixes, the current 6.4.svn).

That's correct. Thanks for following up on this.

Peter
--
Dr. Peter Löwe
<peter.loewe@gmx.de>