[geos-devel] Re: GEOS / SRID / WKB

Charlie Savage cfis at interserv.com
Thu Feb 2 19:07:01 EST 2006


Any chance get/set SRID could be "undeprecated?"

The reason is that it is much harder to use userdata. With get/set SRID 
all you have to do is set an integer. With user data you have deal with 
allocating/deallocating memory instead of setting a simple integer.  
That's ok, but it becomes harder if you want to clone geometries.  If 
you do that, then the clone methods (which end up eventually in the copy 
constructor of Geometry) set the new object's user data to null, which 
is reasonable since its a pointer.  But that makes it hard to make use 
of the user data to store SRID values - since you have to first clone 
the object then manually copy over the user data.

I realize that SRID values don't play a role in the traditional use 
cases for GEOS.  I gather I'm using it in a bit of a non-traditional way 
- as a client-side library for being able to read in data queried from 
PostGIS, then use Ruby to work with that data.  So the SRID values for 
my case are quite important.  I think that as the use of GEOS increases, 
this type of usage could become more common.

The only things I really need for this are:

1.  Keeping get/set SRID around
2.  Saving srid values read from the WKB format (see patch from yesterday).
3.  A change in the Geometry copy constructor - right now when you clone 
an object the new object gets its SRID value from the geometry factory 
and not from the cloned geometry.  That seems incorrect to me - I'd 
expect if you'd clone an object you'd get a true copy of it (I can 
provide a patch for this, its a one line change).
4.  It would be nice to be able to write out the SRID values in EWKT or 
EWKB, but that's not really critical.

So one vote to keep get/set SRID as official parts of the api....

Charlie


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


More information about the geos-devel mailing list