[postgis-devel] RFC: Remove mmin and mmax from GBOX

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Thu Jul 7 02:17:04 PDT 2011


On 06/07/11 18:11, Chris Hodgson wrote:

> Could M not be time? or temperature? Those seem like dimensions to me,
> and it would be great to be able to include them in the extents of the
> bbox.
>
> What is special about x, y, and z that makes them "dimensions" and not
> just "numerical attributes"? The key is that there is one of each of
> them, for each point in the geometry, not just for each geometry. And
> the same is true of "m" - that's the whole point of "m" - to take what
> would normally be an "attribute" in the table and promote it to
> "dimension" status.

Well I'd say a dimension is something that identifies a unique region in 
multi-dimensional solution space, whereas an attribute is a reading of 
some description, e.g temperature, average number of mosquitos etc.

In fact, there are only four fundamental dimensions that have been 
defined: http://www.rwc.uc.edu/koehler/biophys/1a.html, i.e. we can 
conclude from this that a dimension is something that is a simple and 
not a derived unit. Indexing derived units in this way does not make 
sense, which is why I suppose they came up with M in the first place to 
indicate that it is an arbitrary attribute value.

> I think it would be a shame to remove support for 4-d indexing. I'm also
> ok with a max of 4 dimensions though.

You'd have to be doing some fairly crazy stuff to go above 4D ;) But I'm 
not proposing to remove 4D indexing, merely clarify the usage throughout 
the codebase.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs



More information about the postgis-devel mailing list