[postgis-devel] LWGEOM -- inital version ready for testing

[Mark Cave-Ayland]

Hi Dave,

Firstly a big well done for the work you've put into the LWGEOM - I had
hoped to have taken a more active role in developing the code but
unfortunately my time has been needed on other things :)

Anyway, haven't seen many responses from the other guys on the list so
thought I would add in my initial thoughts after looking at the CVS
snapshot (I've yet to spend some time loading it into a database so this
is mostly just thoughts on screen).


1. I like the reformat of the code. I know that some of the functions
are missing, but the 
   whole things seems easier to read, particularly in the use of
function names etc.


2. At this stage it think it would be useful to include some sort of
debugging function to 
   dump the LWGEOM format into a human-readable form, for example:

	> SELECT raw_lwgeom(geom) FROM geomtable;
	
	| size | has_srid | has_bbox | dimensionality | wkb_type |
wkt_geom | wkb_geom | 
	
+------+----------+----------+----------------+----------+----------+---
-------+


   I can see this being useful for helping users in situations where
they are not sure 
   exactly how they have configured the particular geometry in the
table. What do you
   think?


3. Should we prevent users from adding bounding boxes to point columns?
(i.e. is the 
   single/double precision conversion fast enough to make this a waste
of disk space?)


4. I think it would be useful to include BBOXes in LWGEOM by default. My
thinking here 
   would be that those users who would be knowlegable enough to be
concerned about the 
   space saving will more than likely to be knowledgable enough to
remove it where as new 
   users may get confused when certain queries that used to perform well
in PostGIS 
   perform poorly using LWGEOM.


5. As far as I can see, assuming a non-index scan, the LWGEOM operators
call the box2d_* 
   functions directly which is defined using float4s. It looks like this
is contrary to 
   the OGC spec since all coordinates (and therefore I would guess
operators) are defined 
   as doubles? :(.

   I guess that we would need to maintain a box2d type which uses
doubles as well as 
   floats and use this for all the LWGEOM operators/functions (the box2d
float4 would  
   still be used for the indexes). Here it would be compulsory to add
RECHECK to the 
   operator classes since when expanding the box2d(double) to
box2d(float) extra 
   geometries may be returned by an overlap calculation. The RECHECK
would ensure that 
   these would be stripped out before the result set was returned.


6. It looks like you can add bboxes and srids to a geometry but not
remove them? Also if I 
   follow the instructions in the README to add bounding boxes to a
column:

   DROP INDEX <lwgeom index name>;
   UPDATE <table> SET <lwgeom column> = AddBBOX(<lwgeom column>);
   CREATE INDEX <lwgeom index name> ON <table> USING GIST 
     (<lwgeom column> GIST_LWGEOM_OPS);
   VACUUM ANALYSE <table>;

   That would seem to work great. My question is now if I add more
geometries to the    
   table, would these new geometries not have a bounding box attached?
Would the only way   
   to add bounding boxes to these geometries be by running the update
query and reindexing 
   again?


Anyway glad to see that this stuff is becoming a reality, and I hope
that this will get some discussion started on the list about your work
so far :) If I get a chance I will try and setup a test database with
some sample data and see how it performs....


Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net 
> [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> Behalf Of David Blasby
> Sent: 29 April 2004 19:52
> To: postgis-devel at postgis.refractions.net
> Subject: [postgis-devel] LWGEOM -- inital version ready for testing
> 
> 
> There's an inital version of LWGEOM available for testing.  
> The indexes 
> it makes are about 40% smaller, and there's a very 
> significant reduction 
> of the actual geometry size.  It natively supports 2D, 3D, and 4D 
> geometries.
> 
> Its been tested on a Linux (Intel) machine and a Solaris (Sparc) 
> machine.  Norman says it compiles on Windows (cygwin), so it 
> should also 
> work there.
> 
> If you checkout a CVS copy of PostGIS, you'll see a "lwgeom/" 
> directory.
> 
> There's a README file here with lots of details on how to use it.
> 
> In summary, to test out the LWGEOM on your system:
> 
>       cd lwgeom
>       make
>       cd regress
>       ./run_regress
>       ./run_regress2
>       ./run_regress3
> 
> 
> Please let me know if you're tried it out and if you had any problems.
> 
> dave
> ps. I've attached the README file - it contains more detail of how to 
> use the LWGEOM type.
> 
> pps. Thanks to Ralph Mason who did lots of work doing a 
> lex/yacc WKT/WKB 
> parser and writers.
>