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: [email protected] [mailto:[email protected]] On Behalf Of Frank Warmerdam Sent: Wednesday 21 July 2010 15:46 To: Martin Dobias Cc: [email protected] 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, [email protected] 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 [email protected] 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. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
