Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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? What are the rules then?

greetz

share|improve this question
add comment

4 Answers

up vote 23 down vote accepted

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. filegdb, spatialite, etc).

UPDATE: 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.

share|improve this answer
    
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
1  
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
3  
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
show 2 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
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
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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