[gdal-dev] RFC 29: OGR Set Desired Fields

Frank Warmerdam warmerdam at pobox.com
Fri Jul 30 09:44:41 EDT 2010


Martin Dobias wrote:
> Hi Tamas
> 
> On Thu, Jul 29, 2010 at 9:10 PM, Tamas Szekeres <szekerest at gmail.com> wrote:
>> Frank,
>>
>> If you refer to the OGR_GEOMETRY, OGR_GEOM_WKT, OGR_GEOM_AREA special
>> fields, both return a meaningful value (ie. an empty string) when the
>> geometry is null. In this regard it would be enough to disable only the
>> geometry column of that layer. However since the geometry column is not
>> necessarily be added to the field collection at OGRFeatureDefn, disabling
>> the geometry column might probably be set at OGRFeatureDefn while the others
>> at OGRFieldDefn in my suggested approach:
>>
>>
>> for( int iField = 0; iField < poDefn->GetFieldCount(); iField++ )
>> {
>>   if (poDefn->GetFieldDefn(iField)->IsIgnored())
>>     continue;
>>
>>   // fetch field
>> }
>>
>> if (!poDefn->IsGeometryIgnored())
>>
>> {
>>   // fetch geometry field
>> }
> 
> I like this approach - OGRFeatureDefn / OGRFieldDefn look like good
> places where to store the flag whether fields or geometry should be
> ignored.
> 
> Though I'm not sure how to proceed with API for setting what should be
> ignored. In your further mail, you suggest
> OGRFeatureDefn::EnableGeometryColumn(bool) for geometry (and I presume
> something similar for fields, e.g. OGRFieldDefn::SetIgnored(bool) ).
> This would however bring some inconsistency, because documentation for
> OGRLayer::GetLayerDefn() states that the returned OGRFeatureDefn
> shouldn't be modified. But this statement could be probably relaxed so
> that changing ignore state of fields/geometry/style will be allowed?

Martin,

I do not agree with applications directly changing the OGRFieldDefn, even
if ultimately the flag is stored here.  There needs to be a virtual method
on the OGRLayer (IMHO) so that drivers have an opportunity to hook the
method to do something special when the list of desired fields changes.

I'm disappointed that several new methods will be added to the API, with
distinct methods for geometry, and style.  I am always fighting to
minimize the breadth of the API, within reason.  Hopefully you can weld
these results into a RFC proposal we can vote on reasonably soon.

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    | Geospatial Programmer for Rent



More information about the gdal-dev mailing list