[postgis-users] Postgis Lean

[David Blasby]

> I am very new to this, but am I right in my understanding I would only 
> need to supply a new 'compress' and 'decompress' function for this type 
> and can use all the other postgis functions when supporting a gist index?

yes.  In general, "decompess()" doesnt do anything. "Compress()" 
converts a geometry to just a bounding box.

Its a bit more difficult than that to get full support - you also have 
to set up a bunch of support functions (like "left", "left overlap", 
etc...).  But you could just modify the postgis versions.

If you're really interested in this, you should take a quick look at the 
postgis gist code.  There's more information in the postgresql help, and 
the folks (oleg and teodor) who maintain GiST are at:
http://www.sai.msu.su/~megera/postgres/gist/

They have an example that works on the native postresql polygon type.

Basically, you'll need to:

1. create your new geometry type
2. create input/output functions for it (steal the WKB in/out code from 
postgis)
3. create the GiST support functions that operate on your geometry type 
(steal from postgis, but you might have to write some from scratch)
4. create a function that takes your geometry and converts it to a BOX 
(the old style postgresql type)
5. add the GiST support function on BOX (already existing in postgis)
6. create functions that convert to and from PostGIS geometries (steal 
the code from postgis).  For 7.4 you'll have to add an explicit CAST.
7. you might have to write a few more very simple conversion functions 
(ie. BOX3D -> your new geometry type)

At this stage, you'll have:
1. your new type
2. some simple functions that directly work on your type
3. indexable
4. you can run the normal PostGIS functions on it (but this will be a 
bit slow)

This is about 2 weeks work if you know what you're doing.

I really suggest you use WKB as its relatively small and generic - plus 
most of the conversion functions are already written.

> And I can 'port' postgis functions that I really need speed on 
> understand the new format.  That should make it almost invisible.

Yes - just write the functions so they work on your native format.  If 
you want to be fancy, you can also write functions that convert directly 
to GEOS if you're expecting to use those functions as well.


> Does anyone know about MapServer's connection to postgis, would it work 
> with a datatype like this, or would the changes be reasonably easy to 
> make? It seems like something like this would be useful for most street 
> mapping applications. I would like to not break support for it.

I wrote the mapserver connector.  You'll need to add support for a few 
simple functions:

1. asBinary(<geom>)-- return WKB (really easy if your base type is WKB)
2. force2d(<geom>) -- if geom is 3d, convert it to a 2d representation
                          (this isnt difficult)

You'll either have to ensure that there is an entry in the 
GEOMETRY_COLUMNS table or make them specify "the_geom from mytable USING 
SRID=-1"

There might need to be a little bit more needed for querying, but I 
think the above is all you need for displaying.

dave