[gdal-dev] Adding multipolygons to an existing geometry collection

[Ari Jolma]

Even Rouault wrote:
>> What's the "Java dirty trick" that the code talks about?
>>     
>
> Ari,
>
> Do you really want to hear the explanation ;-) ? OK, here it is.
>
> This is related to subtelities of SWIG and Java garbage collection.
>
> Imagine that DISOWN is still used for the input parameter of 
> ForceToMultiPolygon
>
> Consider the following code :
>
> geom1 = ogr.CreateGeometryFromWKT(xxxx);
> geom2 = ogr.ForceToMultiPolygon(geom1);
>   

IMHO this shouldn't be allowed in languages that use OGR through swig in 
the first place since forceTo.. really works on its argument geometry 
although it syntactically returns a new pointer. That's why I thought it 
would have been better to be a object method, i.e.,:

geom1 = ogr.CreateGeometryFromWKT(xxxx);
geom1.ForceToMultiPolygon();

There are similar problems elsewhere in the swig bindings, which are 
also fixed with similar tricks in Perl bindings (I'm not sure about the 
other languages), but they are usually due to things like feature 
depending on the existence of its layer.

Regards,

Ari

> geom2 = null;
> /* big memory allocation */
> foo(geom1)
>
> If nothing special is done, during the big memory allocation, the garbage 
> collector will collect the geom2 object. During its finalization, this will 
> call the destructor of the underlying C++ object (let's call it geom2_cpp). 
> But since the call of ForceToMultiPolygon(), geom1_cpp is owned by geom2_cpp, 
> thus deleting geom2_cpp will cause geom1_cpp to become invalid. And 
> foo(geom1) would operate on garbage.
>
> This can be fixed (I have already done this for Feature.SetGeometryDirectly()) 
> by adding special code in ogr_java.i so that geom1 (the Java object) holds a 
> Java reference to geom2 (the Java object). So the 2 objects are bound 
> together and garbage collection of one cannot occur if the other one is still 
> in scope...
>
> Calling Clone() and separating the lifetime of the 2 objects avoids the above 
> complication.
>
> Best regards,
>
> Even
>
>   
>> Ari
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>     
>
>
>