From: Sandro Santilli <strk@keybit.net>
Date: Thu, 13 Jan 2005 09:10:11 +0000 (+0000)
Subject: Added updated README file
X-Git-Tag: pgis_1_0_0RC1~11
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=4e06c961add37a4f052c12507ecf36ac4791160d;p=postgis

Added updated README file


git-svn-id: http://svn.osgeo.org/postgis/trunk@1293 b70326c6-7e19-0410-871a-916f4a2858ee
---

diff --git a/lwgeom/README b/lwgeom/README
new file mode 100644
index 000000000..6723f7435
--- /dev/null
+++ b/lwgeom/README
@@ -0,0 +1,73 @@
+Welcome to the Initial version of LWGEOM.
+
+More information is available on the PostGIS user's mailing list and 
+the PostGIS developer's mailing list.  
+
+Differences
+-----------
+
+The LWGEOM is very much like the original PostGIS GEOMETRY type.  The 
+main differences are:
+
+a) LWGEOMs are much smaller than the PostGIS GEOMETRY
+b) LWGEOMs natively support 2d, 3d, and 4d points
+c) LWGEOMs are indexed using single-precision bounding boxes.  This
+   make the indexes significantly smaller than PostGIS GEOMETRY
+   indexes.
+d) LWGEOMs are internally very similar to OGC WKB   
+e) The "normal" view of LWGEOMs is OGC WKB - PostGIS GEOMETRY is OGC WKT
+f) PostGIS geometries have a built-in BOX3D.  LWGEOMs have an *optional*
+   BOX2D (see below).
+
+
+Also included with the LWGEOMs is a type called 'box2d'.  This is
+very similar to PostGIS BOX3D type:
+
+a) BOX2Ds are 2D - BOX3D is 3D
+b) BOX2Ds are represented by single-precision floating point numbers,
+   while BOX3Ds are double-precision floating point numbers.
+c) BOX2Ds will sometimes be slightly larger than you might expect.
+   This is because the conversion from double-precision to 
+   single-precision is inexact.  When this happens, the BOX2D will
+   automatically expand itself.
+   
+
+Bounding Boxes
+--------------
+
+<this section for advanced users.  Ignore it if you don't understand
+ what its saying.>
+
+Bounding boxes are optional in LWGEOMs.  By not having one, you are
+saving a small amount of space per LWGEOM geometry (16 bytes).
+
+Bounding boxes are attached to any non-POINT geometry by default.
+
+You can disable this automatic addition setting AUTOCACHE_BBOX to 0
+in the top-builddir Makefile.config and read BBOXCACHE_BEHAVIOURS
+for function-by-function behaviour explanation.
+
+Manual control of bbox cache is available using DropBBOX() and AddBBOX().
+
+UPDATE <table> SET <geomcol> = DropBBOX(<geomcol>);
+UPDATE <table> SET <geomcol> = AddBBOX(<geomcol>);
+
+Note that if you don't cache a BBOX spatial operators will be much slower,
+as they'll need to compute all the boxes at every invokation.
+If you use GiST indexes you will still note a slow down as a RECHECK
+clause is specified for GiST operators. Also, GiST index updating
+will be slower w/out a BBOX cache.
+
+
+Space Saving
+------------
+
+LWGEOM indexes are approximately 40% smaller than PostGIS indexes.
+
+A LWGEOM 'POINT(0 0)' takes up 21 bytes, a POSTGIS 'POINT(0 0)' takes
+up 140 bytes.  This shows that LWGEOMs have a much smaller overhead.
+
+LWGEOMs will store 2D points as 2 double precision numbers (16 bytes) -
+PostGIS will store 2D points with 3 numbers (24 bytes).   This can be 
+another big savings.
+