[geos-devel] GEOS and Writing SRID values

[Frank Warmerdam]

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, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org