[Gdal-dev] RFC 6: OGR support for querying and selection
by geometry and feature style
warmerdam at pobox.com
Tue Oct 24 23:49:51 EDT 2006
I'm quite pleased with RFC-6. Am I correct in understanding that
your existing patch addresses fetching the special fields, and using
them in WHERE clauses?
Some things I'd like to see in the proposal:
1) I think we should have constants for the special fields! All
these case statements with "1", "2", etc in them scare me!
2) I'd like to be able to register a function to fetch the special
fields so we don't have to have the special fetch code appearing
in so many places. At the very least a way of registering a function
in an array parallel to the SpecialFieldNames and SpecialFieldTypes
arrays. But perhaps it would be better to actually have methods on the
const char *GetSpecialFieldAsString( int nSpecialFieldCode );
int GetSpecialFieldAsInteger( int nSpecialFieldCode );
3) I'd like the RFC to include a section on "how to add a new special
field". Hopefully if the special field accessor on the OGRFeature
idea works, it won't be too complicated.
4) I'm a bit concerned about the lifespan for dynamically allocated
return strings. How carefully have you analysed the lifespan for
the strings for which you propose the StringFinalizer class? If
the lifespan is appropriate, I was thinking that perhaps we could
hold them in the OGRFeature in a temporary string value that would
last till the next Get*AsString() request on that particular
OGRFeature. Would that be a long enough life span, even if there
were multiple special fields that required dynamically allocated
values? Actually, I'd like to use the current approach for regular
non-string values requested on OGRFeature::GetFieldAsString().
Currently these are held in a static buffer, causing a substantial
5) I'd like to see a section in the RFC describing the test suite items
you will add to the GDAL autotest.
6) I think the backward compatibility section of the RFC should mention
that the new special fields will potentially conflict with regard
fields with the given names, and to describe which will take precidence
when there is a conflict.
I think the feature this RFC describes will be a fantastic addition to the
OGR SQLish engine. If you wish, I'd be willing to implement items (4) and
(5) above if you can take care of the rest.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
More information about the Gdal-dev