[postgis-devel] LWGEOM -- inital version ready for testing
m.cave-ayland at webbased.co.uk
Tue May 4 05:45:09 PDT 2004
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
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
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
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
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
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
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
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....
Tamar Science Park
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
> 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/"
> 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
> cd regress
> Please let me know if you're tried it out and if you had any problems.
> 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.
More information about the postgis-devel