[gdal-dev] RFC 35: Delete, reorder and alter field definitions of OGR layers - Call for discussion

[Even Rouault]

Martin,

> I have just two comments:
> - is the alternation of hte field definition going to have some rules
> how the existing data should be converted to the new type or will the
> driver itself choose how to convert the data? The latter option is
> surely the easier one, but it would be probably good to guarantee at
> least some expected conversions: int <-> text, float <-> text, round
> the number when lowering precision etc.

I've added a new section 'Altering field types' in the RFC : 

"""
 This RFC does not attempt to guarantee which type conversions will be 
possible. It will depend on the capabilities of the implementing drivers.
For example, for database drivers, the operation will be directly done
on the server side (through a 'ALTER TABLE my_table ALTER COLUMN my_column 
TYPE new_type' command for the PG driver). So some conversions might be 
possible, others not...

It is however expected that converting from any type to OFTString will be 
supported in most cases when AlterFieldDefn() is supported.

Drivers that don't support a conversion and that were required to do it 
(ALTER_TYPE_FLAG set and new_type != old_type) should emit an explicit error.
"""

I've also implemented the conversion from any type to OFTString for the 
shapefile driver and upload a v3 of the patch.

Converting from text to a numeric type seems difficult, because you have no 
guarantee that the content of all features for this field is numeric... So this 
would raise the question : what to do when the conversion is not possible for 
at least one value ? : refuse the whole conversion, or convert what can be 
converted and put some default value in case the conversion is not possible. 
To come back to the PG driver, it refuses to convert from string to integer, 
even when it is possible. From the error message, I suppose it would need a 
USING clause to provide a conversion expression, but I didn't go as far as 
this for now. Hence the rationale for not promising too much in the RFC.

> - what is actually the motivation behind reordering of the fields? Is
> that just for aesthetical reasons? (e.g. zip code should be next to
> the city name)

The reasons given by Stephen are quite good.

I mainly implemented it for the completness of the possible field 
manipulations, as suggested by Frank in ticket #2671. One use case I see is an 
improved user experience when you open a table and want to see the most 
significant columns at the beginning without needing to scroll to the end. I'm 
not sure which drivers, apart from shapefile, will be able to implement it 
actually. There are not so many formats that can implement reordering of fields 
in place. The implementation in some cases might be possible by using an 
intermediate temporary file. This would be needed for example to implement this 
for any text based format, such as CSV, but for that very same reason, CSV 
driver cannot add a field to a layer where features have already been written).

Tanks for your comments,

Even