gvSIG bugs #2672
DBF field names max length is 11 instead of 10
Status: | Closed | % Done: | 100% | |
---|---|---|---|---|
Priority: | Normal | Spent time: | - | |
Assignee: | Joaquín del Cerro Murciano | |||
Category: | Document table | |||
Target version: | 2.1.0-2249-testing | |||
Severity: | Major | Add-on version: | ||
gvSIG version: | 2.1.0 | Add-on build: | ||
gvSIG build: | 2234 | Add-on resolve version: | ||
Operative System: | Add-on resolve build: | |||
Keywords: | dbf | Proyecto: | ||
Has patch: | Yes | Hito: | ||
Add-on name: | Unknown |
Description
DBF field names max length is 11, but it should be 10 as defined in the shapefile format specification: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
Related issues
History
#1 Updated by Antonio Falciano almost 10 years ago
In fact, if I don't miss something, there is:
public static final int MAX_FIELD_NAME_LENGTH = 11;
in the following two classes:
- package org.gvsig.fmap.dal.store.dbf, class DBFStoreProvider
- package org.gvsig.fmap.dal.store.dbf.utils, class DbaseFile
Then in
package org.gvsig.fmap.dal.store.dbf.utils, class DbaseFileHeader
if (tempFieldName.length() > 11) { tempFieldName = tempFieldName.substring(0, 11); warn("FieldName " + inFieldName + " is longer than 11 characters, truncating to " + tempFieldName); }
and in
package org.gvsig.fmap.dal.store.dbf.utils, private void fillBuffer
if (fad.getName().length() > 11) { throw new FieldNameTooLongException("DBF file", fad.getName()); }
#2 Updated by Antonio Falciano almost 10 years ago
- Status changed from New to Awaiting response
The DBF field names max length was 10 in gvSIG 1.x, so this would be a regression for gvSIG 2.1. It can't be considered an enhancement, because there could be interoperability issues with other applications. The DBFs and indirectly the SHPs produced by gvSIG 2.1 are not standard ones right now (build 2238).
#3 Updated by Álvaro Anguix almost 10 years ago
- Assignee set to Joaquín del Cerro Murciano
#4 Updated by Antonio Falciano over 9 years ago
Because interoperability matters, is it suitable for the 2.1.0-rc2?
#5 Updated by Antonio Falciano over 9 years ago
- % Done changed from 0 to 100
- Status changed from Awaiting response to New
- File MAX_FIELD_NAME_LENGTH.patch added
I attach a patch that fixes this bug. Hope this helps!
#6 Updated by Álvaro Anguix over 9 years ago
- Has patch set to Yes
#7 Updated by Antonio Falciano over 9 years ago
- Target version set to 2.1.0-2259-rc3
#8 Updated by Joaquín del Cerro Murciano over 9 years ago
- Target version changed from 2.1.0-2259-rc3 to 2.1.0-2248-testing
- Status changed from New to Fixed
#9 Updated by Antonio Falciano over 9 years ago
- Target version changed from 2.1.0-2248-testing to 2.1.0-2259-rc3
- Status changed from Fixed to New
It seems that the correction of ExporttoShapeService.java contained in the patch is missing in gvsig-desktop:r41746, so I have to reopen this ticket. Furthermore, the Export to Shape seems to be broken at the moment (build 2248). I'll open a new ticket about it.
#10 Updated by Antonio Falciano over 9 years ago
- Target version deleted (
2.1.0-2259-rc3) - Status changed from New to Fixed
Target version: 2.1.0-testing-2248
I see that the patch of ExporttoShapeService.java is made in gvsig-desktop:r41745, sorry.
I can't verify if it really works, because I can't export or create new shape layers at the moment (build 2248).
#11 Updated by Joaquín del Cerro Murciano over 9 years ago
- Related to gvSIG bugs #2856: Can't create a new shape layer added
#12 Updated by Joaquín del Cerro Murciano over 9 years ago
- Target version set to 2.1.0-2259-rc3
#13 Updated by Joaquín del Cerro Murciano over 9 years ago
- Target version changed from 2.1.0-2259-rc3 to 2.1.0-2249-testing
#14 Updated by Antonio Falciano over 9 years ago
- Status changed from Fixed to Closed