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

[Mark Cave-Ayland]

On 06/07/11 18:18, Paul Ramsey wrote:

> 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.

There is definitely an issue here, but if we fix it now the pain will be 
considerably less than having people starting to code functions that 
don't make this distinction and suddenly we find places where we have 
one behaviour if the unit is time, and another if it is a reading of 
some description.

For example, take the following WKT snippet:

LINESTRING(5 5 1 3,3 5 2 2,3 3 3 1,0 3 1 1)

Looking at this, I would say that LINESTRING is a 4D linestring and 
would expect the 4th coordinate to appear in an index. This could be 
compared to the following:

LINESTRINGM(5 5 1 3,3 5 2 2,3 3 3 1,0 3 1 1)

Now this is to be interpreted as 3D linestring with a measure, and the 
measure should NOT be held within the multi-dimensional index because it 
is a derived unit. If you take my example to Chris earlier of the 4th 
coordinate being temperature measurements, then if you were to index 
this in the current code you would end up with a 4D index and because of 
the relatively narrow value ranges for temperature the index would be 
large not particularly efficient :(

By clarifying the different between 4D and M we achieve the following 
aims: i) we allow the user to determine whether or not the 4th value 
should be indexed and ii) we enable deterministic function behaviour.

My reason for raising this was when looking at the code, functions have 
two different types of behaviour - one that considers the 4th value to 
be a dimension (e.g. GBOX) and others that consider it to be a measure. 
By reworking the code to clarify this, we can resolve this ambiguity and 
therefore spot errors caused by this misunderstanding much more easily.


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