mirror of
https://git.osgeo.org/gitea/postgis/postgis
synced 2024-10-25 09:32:46 +00:00
74 lines
2.6 KiB
Plaintext
74 lines
2.6 KiB
Plaintext
|
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.
|
||
|
|