[postgis-users] referencing GEOMETRY object values in libpq?

[David Blasby]

Paul Ramsey wrote:

> Yes, a better way would be to read the "Well Known Binary", much easier 
> to transform than the text form. You can get the binary forms by 
> declaring a binary cursor and pulling the data that way. There is some 
> example code for this in the examples/wkb_reader directory.

Its *way* easier to use the normal SQL queries.  You'll get back 
something like this:

test2=# select asbinary('POINT(123 456)'::geometry);
                   asbinary
--------------------------------------------
  01010000000000000000C05E400000000000807C40


You'll need to write a little function that takes a string like 'E4' and 
  returns a char with the value 228 in it (this is really easy).  You'll 
use this to convert the above string of 42 bytes to an array of chars 
(length 21) - thats your WKB.

To go from WKB back to postgis, you just write a function that take a 
number like 228 and converts it to a little 'E4' string (also really 
easy).  Use GeometryFromWKB() in the database.

The down side of this is three fold:

1. You're transferring twice the data - for the above example, 42 
characters (when you only really need to send 21).
2. There's a little bit of extra processing required (the conversion)
3. During the conversion process, you'll have the text version and 
binary version in memory at the same time.  For VERY VERY VERY large 
geometries, this might be a problem.


The advantage is that its really really simple to do.  If you actually 
use BINARY cursors, you'll have to deal with a much much more complex 
application because your ENTIRE query will be coming back in binary (not 
just the geometry).  This is a very big pain the butt!  Trust me, you 
dont want to go there.

So, unless you're really looking for performance with large geometries, 
you'll find the "naive" way much easier.  The nice part is you can write 
your application the "naive" way, then easily convert it to the hard way 
if you find its too slow.

WKB is defined in the OGC SF SQL spec, and is easy to machine parse.

dave