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

[Paul Ramsey]

Agree with Chris. Saying 'm isn't a dimension' is a semantic issue and
not worth reorganizing the code base around, since we can do practical
work with things as they stand now, even if m (or 't' or whatever is
jammed in there) isn't strictly speaking in the same dimensional space
as XYZ.

Note that, practically, Z has the same problems dimensionally as M,
since it's not uncommon for Z to be in different units from XY (see,
SRID=4326;POINTZ() ) Perfection is not in our grasp, let's muddle
through.

Also 'non-M dimensions' imply a round of alterations / upgrades to WKT
input/output and WKB input/output and so on. We have a robust
understanding of what to do with XYZM at this point.

P.

On Wed, Jul 6, 2011 at 10:11 AM, Chris Hodgson <chodgson at refractions.net> 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.
>
> 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.
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>