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

[Chris Hodgson]

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.

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.

Chris

Mark Cave-Ayland wrote:
> On 06/07/11 17:38, Paul Ramsey wrote:
>
>> Yeah, by removing the fourth dimension you're foreclosing on 4d
>> indexing to some extent, since gboxes are used to pass around full
>> extents of 4d objects.
>
> But that's the misunderstanding here - M isn't a dimension. It's an 
> arbitrary numerical attribute attached to the geometry.
>
> Thinking about this some more, I was wondering if we could change 
> GSERIALIZED a bit. Currently we have this:
>
> typedef struct
> {
>     uint32 size; /* For PgSQL use, use VAR* macros to manipulate. */
>     uchar srid[3]; /* 21 bits of SRID (and 3 spare bits) */
>     uchar flags; /* HasZ, HasM, HasBBox, IsGeodetic */
>     uchar data[1]; /* See gserialized.txt */
> } GSERIALIZED;
>
> I'm thinking that instead of HasZ we should simply reserve 2 bits for 
> the number of dimensions, and then if a measure is present the HasM 
> bit can be set. This will give us up to 4 dimensions for people to 
> play with, and will also tidy up the HasZ/HasM handling. Do people 
> think 4 dimensions is currently enough? I'm happy to go ahead and do 
> the work to make the relevant changes.
>
>
> ATB,
>
> Mark.
>