[gdal-dev] RFC 21: OGR SQL type cast and field name alias

[Tamas Szekeres]

2008/1/25, Even Rouault <even.rouault at mines-paris.org>:
> I'm probably missing something as I have never used the OGR styling
> capability, but as far the specific motivation explained in the RFC is
> concerned, couldn't it be possible, and more simple, to hack directly in
> ogrfeature.cpp a width big enough for the OGR_STYLE special field (it can be
> made very big as the shape driver automatically crop it to 255) ?

Even,

My motivation described out there is only a use case this enhancement
can help with. However I certainly keep in mind to provide an option
for a broader of interest rather than making a local change.
Setting the default length of the OGR_STYLE field would neither help
to solve my original issue, since I'd like to set the length to the
length of the largest value instead of 255 which was only an example
in the proposal. I could also have written as well

ogr2ogr -f "ESRI Shapefile" -sql "select *, CAST(OGR_STYLE AS
character(82)) from rivers" rivers.shp rivers.tab

for example.

To determine the largest length I could also have included some string
functions, like

"select max(length(OGR_STYLE)) form rivers"

but I haven't addressed this in the proposal.


> Your proposal suggests that the user is aware that DBF strings cannot be
> bigger than 255 characters, which is not obvious (for example, we don't even
> document that in drv_shapefile.html. Would be good to do ;-) )

No, this was only an example. I could also have used a bigger value
here as well however the shapefile driver will possibly truncate the
strings to 255 in length.

> If I remember well too, FrankW also proposed to add an option to ogr2ogr that
> would scan all the features to compute the required with in case it's not set
> by the input driver. That could also help in your use case. One drawback is
> that ogr2ogr would need to run in 2 passes when this option is used.

I would forcibly discourage this solution to alter the concept how
ogr2ogr is working only because of the OGR_STYLE field.

I think this change cannot be compared in value with the option to
implement additional functionality can be found anyway in the SQL92
specification. I consider it's trivial to establish a support for
changing the name and the type of the field when making data
transformations between the OGR supported data sources.


Best regards,

Tamas