[Gdal-dev] GetGeometryRef in scripts

[Frank Warmerdam]

On 9/20/05, Kevin Ruland <kruland at ku.edu> wrote:
> 
> Frank,
> 
> Hopefully you know where I'm comming from right now....  memory control
> in script land.  I am unfortunately confused a little.  There are some
> methods which I'd like to have clarification on.
> 
> Feature::GetGeometryRef
> Feature::SetGeometry
> Feature::SetGeometryDirectly
> 
> Geometry::GetGeometryRef
> Geometry::AddGeometryDirectly
> Geometry::AddGeometry
> 
> I roughly understand the difference between SetGeometry and
> SetGeometryDirectly in the latter assumes ownership of the Geometry*
> argument and the former executes some clone process.

Kevin, 

Right. 

> Is this additional complexity required in scripts?  Can we get by with
> only SetGeometry?

That is potentially sacrificing significant performance, but if you
can't see a practical way to void it, then so be it.  

> What is Geometry::GetGeometryRef()?  How would it be used?

This method returns a subgeometry if the geometry is a container.
 
> Charlie indicates the Geometry object returned by
> Feature::GetGeometryRef is owned by the the Feature object.  Would it be
> ok to change this from it's current implementation:
> 
> return OGR_F_GetGeometryRef(self)
> 
> To a method which returns a clone whos memory is managed by the script,
> 
> OGRGeometryH g = OGR_F_GetGeometryRef(self)
> return OGR_G_Clone( g );

With the understanding that you are potentially adding quite
a bit of runtime cost, I suppose this would be acceptable, but
if practical I would prefer to keep the current approach.
 
> What about the two different versions of AddGeometry?

Likewise.  We could settle for just AddGeometry(), but there
is a non-trivial cost in some applications. 

Scripting languages like python are not particularly slow, 
and it is quite practical to process large volumns of data
with it.  But if you force lots of extra object copying you 
will make it difficult to write efficient python scripts for
some applications.  The same would apply to other languages
I would imagine. 

In the old python interface we carried around a flag indicating
whether a given object reference "owned" that object or
not.  At least this was done for stuff like geometries.  Is
there a reason that approach cannot be generalized?  

In the past, I have opted to keep the scripting interface pretty
close to the underlying C++ library for the most part; however, 
I am willing to defer to the you and others doing the majority
of the swig interface work if you prefer to emphasise safety
over performance.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent