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)???<br>

<br><div class="gmail_quote">On Mon, Jul 13, 2009 at 4:04 PM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

For my "geography" work, I am trying to ensure that what I do either<br>
uses existing liblwgeom hooks, or creates new things that liblwgeom2<br>
could use. I'll be doing indexing as a 3-space index, and that works<br>
OK for geography, things are static:<br>
<br>
bbox dims = 3<br>
coordinate dims = 2<br>
<br>
However, for geometry, we were thinking about adding multidimensional<br>
indexing. Right now we have a situation like this for geometry:<br>
<br>
bbox dims = 2<br>
coordinate dims = 2/3/4<br>
<br>
No problem, because we only calculate a 2d box, no matter what our<br>
dimensionality. But when we add the possibility of multi-dimensional<br>
indexes, we get in a bind. How many dimensions of bbox should we<br>
calculate? We need enough to support the index, but we don't know what<br>
the dimensionality of the index using the bbox will be. That leaves us<br>
forced to calculate the full multi-dimensional bbox even if we only<br>
want a 2-d index. We also could end up with some interesting problems,<br>
for example, returning results from a 4d index given a 2d query bbox.<br>
<br>
The straightest line solution, IMO, is to just create a bbox with<br>
enough dimensionality to handle the coordinates. So we'll end up with<br>
<br>
coordinate dims = 2 => bbox dims = 2<br>
coordinate dims = 3 => bbox dims = 3<br>
coordinate dims = 4 => bbox dims = 4<br>
<br>
For 2-vertex 3d points that you only want a 2d index on (the worst<br>
case, since we don't put boxes on points), that implies a storage<br>
overhead of about 10%.<br>
<br>
P.<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>************************************<br>David William Bitner<br>