referencing GEOMETRY object values in libpq?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

referencing GEOMETRY object values in libpq?

sandr002
Hi,

I'm working on a project that requires using C, and I'm still pretty new
to PostGIS.  I'm trying to retrieve the values  of the points on a
polygon from a PGresult, using the libpq library.  Is there a better way
to do this than parsing the 'GeometryAsText()' string?  I guess what I
would like to know is if there is a way to reference
POLYGON3D->pts->POINT3D->x/y/z to store it in a local variable of my own.  

Thanks guys,
-Nick


Reply | Threaded
Open this post in threaded view
|

Re: referencing GEOMETRY object values in libpq?

Paul Ramsey-2
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.

Paul

[hidden email] wrote:

> I'm working on a project that requires using C, and I'm still pretty new
> to PostGIS.  I'm trying to retrieve the values  of the points on a
> polygon from a PGresult, using the libpq library.  Is there a better way
> to do this than parsing the 'GeometryAsText()' string?  I guess what I
> would like to know is if there is a way to reference
> POLYGON3D->pts->POINT3D->x/y/z to store it in a local variable of my own.  
>
> Thanks guys,
> -Nick

--
       __
      /
      | Paul Ramsey
      | Refractions Research
      | Email: [hidden email]
      | Phone: (250) 885-0632
      \_

Reply | Threaded
Open this post in threaded view
|

Re: referencing GEOMETRY object values in libpq?

David Blasby-3
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