Shapefile driver has inconsistent default length for text fields

[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.

[ryanl]

fix against r23734

[janise]

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?

[Even Rouault]

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 :

id,foo
1,0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789ABCDE

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:
(unknown)
id: String (80.0)
foo: String (255.0)
OGRFeature(foo):0
  id (String) = 1
  foo (String) = 012345678901234567890123456789012345678901234567890123456789012
34567890123456789012345678901234567890123456789012345678901234567890123456789012
34567890123456789012345678901234567890123456789012345678901234567890123456789012
345678901234567890123456789ABCDE

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.

[janise]

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.

[Even Rouault]

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.

[janise]

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.

[Even Rouault]

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 ​http://www.gisinternals.com/sdk/ (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 http://trac.osgeo.org/gdal/changeset/23972