Evolution of OGRLayer ?

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
screen.

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

//Move to first Record
OGRLayer->ResetReading();
//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)
 OGRFeature::DestroyFeature(OGRLayer->GetNextFeature());
}
//Here we are
For(long i(n) ; i < n+d; i++)
{
 DoSomethingWith(OGRLayer->GetNextFeature());
}

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,

Jean.

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