[postgis-devel] Multi-D Indexing and Serialized Form

[Paragon Corporation]

Is T as true timestamp in MM/SQL specs.  Wouldn't we be breaking our
compliance.  Not that we aren't in other ways -- but.
 
I suppose its not possible to have people decide what kind of index to build
-- like some parameter to GIST or whatever.  That way people who don't want
to pay the 10% disk penalty won't have to.
 
Thanks,
Regina

  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of David
William Bitner
Sent: Monday, July 13, 2009 5:19 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Multi-D Indexing and Serialized Form


If we're opening up the whole ball of wax and looking at the potential
things that could go into a liblwgeom2 serialized form, would there be any
possibilities to have a T dimension that was an actual timestamp (as opposed
to the typical use of an offset from a time)???


On Mon, Jul 13, 2009 at 4:04 PM, Paul Ramsey <pramsey at opengeo.org> wrote:


For my "geography" work, I am trying to ensure that what I do either
uses existing liblwgeom hooks, or creates new things that liblwgeom2
could use. I'll be doing indexing as a 3-space index, and that works
OK for geography, things are static:

bbox dims = 3
coordinate dims = 2

However, for geometry, we were thinking about adding multidimensional
indexing. Right now we have a situation like this for geometry:

bbox dims = 2
coordinate dims = 2/3/4

No problem, because we only calculate a 2d box, no matter what our
dimensionality. But when we add the possibility of multi-dimensional
indexes, we get in a bind. How many dimensions of bbox should we
calculate? We need enough to support the index, but we don't know what
the dimensionality of the index using the bbox will be. That leaves us
forced to calculate the full multi-dimensional bbox even if we only
want a 2-d index. We also could end up with some interesting problems,
for example, returning results from a 4d index given a 2d query bbox.

The straightest line solution, IMO, is to just create a bbox with
enough dimensionality to handle the coordinates. So we'll end up with

coordinate dims = 2 => bbox dims = 2
coordinate dims = 3 => bbox dims = 3
coordinate dims = 4 => bbox dims = 4

For 2-vertex 3d points that you only want a 2d index on (the worst
case, since we don't put boxes on points), that implies a storage
overhead of about 10%.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





-- 
************************************
David William Bitner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090713/4106cdf2/attachment.html>