[postgis] OGR and PostGIS

[Dave Blasby]

Frank Warmerdam wrote:
> 
> Folks,


Frank, I'm really happy to see that you've dived into PostGIS and given
a bunch of really helpfull comments.


> <        geom
> < -------------------
> <  POINT(Infinity 0)
> ---
> >      geom
> > --------------
> >  POINT(inf 0)
> 382,384c382,384
> <         geom
> < --------------------
> <  POINT(-Infinity 0)
> ---
> >      geom
> > ---------------
> >  POINT(-inf 0)


These are fine.  It caused by how printf("%g", (double) 1e999 ) is
interpreted.  On our Solaris machine, it prints "Infinity"; on an i386
it prints "inf".
Our solaris machine correctly parses "Infinity", "infinity", "inf", and
"Inf" as valid instances of the IEEE 'infinity' value.  I expect that
this is the case on your i386 machine.  We're creating a linux i386
installation as I type, so I can test this there.


The next two problems are more interesting;


> 672c672
> <    884
> ---
> >    880
> 740c740
> < INSERT 18857599 1
> ---
> > INSERT 20649 1
> 793c793
> <     72080 |    72080
> ---
> >     72076 |    72076


These values are the size of the underlying geometry structure (using
the mem_size() function).  Its very strange that our solaris machine
would give a different number of bytes than your i386.  Most likely this
is being causes by (1) different size of base types (ie. sizeof(bool) on
i386 != sizeof(bool) on sparc) or (2) memory alignment differences.  


> INSERT INTO geom_test ( gid, geom, name )
>   VALUES ( 1, 'POLYGON((0 0 0,0 5 0,5 5 0,5 0 0,0 0 0))', '3D Square');
> 
> Resulted in this from a select *:
> 
>    1 | POLYGON((0 0 0,0 5.31146529464635e-315 0,5.31146529464635e-315 5.31146529464635e-315 0,5.31146529464635e-315 0 0,0 0 0)) | 3D Square


This is probably caused by the same problem as above.  It works
correctly on our solaris install.  

I'll take a good look at the structures and see why you are consistently
4 bytes shorter than I am.

> Finally, I have integrated the ability into OGR to read PostGIS tables.
> They are identied as any table with a field that has the type "Geometry".
> This is now working fine for read access, and I will start work on creating
> new geometric tables from OGR.

Nice!
 
> What is the best way for my OGR library to determine if a PostgeSQL
> instance has the PostGIS extensions loaded?  Should I access the types
> table, and look for a Geometry type?

There are two types you will be interested in;

select OID from pg_type where typname = 'geometry';
select OID from pg_type where typname = 'wkb';


if you do a 'select * from geom_table', you will get your geometry back
as a block of text (wkt format).

if you do a 'select gid,name, wkb_xdr(geom) from geom_table', you'll get
your geometry back as type wkb (in WKB).  (only in release 0.2 or above,
and you have to use binary cursors)

The wkb type is just like the internal type 'text'.  The first 4 bytes
represent the size of the structure, then the actual wkb stream.

Paul has installed PostGIS on a i386 linux box, so I should have no
problem tracking down the problem.  When I'm finished I'll send you out
a pre-release 0.2 (with the wkb stuff).  Included is a simple program
that uses binary cursors to read binary data out of the database.

dave

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/