[gdal-dev] RFC 35: Delete,
reorder and alter field definitions of OGR layers - Call for
even.rouault at mines-paris.org
Mon May 9 15:48:20 EDT 2011
> 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,
More information about the gdal-dev