[GRASS-dev] [GRASS GIS] #2193: v.in.ogr does not handle columns named 2D_lenght and 3D_lenght

[GRASS GIS]

#2193: v.in.ogr does not handle columns named 2D_lenght and 3D_lenght
------------------------------------------------------------+---------------
 Reporter:  wenzeslaus                                      |       Owner:  grass-dev@…              
     Type:  defect                                          |      Status:  new                      
 Priority:  minor                                           |   Milestone:  7.0.0                    
Component:  Vector                                          |     Version:  svn-trunk                
 Keywords:  v.in.ogr, r.in.gdal, import, database, columns  |    Platform:  All                      
      Cpu:  All                                             |  
------------------------------------------------------------+---------------
 When the attribute table of the imported map contains numbers at the
 beginning of the map/layer name (e.g. `2D_lenght`), G7:v.in.ogr replaces
 the number with `x`.


 When there are two columns which differ only by this first character (e.g.
 `2D_lenght` and `3D_lenght`), both names will result in `xD_lenght`:

 {{{
 Column name <2D_lenght> renamed to <xD_lenght>
 Column name <3D_lenght> renamed to <xD_lenght>
 }}}

 This of course causes an error:

 {{{
 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 duplicate column name: xD_lenght
 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 duplicate column name: xD_lenght
 ERROR: Unable to create table: 'create table mytable (cat integer, ...,
 xD_lenght double precision, xD_lenght double precision, ...)'
 }}}

 (I don't know why the lines at the beginning are repeated.)

 This replacing can actually happen also for map/layer names itself,
 probably for both G7:v.in.ogr and G7:r.in.gdal, when filenames (or
 whatever) begging with the number.

 The workaround is to specify all column names manually using `cnames`
 parameter, or `output` parameter in case of layers. However, more
 comfortable (especially in case of columns) would be to have some more
 robust replacing method active by default, e.g. prefix for columns with
 invalid character at the beginning instead of replacing.

 The other part of the story is that in GUI, you cannot specify `cnames`,
 perhaps some table for column names can be done but automatic working
 (robust) way would be beneficial for both GUI and scripts.

 By the way, shouldn't be `cnames` renamed to `column_names` according to
 new GRASS reading friendly standards?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2193>
GRASS GIS <http://grass.osgeo.org>