[fdo-users] Re: SDE and slow multi-geometries

Oyvind Idland oyvind.idland at gmail.com
Fri Feb 18 05:05:24 EST 2011


The code is now fixed. As I got started, I also did some related code
cleanup:

- the macro function EXPAND() are now gone. Instead, I made a simple
templated
array class with an array subscript operator. This looks much cleaner now
and can be
debugged.


- the macro function ADD_POINT is also gone, replaced with an inline static
function.


- memory leak: ArcSDEConnection, line 885:

CHAR *qualified_table_name = new CHAR[SE_QUALIFIED_TABLE_NAME+1];

This one never gets deleted. I can't see any reason to use new, so I
replaced it
with an array instead:

CHAR qualified_table_name [SE_QUALIFIED_TABLE_NAME+1];



However, there are still things I'd like to do with the code: The geometry
buffering is
attached to the ArcSDEConnection class, and functions like
convert_sde_shape_to_fgf()
are poking around in these arrays (XY, Z, parts etc). What I would like to
do, is to
wrap all these arrays together with the indexing code into a new SDE
geometry
handling class. This won't add anything new, just make it more clean.


Where can I submit/send the changes ?


-- Oyvind



On Wed, Feb 16, 2011 at 4:53 PM, Oyvind Idland <oyvind.idland at gmail.com>wrote:

> Hello,
>
> I have been looking into an issue that was brought up here earlier. Turns
> out that the SDE API
> is slower than cold molassis when using SE_shape_get_num_points() on
> multipart geometries.
>
> I did some experimentation using the index tables returned from
> SE_shape_get_all_points()
> directly. The total processing speed on my dataset went from roughly 20
> secs down to less than
> 1 sec. There are several huge polygons with 200+ holes in them, and
> multilines.
>
> Why the native SDE API is so slow is a mystery, those indices should not
> require heavy
> calculation.
>
> The code is experimental so far, but when I finish writing the code, I can
> submit a patch
> if desired.
>
>
> -- Øyvind Idland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20110218/7ff64987/attachment.html


More information about the fdo-users mailing list