[Gdal-dev] Evolution of OGRLayer ?

Jean jeanhri4 at ifrance.com
Mon Sep 22 04:24:07 EDT 2003

Here is a proposition for OGRLayer

There is two way to access a Feature with an OGRLayer
1 - A sequential access via GetNextFeature.
2 - A direct access via its FeatureID : GetFeature(long aFeatureID).

Some records provider (like ADO for example) bring another type of acess
: GetFeature(long aRecordPositionInCurrentQuery)

I believe that this very access might be sometimes intersting. 
Indeed let's imagine a Grid display, client of an OGRLayer. A grid does
not display the whole range of features but only some of them, from
record n to record n + d, where d is the record's number displays on

With the 1- feature access, the grid display algorithm could look like
this :

//Move to first Record
//Then, move to Record n.
For(long i(0); i < n; i++)
 //Note that GetNextFeature, iterate and Get the record data, 
 //wherease a simple iteration would have been enough (no Disk Access
but only a GetCursor from the Dataserver)
//Here we are
For(long i(n) ; i < n+d; i++)

With the 2- feature access, the grid has to map for each line displayed
its FeatureID (Line position/Feature ID). Indeed, there is no reason for
that Feature ID = Grid Line Position.
Because of this mapping, hhe grid becomes less generic.

So would you be interrested in a public method on OGRLayer to get
aFeature via its Query's position ?

if (OLCRandomRead) is available
OGRFeature* GetFeatureFromPosition(long aRecordPosition); 

Hoping my english is not that bad, 
Thanks in advance,


MSN Messenger, nouvelle version ! Personnalisez vos messages, jouez en
ligne et communiquez en temps réel par vidéo! http://ifrance.com/_reloc/m

More information about the Gdal-dev mailing list