[postgis-users] Postgis Lean

Ralph Mason ralph.mason at telogis.com
Wed Dec 17 18:38:41 PST 2003

Hi Dave,

Thanks for the reply.

> Apart from that, you're right, you could save most of those bytes. 
> Unfortunately, it would actually be a lot of work to change all the 
> postgis functions to understand what you're doing.
And perhaps not as *advantageous *as I thought,  I am really trying to 
work with line strings  which are as you give below.  I do have some 
multi segment line strings but I can decompose them into single 
segments.  For other shapes I can just use a standard geometry.

> As an easier alternative, you could create a new type based on WKB.
> Internal storage would be like:
> <xmin (double)>
> <xmax (double)>
> <ymin (double)>
> <ymax (double)>
> <SRID> (optional)
> <WKB>
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?

These lines are directional (I need to know the left and right side of 
them )so it would probably need to be more x1,y1 x2,y1 and the boxing 
functions would find the min max. I guess I could swap the data so all 
the data is imported with the start being the top left and the bottom 
being the bottom right.

> This is enough information to allow it to be indexed.  If you look at 
> the postgis GiST indexing code, you'll see its fairly abstract - all 
> you really need to do is convert your geometry into a BOX.  That 
> information is at the top of my example geometry above.
> Since postgis already has PostGIS->WKB and WKB->PostGIS, you can 
> easily create a conversion function from postgis-> new geometry type 
> and back.   You'll be able to do things like:
> SELECT length(my_new_geometry_column) FROM table;
And I can 'port' postgis functions that I really need speed on 
understand the new format.  That should make it almost invisible.

I guess it would also be pretty simple to support  WKT that 'can' 
represent a two point line.  This would make it almost transparent, and 
shp2psql would work with it.

> and postgresql will automatically convert your new geometry to a 
> postgis geometry and returns its length.  This is slow, but you get 
> all the postgis functionality for free.

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.


More information about the postgis-users mailing list