[Gdal-dev] importFromWkt() problem

Petteri Packalen packalen at cs.joensuu.fi
Sat Sep 2 11:11:15 EDT 2006


Mateusz

>> Once again, I struggled with the weird problem until I understood to
>> look at the documentation... The problem was that, within
>> importFromWkt(), the pointer was updated to pointer after the consumed
>> text. However, I don't still understand why the first *corrected*
>> solution does not work properly. I want to reset the geometry of an
>> existing feature based on WKT representation. Below are two examples in
>> which only the latter one works properly. An example 1 crashes due to
>> illegal memory access. geo_trans is a buffer which stores WKT.
>>
>> EXAMPLE 1
>> =========
>> OGRPolygon * poPoly = new OGRPolygon();
>> poPoly->importFromWkt( &geo_trans );
>
> Please show your geo_trans declaration and initialization.

WKT_BUF 1000000
char * geo_trans = new char[ WKT_BUF ];

>> In addition, in an example 1 the
>> problem occurres only after very many (>million) calls to
>> importFromWkt(). Something is happening in the background (related to
>> reference counting etc.?) I don't understand.
>
> You mean, you're importing ~1 million geometries from WKT strings?

yes, actually coordinates are read from the shapefile, parsed to WKT, WKT 
coordinates are processed (local affine transformation) and converted back 
to WKT representation. This approch may sound a bit weird but the reason 
for this is that I have previously implemented routines for this WKT 
processing. Millions of shapes is just an extreme case for testing 
purposes (lidar data).

> Are you sure you're doing fresh WKT initialization for every geometry?

geo_trans is allocated only once in the beginning of the function and the 
same chunk is used all the time. I'm sure WKTs are in proper format.

> Please, show us more complete piece of code, with declarations and
> definitions of all variables that play in the example 1.

The code is too length and fragmentd to be pasted here as a whole. The 
latter approch creates correct output. However, now I noticed that there 
may have some memory de-allocation problem with it which lead to another 
question. Because I use SetGeometryDirectly( new_geom ), I don't release 
new_geom explicitly. I have understood OGRFeature::DestroyFeature( poDstFeature ) 
de-allocates it and all other resources it uses. Have I understood it 
correctly?

Best regards,
Petteri




More information about the Gdal-dev mailing list