[GRASS-user] Importing .csv table into GRASS

[Moritz Lennert]

JanaKr wrote:
> I am trying to import a simple okresy.csv table, the first few lines 
> of which are:
> 
> CAT,AREA,PERIMETER,CISLO_OKR,SO2_KG,SO2_OBYV 
> 64,9485480,15278.33,101,3384,0.08 66,92488080,53576.26,102,3384,0.03
>  62,74758064,39651.84,103,3384,0.05 63,96450584,56394.8,104,3384,0.04
> 
> 
> Using  db.in.ogr okresy.csv out=okresy returns error message: Input 
> table <okresy.csv>   not found or not readable


Actually, your problem comes from the fact that your first column is
named CAT. If you look at the db.in.ogr script, it does:

WARNING="`v.in.ogr --q dsn=\"$GIS_OPT_DSN\" $LAYER out=$GIS_OPT_OUTPUT
-o --o 2>&1 | grep -i 'ERROR\|cat' | grep -v 'truncated'`"
if [ ! -z "$WARNING" ] ; then
    echo "$WARNING"
    if [ ! -z "$GIS_OPT_DB_TABLE" ] ; then
       g.message -e "Input DSN <$INPUT> not found or not readable"
    else
       g.message -e "Input table <$INPUT> not found or not readable"
    fi
    exit 1
fi


And if you try that with your file:

v.in.ogr --q dsn=test.csv out=test -o --o

GRASS 6.3.0 (gisdemo_ncspm):~ > v.in.ogr --q dsn=test.csv out=test -o --o
WARNING: Width for column CAT set to 255 (was not specified by OGR), some
          strings may be truncated!
WARNING: Width for column AREA set to 255 (was not specified by OGR), some
          strings may be truncated!
WARNING: Width for column PERIMETER set to 255 (was not specified by OGR),
          some strings may be truncated!
WARNING: Width for column CISLO_OKR set to 255 (was not specified by OGR),
          some strings may be truncated!
WARNING: Width for column SO2_KG set to 255 (was not specified by OGR),
          some strings may be truncated!
WARNING: Width for column SO2_OBYV set to 255 (was not specified by OGR),
          some strings may be truncated!
DBMI-SQLite driver error:
Error in sqlite3_prepare():
duplicate column name: CAT

ERROR: Cannot create table: create table test (cat integer, CAT varchar (
        255 ), AREA varchar ( 255 ), PERIMETER varchar ( 255 ), CISLO_OKR
        varchar ( 255 ), SO2_KG varchar ( 255 ), SO2_OBYV varchar ( 255 ))


If you rename that first column to ID or something else, it works like a
charm.

In more recent versions, there is an explicit error message which leads
you directly to the problem, although I consider this a bug of the
script, so you might want to file a bug report if it isn't already done.



> 2-nd mail (reply to Moritz): Actually, the .csv table was made from 
> .dbf table of an existing vector map. The problem is that I want to
> use v.db.join to transfer one attribute from that table to another
> vector map through a common key; When I tried v.db.join directly on
> the .dbf table, it said the .dbf format is not supported. I am
> affraid  v.in.ascii will produce a .dbf table, so it does not serve
> my purpose.

As Hamish mentioned, v.in.ascii only makes sense if your csv file
contains geometries, and not only attribute data. Sorry for misleading you.

Concerning the issue of dbf, GRASS will create the table in the default 
database backend that you define with db.connect, so just define sqlite 
as your default database backend, and it will create a table in an 
sqlite db which you can then use for v.db.join.

Moritz