# Bypassing 10 character limit of field name in shapefiles?

I'm exporting geometry with attached text attributes from oracle database to esri shapefile format (.shp) with Java and Geotools library.

Attribute columns in our database have names with more than 10 characters, and Geotools forces to truncate them. I understand that it's due to .shp or .dbf files specification.

I can workaround this, by creating some simple txt file with "shrtname"="The full and long name", but obviously it won't be understand and imported by any other software than ours.

Is there official way to do the mapping from short field names to long full-text names?

For example, xml file next to all other .shp .dbf .shx files.

Sorry, the answer is no. You have to roll out your own field mapper and only software that uses your mapper will understand it. You could use other formats that do not have this limitation though (e.g. file geodatabase, spatialite, etc).

When people choose shapefiles (and insist on them) as their main format, it is usually chosen for interoperability - think of it as adhering to a spec. If you choose to roll your own field mapper, you are basically doing quite the opposite - since you are doing things outside of a spec - you have created your "extended spec".

Have I done this in the past? Yes. And it most certainly always turns to more of a pain than actually solving a problem because every time you try to open the shapefiles into anything else that can read/write shapefiles, you end up with a table with a whole bunch of hard to understand fields.

At that point, I would ask you, why are you using shapefiles? Either come up with a workflow solution that sticks with the shapefile spec and its limitations, or change file formats. Everything else is just a recipe for headaches.

• unfortunately our customer requires shapefiles :/ – denu Oct 16 '11 at 8:25
• then no other option :( – Ragi Yaser Burhum Oct 16 '11 at 15:30
• The other options are work-arounds, some of which are suggested below. – user3461 Oct 17 '11 at 12:28
• I updated my answer above to explain why work-arounds are a bad idea when your customer just wants shapefiles. – Ragi Yaser Burhum Oct 17 '11 at 14:41
• As a consultant, my experience has been that finding a way to help a client is almost always preferable to saying "there's no way it can be done." Finding out why they need shapefiles is a good start, and you might be able to agree on an alternative, but that's not always going to be the case. Incidentally, one of the best ways to get ideas for workarounds is to post a notice on the Web that says "there's no other option." :-) – whuber Oct 17 '11 at 15:24

There is a standard way to deal with this, although your clients might not be completely happy with it: you export two files, a shapefile and a data file in a format their software can read. The shapefile has only a unique identifier, [Id], for attributes. The data file has several attributes: [Id] to match the shape, [Field] to provide the field name, [Type] to indicate its type, and one attribute of each possible data type to store the value. Each field in the original file is stored as a record in this data file.

For example, a source table looking like this:

[Shape] [Id] [Name]     [Population2010]
shape1  A1   California         37253956
shape2  A2   Texas              25145561
shape3  A3   Wyoming              563626


would have a corresponding data file

[Id] [Field]        [Type]  [Text]     [Integer]
A1   Name           Text    California    <Null>
A1   Population2010 Integer <Null>      37253956
A2   Name           Text    Texas         <Null>
A2   Population2010 Integer <Null>      25145561
A3   Name           Text    Wyoming       <Null>
A3   Population2010 Integer <Null>        563262


It should be obvious how to use these data in any RDBMS and how to convert back and forth between the two formats.

If your customer is using ArcGIS, you could provide a script to assign field aliases in bulk. This would give them the appearance of long field names when they're using the data.

Similar scripting may work to provide aliases in other GIS packages, too.

• I am of course delighted to see one of my answers held in high regard, but that answer applies to geodatabases and not to shapefiles. They can't hold aliases, though in Arcgis one can save a layer file which remembers the alias. – matt wilkie Oct 18 '11 at 18:59
• Noted, and thanks for the clarification. Also note that the aliases could be saved with an MXD, too. I suggested that the scripts should be provided to the customer since they would have to be re-run anytime the shapefiles were added to a new map. – user3461 Oct 18 '11 at 19:19

The easiest route to take is to store ONLY your geometry as a shapefile, for the excellent geometry editing capabilities that exist in many GIS applications, YET store all your field data (or the bulk of them) in sqlite as tables. Join them as necessary to research your field data.

BUT If you need to edit the tables while doing spatial queries, or selecting the shapefile features in QGIS, you will need to forget [shapefiles joined to sqlite tables] as an option, and instead export everything to Spatialite. Learn to use Qspatialite and Spatialite_GUI (they are both complimentary to each other with many features the other lacks-- you will need and use both if you do many things with SQLITE)

Its important to keep in mind those tables (joined to shapefile) would not be editable at the same time as the join. And so migrating to Spatialite would be an excellent alternative to shapefiles. It keeps with the simplicity and portability of shapefiles while offering most of the virtues of a SQL database, without the complexity of PostgreSQL.

Temporary fix can be, saving as TAB file, which can have column names up to 31 characters long.

• not sure this really answers the question – nmtoken Sep 25 '18 at 14:37