[geos-devel] GEOS and Writing SRID values

[Charlie Savage]

> 
>> If this is a big issue, then a writeSRID flag could be added to the 
>> WKBWriter.  But then you'd have to expose the flag via the CAPI - 
>> maybe something like this:
>>
>> extern char GEOS_DLL GEOS_getWriteSRID();
>> extern char GEOS_DLL GEOS_setWriteSRID(char value);
> 
> Why char?  Why not an integer boolean?

Just following the standard already set in the C API (see isValid, 
isSimple, isRing, etc.).
> 
> 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.

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

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

Is the geos 3.0 capi still backwards compatible with the 2.x apis?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20070913/9341c2c8/smime.bin