Opened 10 years ago

Closed 10 years ago

#4448 closed enhancement (fixed)

Shapefile driver has inconsistent default length for text fields

Reported by: ryanl Owned by: warmerdam
Priority: normal Milestone: 1.10.0
Component: OGR_SF Version: svn-trunk
Severity: normal Keywords: shapefile
Cc: robert.coup@…, janis.elmeris@…

Description (last modified by ryanl)

When creating a shapefile the default width of a String field is 80 instead of the max 255. Both the FileGDB and Mitab drivers have the default set to the maximum size of the field (2147483647 and 254 respectively) The impact of this is if there is a field with string length undefined will be incorrectly truncated to 80 chars.

Attachments (1)

stringlength.diff (551 bytes ) - added by ryanl 10 years ago.
fix against r23734

Download all attachments as: .zip

Change History (10)

by ryanl, 10 years ago

Attachment: stringlength.diff added

fix against r23734

comment:1 by ryanl, 10 years ago

Description: modified (diff)

comment:2 by ryanl, 10 years ago

Description: modified (diff)

comment:3 by janise, 10 years ago

Cc: janis.elmeris@… added

comment:4 by janise, 10 years ago

I would think this is more a defect than an enhancement. Or is there a way I can define the string length when converting from GPX to Shapefile?

comment:5 by Even Rouault, 10 years ago

Are you sure this is really necessary in trunk ? I have implemented a few months ago an autogrowing for shapefiles that should cope with the resizing of the column up to 255 chars if necessary.

For example, if you have foo.csv :


and then : ogr2ogr foo.dbf foo.csv

ogrinfo foo.dbf :

C:\gdal_trunk\gdal>ogrinfo foo.dbf -al
INFO: Open of `foo.dbf'
      using driver `ESRI Shapefile' successful.

Layer name: foo
Geometry: None
Feature Count: 1
Layer SRS WKT:
id: String (80.0)
foo: String (255.0)
  id (String) = 1
  foo (String) = 012345678901234567890123456789012345678901234567890123456789012

It is not very wise to default to 255 characters by default since in most situations the strings are much shorter and that would result in bigger files than necessary.

comment:6 by janise, 10 years ago

If 80 characters limit is only by default and I can actually change it, I would be OK with that. I can pass the 255 character length or whatever I need as an argument, no problem. If there was such an option.

The converter should either offer an option at which length to truncate to (255 being the maximum), or dynamically read the max length of the source data fields and set the target max length to that.

Simply losing data upon conversion (not because of the target data type) seems a bug/defect to me.

comment:7 by Even Rouault, 10 years ago

janise, did you read my above comment ? I believe that this is now fixed in GDAL trunk. Perhaps you could just retry and see if this works for you.

comment:8 by janise, 10 years ago

OK, if it is fixed, then it's all right. I thought that you doubt that this fix/improvement "is really necessary in trunk".

I'm using GDAL 1.9.1 at the moment. When I get GDAL 1.9.2, then probably this will be fixed then.

comment:9 by Even Rouault, 10 years ago

Milestone: 2.0.0
Resolution: fixed
Status: newclosed

No, you won't get it in GDAL 1.9.2. Currently GDAL trunk = GDAL 2.0dev. If you are on Windows, you can download it at (the -developmenet packages). Otherwise you'll have to compile it from sources.

I'm closing this ticket, because I think that the need expressed is now satisfied by the improvement done in

Note: See TracTickets for help on using tickets.