[GRASS5] GRASS5.1: trouble importing shape file with v.in.ogr

Hello,

I'm trying to import a shapefile into GRASS5.1 using v.in.ogr. I get the
following message when trying to import:

v.in.ogr dsn=/home/mlennert out=cp_in layer=cp
dbmi: Protocol error
dbmi: Protocol error
ERROR: Cannot create table: create table cp_in (cat integer, CP_ID integer,
       PC4_CODE varchar ( 4 ), PC4_NAME varchar ( 40 ), LANG1 varchar ( 3 ),
       PC4_NAME2 varchar ( 40 ), LANG2 varchar ( 3 ), X integer, Y integer,
       SUPERFICIE integer, Z1_81_100 integer, DENSITé97 integer, POP97_81
integer,
       BEST_SCORE integer, BEST_SCORE integer, PART_DE_ME double precision,
       PART_DES_M double precision, BOITES_Ã _C integer, PART1 integer)

I can import the file with v.format.

Moritz

On Tuesday 27 May 2003 16:33, Moritz Lennert wrote:

Hello,

I'm trying to import a shapefile into GRASS5.1 using v.in.ogr. I get the
following message when trying to import:

v.in.ogr dsn=/home/mlennert out=cp_in layer=cp
dbmi: Protocol error
dbmi: Protocol error
ERROR: Cannot create table: create table cp_in (cat integer, CP_ID integer,
       PC4_CODE varchar ( 4 ), PC4_NAME varchar ( 40 ), LANG1 varchar ( 3
), PC4_NAME2 varchar ( 40 ), LANG2 varchar ( 3 ), X integer, Y integer,
SUPERFICIE integer, Z1_81_100 integer, DENSITé97 integer, POP97_81 integer,
       BEST_SCORE integer, BEST_SCORE integer, PART_DE_ME double precision,
       PART_DES_M double precision, BOITES_à_C integer, PART1 integer)

I can import the file with v.format.

Moritz

Problem seems to be in 'é' and 'à' which dbf driver does not accept,
(but postgres yes). Another problem is BEST_SCORE 2x, what is original name?
BEST-SCORE? DBF may contain characters which are not accepted by SQL
('#','-'), these chars are currently simply replaced by '_', which probably
resulted in duplicate BEST_SCORE.
You can try to rename column names of input table.

Radim

Radim Blazek said:

On Tuesday 27 May 2003 16:33, Moritz Lennert wrote:

Hello,

I'm trying to import a shapefile into GRASS5.1 using v.in.ogr. I get the
following message when trying to import:

v.in.ogr dsn=/home/mlennert out=cp_in layer=cp
dbmi: Protocol error
dbmi: Protocol error
ERROR: Cannot create table: create table cp_in (cat integer, CP_ID
integer,
       PC4_CODE varchar ( 4 ), PC4_NAME varchar ( 40 ), LANG1 varchar (
3
), PC4_NAME2 varchar ( 40 ), LANG2 varchar ( 3 ), X integer, Y integer,
SUPERFICIE integer, Z1_81_100 integer, DENSITé97 integer, POP97_81
integer,
       BEST_SCORE integer, BEST_SCORE integer, PART_DE_ME double
precision,
       PART_DES_M double precision, BOITES_Ã _C integer, PART1 integer)

I can import the file with v.format.

Moritz

Problem seems to be in 'é' and 'à ' which dbf driver does not accept,
(but postgres yes). Another problem is BEST_SCORE 2x, what is original
name?
BEST-SCORE? DBF may contain characters which are not accepted by SQL
('#','-'), these chars are currently simply replaced by '_', which
probably
resulted in duplicate BEST_SCORE.
You can try to rename column names of input table.

That was it. Thanks a lot, Radim.

Now I have the next problem:

g.rename vect=cp_clean,cp
WARNING: Vectors are not supported by g.rename

Is there another way to rename vector files in 5.1 ?

Moritz

On Wednesday 28 May 2003 10:07, Moritz Lennert wrote:

> Problem seems to be in 'é' and 'à' which dbf driver does not accept,
> (but postgres yes). Another problem is BEST_SCORE 2x, what is original
> name?
> BEST-SCORE? DBF may contain characters which are not accepted by SQL
> ('#','-'), these chars are currently simply replaced by '_', which
> probably
> resulted in duplicate BEST_SCORE.
> You can try to rename column names of input table.

That was it. Thanks a lot, Radim.

Here you could realy say: How awful! I cannot rename all OGR datasources! Etc.
The problem here, is the same as with table names for attributes (vector names
may have characters not allowed in SQL ('.','-').
Any ideas for name mangling are welcome. Requirements for new name:
- similar to original
- simple enough for user
- using only chars accepted by SQL (for tables and columns)

Now I have the next problem:

g.rename vect=cp_clean,cp
WARNING: Vectors are not supported by g.rename

Is there another way to rename vector files in 5.1 ?

Would it be a problem to do g.copy + g.remove?

As I mentioned in code:
    /* Vectors are not supported because I don't know how should work:
    * 1. Should be all attribute tables renamed?
    * 2. Should be all attribute tables moved to current default driver/database?
    * 3. Should be PostGis tables renamed?
    * 4. Should be PostGis tables moved to current default PostGis database? */

Ideas welcome again.

Radim

Radim Blazek said:

On Wednesday 28 May 2003 10:07, Moritz Lennert wrote:

> Problem seems to be in 'é' and 'à ' which dbf driver does not accept,
> (but postgres yes). Another problem is BEST_SCORE 2x, what is original
> name?
> BEST-SCORE? DBF may contain characters which are not accepted by SQL
> ('#','-'), these chars are currently simply replaced by '_', which
> probably
> resulted in duplicate BEST_SCORE.
> You can try to rename column names of input table.

That was it. Thanks a lot, Radim.

Here you could realy say: How awful! I cannot rename all OGR datasources!
Etc.
The problem here, is the same as with table names for attributes (vector
names
may have characters not allowed in SQL ('.','-').
Any ideas for name mangling are welcome. Requirements for new name:
- similar to original
- simple enough for user
- using only chars accepted by SQL (for tables and columns)

Personnally I don't have any problem respecting basic rules about how to
name columns in a table...

Now I have the next problem:

g.rename vect=cp_clean,cp
WARNING: Vectors are not supported by g.rename

Is there another way to rename vector files in 5.1 ?

Would it be a problem to do g.copy + g.remove?

As I mentioned in code:
    /* Vectors are not supported because I don't know how should work:
    * 1. Should be all attribute tables renamed?
    * 2. Should be all attribute tables moved to current default
driver/database?
    * 3. Should be PostGis tables renamed?
    * 4. Should be PostGis tables moved to current default PostGis
database? */

Ideas welcome again.

I'm not familiar enough with 5.1, yet, to be able to judge anything
concerning these questions, so in the meantime g.copy+g.remove will just
do fine.

Moritz

Radim Blazek wrote:

Here you could realy say: How awful! I cannot rename all OGR
datasources! Etc.
The problem here, is the same as with table names for attributes
(vector names may have characters not allowed in SQL ('.','-').
Any ideas for name mangling are welcome. Requirements for new name:
- similar to original
- simple enough for user
- using only chars accepted by SQL (for tables and columns)

Change all non-alphanumeric characters to underscores; prepend a
leading underscore if the name starts with a digit.

That satisfies all three stated conditions, although it doesn't
satisfy the (unstated) condition that distinct map names correspond to
distinct table/column names (no collisions).

There are two basic options for avoiding collisions:

1. Add a numeric suffix if the desired name is already in use; keep
incrementing the suffix until no collision occurs.

2. Use a scheme similar to URL-encoding, i.e. each non-alphanumeric
character (including underscores) is replaced by an underscore then
the two hex digits for the character's code.

3. Redefine the syntax of GRASS map names to match SQL; e.g. no case
sensitivity, and either:
a) no non-alphanumeric characters except underscore, or
b) all non-alphanumeric are equivalent (i.e. represented by an
underscore internally, so foo.bar and foo_bar are the same map).

All have disadvantages.

Option 1 is non-deterministic, in the sense that the translation
depends upon which maps already exist; also, you would have to store
the original name somewhere.

Option 2 is messy; particularly given that GRASS map names are
case-sensitive and SQL table/column names aren't, so you would also
have to encode all upper-case characters.

Option 3 means that anyone who wishes to preserve the names of their
existing maps loses.

> Now I have the next problem:
>
> g.rename vect=cp_clean,cp
> WARNING: Vectors are not supported by g.rename
>
> Is there another way to rename vector files in 5.1 ?

Would it be a problem to do g.copy + g.remove?

As I mentioned in code:
    /* Vectors are not supported because I don't know how should work:
    * 1. Should be all attribute tables renamed?
    * 2. Should be all attribute tables moved to current default driver/database?
    * 3. Should be PostGis tables renamed?
    * 4. Should be PostGis tables moved to current default PostGis database? */

Treat vector maps like reclassed rasters. I.e. a vector map is
basically a file which tells you where to get the actual data from.
This satisfies the "store the original name somewhere" requirement of
option 1 above.

g.rename would work the same way as for other maps, i.e. it renames
the file/directory.

--
Glynn Clements <glynn.clements@virgin.net>