[geos-devel] GEOS and Writing SRID values

[Frank Warmerdam]

Charlie Savage wrote:
> The second issue is more important.  This would change the wkb output 
> format to match PostGis - will this cause problems?  GEOS already uses 
> an extended WKB format by including dimension information, so its hard 
> to argue its any less OGC compliant.  Also, this would only be different 
> for geometries that actually do have SRID values.

Charlie,

I do not believe the WKB writer should write SRIDs into the WKB stream
by default.  It will certainly break GDAL's use of GEOS!  And it just
isn't part of the specification.

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

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'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 );

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.

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