[PATCH] delete fields in .dbf

[wonder]

I've developed a patch to allow deletion of fields in an existing DBF file. It's done by overwriting header and moving records in DBF file (without creating a new temporary file).

The patch adds new C++ function OGRLayer::DeleteField(int field) and C API equivalent OGR_L_DeleteField.

One downside is that after deletion of a field, the .dbf file is not truncated as there's no hook for truncation. However this doesn't affect overall functionality.

[wonder]

patch for deletion of field in dbf

[wonder]

Btw. if you like the patch I'm willing to create another one to support adding fields to existing DBF files in similar way as deletion is done.

Martin

[warmerdam]

Martin,

Adding a DeleteField() method for OGRLayer's would require an RFC voted on by the GDAL PSC. I'm personally a bit leery about it, but if it were pursued I think it might be best approached as part of more general manipulation of the field list (reordering, modifying type).

Also, it is too late for such capabilities in GDAL/OGR 1.6, now in beta.

I would be very receiptive to an implementation of CreateField() on existing .dbf files which could be incorporated if available in time for 1.6.0 beta2.

[warmerdam]

I have applied the portion of the patch that adds DBFDeleteField() upstream in shapelib. This can be valuable to some people even if OGR does not support deleting fields.

[lutra]

Any chance to see this applied in the next gdal/ogr release?

[wonder]

Frank,

can we try to resolve this ticket to get this functionality into next release (1.8 I guess)? I'm willing to create an RFC, however I'd like to skip the general manipulation as you've proposed and I'd ask only for DeleteField method. Basically the reordering and modifying types of attributes aren't really much requested features and would increase the scope of work significantly.

Martin

[Stemby]

Is there any news?

Carlo

[warmerdam]

There has been no action.

[enrico80]

this is a very useful function, when will it implement?

[Even Rouault]

Proposed implementation of RFC35

[Even Rouault]

v2 of implementation of rfc35

[Even Rouault]

Example of use of RFC35

[Even Rouault]

v3 of implementation of rfc35

[Even Rouault]

Shapelib part of RFC35 implementation

[warmerdam]

Shapelib patched as suggested, and results brought back downstream into GDAL trunk (r22367).

[Even Rouault]

r22368 /trunk/gdal/ogr/ (9 files in 3 dirs): RFC35 : core of implementation (#2671)

r22369 /trunk/gdal/ogr/ogrsf_frmts/ (6 files in 3 dirs): RFC35 : implementation in Shapefile, Memory and PG drivers (#2671)

r22370 /trunk/gdal/swig/ (4 files in 4 dirs): RFC35: SWIG bindings (#2671)

r22371 /trunk/autotest/ogr/ (ogr_pg.py ogr_rfc35_mem.py ogr_rfc35_shape.py): RFC35: autotest for implementation in Shapefile, Memory and PG drivers (#2671)