[geos-devel] GEOS C API Suggestions

[Frank Warmerdam]

On 10/17/05, strk at refractions.net <strk at refractions.net> wrote:
> >  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.

Strk,

OK, this sounds fine.  In C I normally consider "unsigned char" a
more nature byte type but casting it should cause no problems.

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

My main motivation is that I was unable to build GEOS with VC6
on Win32 but I want to use it in my FWTools distribution.  It seems
to be not possible to have VC6 C++ code call a VC7 C++ DLL;
however, VC6 C calls into a VC7 DLL should be OK.

More generally though I am hoping the C API will be more stable and
hopefully make it easier to substitute use of JTS compiled with gcj
for comparison.

> >  4) I think the GEOS C entry points should be DLL exported.
>
> I'm not sure I understand this. Aren't them exported already ?

I saw no sign that the C API had the dllexport attribute on the functions
for win32.   I haven't tried things on win32 yet so perhaps I am missing
something.

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

I don't think this would cause a problem for a GEOSGetCoordinateX(),
and GEOSGetCoordinateY()  function.   However, as I mentioned

> 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 would be concerned that a GEOSGetGeometryN() that returned an
internal reference would limit options for internal implementation.

As I mentioned, I'm happy enough to leave fine grained geometry
creation and query out for now.  We can always add it later if we
are more certain of what we want then.

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

Excellent, I'll update before proceeding.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent