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

[Paul Ramsey]

On the timestamp, er... it doesn't fill me with joy. And it's another
"non dimensional dimension" like "m" that requires special flagging
(XYZMT? XYT? XYZT?) Simply using M as an offset T makes my life so
*much* easier and your only infinitesimally harder.

On the index, yes, people can decide at runtime what kind of index to
build, what they can't decide is how many dimensions to store on the
disk-serialized bbox.

P.

On Mon, Jul 13, 2009 at 2:30 PM, Paragon Corporation<lr at pcorp.us> wrote:
> 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
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>