I'm trying to create custom .shp files by drawing polygons on a new layer in Google Maps Engine, exporting that .kml file, and then converting that file to a .shp file with ogr2ogr.

If I run a command like this:

ogr2ogr -f 'ESRI Shapefile' foo.shp foo.kml

I get the following printed to stdout:

Warning 6: Normalized/laundered field name: 'Description' to 'Descriptio'.

This causes a problem downstream because when I load the .shp file into a r-tree and then query it to perform reverse geocoding, I get back a field "Descriptio" instead of "Description", which just looks odd. Moreover, this happens despite the fact that when I open the .kml file in vim, I don't see any "description" tag anywhere.

So my question is: is there any way around this? Can I alter the KML file in any way to prevent ogr2ogr from complaining that it needs to normalize/launder the field Description?

Please let me know if this question is written poorly. It's my first time on GIS Stack Exchange and I'm not at all trying to be difficult/annoying/insufferable.


This is a known limitation of the .dbf files that accompany the shapefiles.

This among other reasons is why the shapefile format is being slowly phased out and replaced by more robust formats.

As I see it, the only reasons the shapefile is still around is because it still can be read by every GIS software under the sun.

As for your problem you have two options :

  1. You can decide on a new nomenclature to hold your fields taking into account the 10 character limit.
  2. You can choose a more modern format for your data that doesn't have the said limitation.

If you run ogr2ogr --formats | grep write you can see a list with all the formats your ogr's installation can handle as output.

  • To add to this answer, if you decide to go the #1 route and still want to preserve your field names, you could create a metadata lookup table that has all your field names as rows, with two columns: abbrev_nam and full_nam. Then, whenever you transfer your data from the shapefile format, use that lookup table to restore your field names. – Conor Sep 22 '13 at 18:12
  • I'm specifying -f GPKG and field names are still normalized to 10 characters... – Stefan Jul 19 '19 at 13:32
  • Hi @Stefan GPKG is most definitely able to handle columns with 10 characters. You can verify this if try to make a new GeoPackage with a recent qgis version and try to add a column with more than 10 chars as name. – nickves Jul 22 '19 at 12:47
  • I'm pretty sure that GPKG can handle it, but ogr2ogr doesn't seem to respect this property. Maybe I was just doing something wrong. Not investigating further for now. :) – Stefan Jul 23 '19 at 12:45

The good thing about using the library instead of the command line utilities is that you have more control over the whole thing, using the C# bindings, I splitted the field name at the limit:

// Get the layer definition.
OSGeo.OGR.FeatureDefn copyLayerDefn = layer.GetLayerDefn();

// Create a new feature.
OSGeo.OGR.Feature outFeature = new OSGeo.OGR.Feature( copyLayerDefn );

int fieldCount = copyLayerDefn.GetFieldCount();

for( int i = 0; i < fieldCount; ++i )

    OSGeo.OGR.FieldDefn tempFieldDefn = copyLayerDefn.GetFieldDefn(i);

    string fieldName = tempFieldDefn.GetName();

    if( fieldName.Length > 10 )

        Console.WriteLine( "The field's name: " + fieldName + ", is longer than 10 characters. The field's name will be truncated to the first 10 characters." );

        fieldName = fieldName.Substring( 0, 9 );


    OSGeo.OGR.FieldDefn fieldDfn = new OSGeo.OGR.FieldDefn( fieldName, OSGeo.OGR.FieldType.OFTString );

    if( outLayer.CreateField( fieldDfn, 0 ) != OSGeo.OGR.Ogr.OGRERR_NONE )

        Console.WriteLine( "Unable to create the field: {0}" + fieldDfn.GetName() );



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.