Charlie Savage wrote:
Why char? Why not an integer boolean?
Just following the standard already set in the C API (see isValid,
isSimple, isRing, etc.).
Charlie,
Ah, I hadn't noticed that. An odd choice in the first place IMHO.
I must say I hate the way the GEOS C API uses static state in the library
for stuff like byte order and output dimensions and I hate to perpetuate
this. This is a threading risk especially in situations where different
parts of an application are using GEOS can cannot easily cooperate with
locks. This is the sort of problem my clients are running into more and
more with libraries like GEOS, PROJ.4, etc.
I agree - but that's separate thing, no? The right solution is expose
the reader/writers to the capi so you can create one and then use it.
It is seperate from srid issue to be sure. I had not actually realized
about the statefulness of the towkb function before looking at your
suggestions.
I'd like to see an extension to the C API adding:
GEOSGeomToHEX_bufWithOpts( const GEOSGeometry *g, size_t *size,
int byteOrder, int includeSRID,
int outpuDimension );
Yes, that would be better than the current api. But really all the
writer methods (toWkt, toWkb, toHex) should work like that (with
different options for toWkt, just srid I think).
Agreed.
If we could start from scratch, you'd change those 3 methods and get rid
of these 4:
extern int GEOS_DLL GEOS_getWKBOutputDims();
extern int GEOS_DLL GEOS_setWKBOutputDims(int newDims);
extern int GEOS_DLL GEOS_getWKBByteOrder();
extern int GEOS_DLL GEOS_setWKBByteOrder(int byteOrder);
Which would make for a more compact, and bettter, api.
or perhaps, merge the options into a bitfield so we can easily
add new bitfield values in the future without changing the C
API which needs to be quite static.
Are there going to be other options besides those 3 (byte order, include
srid, output dimension)?
So your conclusion is add in 3 new methods (toWktWithOpts,
toWkbWithOpts, toHexWithOpts) and deprecate the original 3 methods and
the 4 above)?
This would be my suggestion. I'd add that a primary goal of the C API
is stability so even if we deprecate the old API we should keep it
around (perhaps undocumented) for a long long time.
Is the geos 3.0 capi still backwards compatible with the 2.x apis?
I'm not aware of any changes in the 3.0 api that break 2.0 applications.
At least not the ones I use. :-)
So, how do we decide how to proceed lacking a PSC and RFC process? Perhaps
Paul (or do we have a current chief developer?) can bless the proposal?
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
