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
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to