[Gdal-dev] Evolution of OGRLayer ?
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
//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