[Gdal-dev] importFromWkt() problem

[Mateusz Loskot]

Petteri Packalen wrote:
>>> 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 ];

Petteri,

It looks good.

As I understand, geo_trans is a buffer to store *single* buffer at time.
Also, I assume you're copying stuff tot the geo_trans buffer
(e.g std::memcpy() or other correct way).
But are you sure you're *reseting* the buffer before copying new stuff?
For example, if onece you have WKT long for 100 characters and
next time you will copy there WKT shorter, e.g. 80 chars long,
then you will have a garbage at the end, so you need to manually
assure there is always null character at the end \0 char.
I'd use std::memset() function from <cstring> library here:

std::memset(geo_trans, 0, WKT_BUF);

called before copying every WKT string into the buffer.

>>> 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).


OK,I don't see anything incorrect here.


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


I'd suspect that may be a problem, please check if you *clear*  the
buffer properly.


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

Understood.

> 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

SetGeometryDirectly transfers ownership of the geometry to instance of
the OGRFeature type on which you call it.
So, if you assign geometry to feature using SetGeometryDirectly,
you don't need to destroy geometry yourself,
destructor of OGRFeature (after you call OGRFeature::DestroyFeature())
will do it for you.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net