[Gdal-dev] GetGeometryRef in scripts

[Kevin Ruland]

Frank,

You are right, performance is important particularly for scripts.  I for
one am quite guilty of whipping up bad one-off code to spin through
thousands of datasets.  It would be good if these could be made efficient.

I'd like to discuss the potential problems to making life easy for
scripters.  The problem with Geometry is we really have three different
kinds of geometry - those owned by nobody, those owned by Features,
those owned by Geometries. (please correct me)

Feature::GetGeometryRef()
Geometry::GetGeometryRef()

And it's owner is either a Feature or Geometry depend on how you got a
hold of it.  You get Geometries which are not owned by anybody by doing:

Geometry::Clone()

There is probably a pure constructor for Geometry as well.

Let's bundle these handles together like this:

struct GeometryGuy {
  OGRFeatureH parentFeature;
  OGRGeometryH parentGeometry;
  OGRGeometryH me;
}

Now there are a bunch of functions which fall into two categories:

Those which make copies:

Feature::SetGeometry()
Geometry::AddGeometry()

Those which assume ownership:

Feature::SetGeometryDirectly()
Geometry::AddGeometryDirectly()

And all the Geometry member functions which operate correctly
reguardless of ownership.

It seems, if the script bindings operate on the GeometryGuy (instead of
OGRGeometryH), we can drop the distinction between the SetGeometry &
SetGeometryDirectly and have the wrapper function determine which method
to envoke.  Of course, the method is determined by which of the parent*
pointers is populated.

I believe a strategy like this would hide the troubles of passing the
wrong kind of Geometry into the wrong method, and at the same time
provide for maximum efficiency.  Yes there would be code overhead to
provide the safety -- extra tests, more complex implementation of
constructors (Clone etc).

Also instead of using OGRFeatureH, we would have to add some reference
counting for the handle in order to allow for chained calls.

Kevin