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

[Jez Walters]

Frank,


If we "connect this to the -select option of ogr2ogr" as you suggest, it would probably be helpful to specify fields by name rather than by number in order to accommodate the OS MasterMap data.

At the risk of repeating myself from another thread, the OS MasterMap Topology Layer vector data has identical field names (for any given layer) in all data chunks, but the field numbers are different in different chunks.  Just to complicate matters, some fields are entirely missing in some data chunks too!  :-(


Regards,


Jez


-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
Sent: Wednesday 21 July 2010 15:46
To: Martin Dobias
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Martin Dobias wrote:
> Hi,
> 
> based on the discussion about optimizing the performance of reading
> features in OGR few days ago, I've prepared an RFC that proposes API
> for limiting which fields will be fetched when reading features:
> 
> http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields
> 
> Any comments or suggestions are highly welcome.

Martin,

Some thoughts:

1) Should there be a TestCapability() value indicating whether the field selection option works for a particular driver?  It doesn't seem critical to me.

2) Should we try to overload this function to also allow selection or deselection of the "special" fields geometry and style?  We try to treat them a bit like fields in things like http://trac.osgeo.org/gdal/wiki/rfc6_sqlgeom.

3) I dislike the passing of an unnecessary nNumFields parameter and unintuitive use of it as a special flag.

4) I think you need to make it clear whether where the method is implemented.  I get the impression the OGRLayer class will implement the method, and the OGRLayer class will keep around a desired fields array.  Should driver specific classes be able to override this method to detect when the desired list changes?   I think so, even though most drivers using the desired fields functionality will not need to do so.

5) I'd like the RFC to be clear that some (many) drivers may not support this functionality in which case all fields will be returned instead of some being null.

As an alternative, if we would like to support the "special fields" for geometry and style perhaps we should offer a method like:

virtual OGRErr OGRLayer::SetIgnoredFields( const char **papszFields );

The argument is a list of fields to be ignored, by name, and the special field names "OGR_GEOMETRY" and "OGR_STYLE" will be interpreted to refer to the geometry and style values of a feature.

Passing NULL for papszFields will clear the ignored list.

The method will return OGRERR_NONE as long as all the field names are able to be resolved, even if the method does not support selection of fields.

I chose passing by field name so that we could handle OGR_GEOMETRY, OGR_STYLE and possibly some other special fields in the future.  I changed the sense to "ignored" so that we wouldn't accidentally drop things like geometry and style just because they weren't explicitly listed in a desired list.

Note, I'm willing to implement this functionality for a bunch of drivers I think might benefit, and I also think the RFC should indicate we will connect this to the -select option of ogr2ogr.

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

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


The information transmitted is intended only for the person
or entity to which it is addressed and may contain
confidential and/or privileged material. If you are not the
addressee, any disclosure, reproduction, copying,
distribution, or other dissemination or use of this
communication is strictly prohibited. If you have received
this transmission in error please notify the sender
immediately and then delete this email.

Any representations or commitments expressed in this email
are subject to contract.

This message has been scanned for viruses and dangerous
content. However, it is essential that the recipient also
checks this message using commercially available mail
scanning and anti-virus software. IPL Information Processing
Limited accepts no liability for any loss or damage resulting
from any virus or other dangerous content in this message.

IPL Information Processing Limited is registered in England
and Wales under company registration number 1418818.
Registration took place at Cardiff on 10 May 1979. IPL
Information Processing Limited's registered office and
normal place of business is Eveleigh House, Grove Street,
Bath, BA1 5LR, United Kingdom. IPL is also registered for
Value Added Tax (VAT) under registration number GB 601 2931 83.