[Gdal-dev] RFC 6: OGR support for querying and selection by geometry and feature style

Frank Warmerdam warmerdam at pobox.com
Tue Oct 24 23:49:51 EDT 2006


Tamas,

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
     OGRFeature like:
        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
     thread-safety issue.

  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.

Best regards,
-- 
---------------------------------------+--------------------------------------
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 mailing list