[Gdal-dev] GetGeometryRef in scripts

[Ari Jolma]

I think the script writer understands the difference between "a geometry 
as a part of something" and "a separate geometry object". The first one 
goes away when the something goes away and second one is there as long 
as the variable is. In our example:

geometry = dataset.getlayer.getgeometry

The temporary layer is always part of something but the geometry becomes 
a separate object because of the assignment. At least in Perl you can 
detect this situation and instantiate a new geometry as a copy of the 
temporary reference which exists for a while. If you have

dataset.getlayer.getgeometry.do_something_with_a_geometry

Then the do_something_with_a_geometry will work on the temporary reference.

I have lots of functions like this in my Geo::Raster that can be used as 
"in-place" or "make-a-copy".

I hope this helps.

Ari


Frank Warmerdam kirjoitti:

>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,
>  
>


-- 
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma