[GRASS5] [bug #4250] (grass) v.out.ogr: CHAR columns are trimmed to 80 chars when writing shp

GRASS GIS GRASS GIS developer
,
1

Hamish wrote:

what does 'dbview -e' say about the dbf coulumns before and after export?

### the dbf BEFORE export

$ dbview -e /home/grassdata/caves_utm33/wlasnosc2/dbf/test.dbf

Field Name Type Length Decimal Pos
Cat N 11 0
Parcel no C 80 0
Maps use C 80 0
Maps class C 80 0
Maps cover C 20 0
Owner cod N 11 0
Owner nam C 249 0
Owner nmb N 11 0
Owner loc C 80 0
Tenant cod N 11 0
Tenant nam C 80 0
Tenant loc C 80 0
Host cod N 11 0
Area N 20 6
Lndrcl lev N 11 0
Lndrcl clt N 11 0

### the dbf AFTER export

$ dbview -e /home/john/test/test.dbf

Field Name Type Length Decimal Pos
Cat N 11 0
Parcel no C 80 0
Maps use C 80 0
Maps class C 80 0
Maps cover C 80 0
Owner cod N 11 0
Owner nam C 80 0
Owner nmb N 11 0
Owner loc C 80 0
Tenant cod N 11 0
Tenant nam C 80 0
Tenant loc C 80 0
Host cod N 11 0
Area N 24 15
Lndrcl lev N 11 0
Lndrcl clt N 11 0

### Interesting is that the "Area" attribute properties changed too, isn't
### that wrong?

what if you just copy the $MAPSET/dbf/ file to be with your .shp file?

If I do that, the relationship between objects in the shapefile and dbf file
is lost. Querries in QGIS prove that. Apparently the dbf is somewhat processed
by v.out.ogr when writing a shapefile.

Maciek

-------------------------------------------- Managed by Request Tracker

2

This is almost exactly the problem I had with ogr a while back (isn't fixed in 1.3.1 so I've patched my copy, maybe fixed in CVS). This problem is for mysql and postgres tables - OGR doesn't translate varchar field types. In the case when OGR can't figure out the field type, it defaults to a char type of length _80_.

I looked in the grass ogr driver source, and there's the same problem. The grass driver doesn't set *any* field lengths at all, so it defaults to 80.

ogrgrasslayer.cpp, lines 148-161.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

3

$ dbview -e /home/grassdata/caves_utm33/wlasnosc2/dbf/test.dbf

Field Name Type Length Decimal Pos
Cat N 11 0

...

Owner cod N 11 0
Owner nam C 249 0
Owner nmb N 11 0
Owner loc C 80 0

are those field names "Owner nam" or "Owner_nam"? I didn't think dbf
fields could have spaces; if two words maybe it is just reading the
first and getting confused as there are multiple "Owner"s? Or is dbview
just translating the names?

did you try sqlite instead of dbf? (doubt any improvement, but maybe
worth a try)

Hamish

4

On Sat, 8 Apr 2006 16:10:23 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> $ dbview -e /home/grassdata/caves_utm33/wlasnosc2/dbf/test.dbf
>
> Field Name Type Length Decimal Pos
> Cat N 11 0
...
> Owner cod N 11 0
> Owner nam C 249 0
> Owner nmb N 11 0
> Owner loc C 80 0

are those field names "Owner nam" or "Owner_nam"?

That's how dbview displays; in OOCalc2 they are "OWNER_COD", OWNER_NAM"
etc. respectively.

I didn't think dbf fields could have spaces; if two words maybe it
is just reading the first and getting confused as there are multiple
"Owner"s? Or is dbview just translating the names?

Columns name are OK, no doubt bout it.

did you try sqlite instead of dbf?

No.

(doubt any improvement, but maybe worth a try)

Then I'll take my time ;).

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/