[geos-devel] GEOS C API Suggestions

[strk at refractions.net]

On Sat, Oct 15, 2005 at 11:13:29PM -0400, Frank Warmerdam wrote:
> Folks,
>
> Circa Sept26 I grabbed GEOS for an effort to integrate the C API
> with OGR (instead of the C++ API).  I have gotten back to that
> project today and gotten the updated OGR to build but there are
> still unexplained crashes.
>
> I haven't tracked that all down, but I do have a few suggestions I
> thought I should make while I have stuff fresh in my mind.
>
>  1) The Distance operation is missing and would be quite useful.

Added.

>  2) Why is the WKB buffer of type "const char *" instead of "unsigned
>      char *" or some similar "byte oriented" type?

I've changed the WKB I/O func signatures to use 'unsigned char', but
the implementation still uses signed values. This is because in STL
string<unsigned char> is not defined (and with GCC 3.3 it's not
automatically instanciated). If you think relying on automatic
cast would bring to any problem please let me know.

>  3) Within geos_c.h I think it should use produce it's own extern "C"  {}
>      around all the declarations if included by a C++ module.

mmm.. so you can use the "stabler" API from C++ you mean ?
Sounds fair... I'll try to figure out how to do this.

>  4) I think the GEOS C entry points should be DLL exported.

I'm not sure I understand this. Aren't them exported already ?

>  5) I think it would be nice to provide entry points to directly
>      create and destroy geometries however that is not really critical.
>      However, I found it odd that calls like GEOS_GetNumCoordinate()
>      and GEOSGetNumGeometries() were provided when no calls
>      to get coordinates or geometries were provided.

The whole point of the CAPI wrapper is to allow for deep changes in
the underlying implementation, maybe changing Coordinate types from
always 3d to possibly 2d... For this reason I'd avoid letting client
code messing with Coordinates. I think I can get rid or the
GEOS_GetNumCoordinate() part following this motivations...

As for GEOSGetNumGeometries I think I might add a GetGeometryN
function, but then we'll have to decide whether to make the
returned GEOSGeom a copy of a reference to internal component,
as the other open issue is memory management... What do you think ?

> I appologise if my comments are out of date.

There's been a segfault fix on Sep27, that actually brought to
a change in the GEOS WKB code (see ChangeLog).

Other additions since then (apart those reported above):

        - NEW: int GEOS_setWKBOutputDims(int newdims)

        - All exception handled invoking the ERROR function set
          with initGEOS (these include GEOSexception, std::exception
          and any other)

--strk;