Bypassing 10 character limit of field name in shapefiles?

Question

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.

Answer 1

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

---

Some word of advice about the workarounds from personal experience.

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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