&&& operator confuses dimensions

[strk]

The &&& operator does not distinguish between Z and M values, see this:

WITH v(i,g) AS ( VALUES
 (1,'POINT(0 0)'::geometry),
 (2,'POINTZ(0 0 1)'), ----- true
 (3,'POINTZ(0 0 0)'), ----- false (wrong?)
 (4,'POINTM(0 0 1)'), ----- true
 (5,'POINTZM(0 0 0 1)'), -- false (wrong!)
 (6,'POINTZM(0 0 1 0)') --- true (wrong!)
 )
SELECT i FROM v WHERE g &&& 'POINTM(0 0 1)'::geometry;

[strk]

So this seems to be an harder problem than it looked. That is, if we really want to assume "missing" dimension are "infinite", as suggested in ​http://lists.osgeo.org/pipermail/postgis-devel/2015-February/024759.html Then we need to "pad" the Z for a ZM point with an explicit infinite range (-inf,+inf).

It sounds like something that would need to be done in gserialized_datum_get_gidx_p which would then construct 4D boxes for 3DM geometries (with a padding). That's unless we have ZM semantic in GIDX which I think we don't ?

[strk]

confirmed, coordinates are anonymous in GIDX, so all we can do is pad, producing 4D from 3DM.

[nicklas]

Just for reference: This discussion is somewhat related to an old discussion about how distance functions shall handle missing dimensions. http://trac.osgeo.org/postgis/ticket/2034

[strk]

I've a patch ready, implementing the "padding" method.

The consequence is 32bit instead of 24bit for storing boxes of 3DM geometries in tables (I guess we could avoid this) and for 16bit instead of 12bit for storing boxes of 3DM in ND indexes (this one cannot be avoided).

I'll need to perform more tests before committing it to trunk as I think all the worms out of the can are hiding somewhere.

[strk]

So as of r13250 I fixed the confusion by padding the Z values in the GIDX for 3dm geometries. The storage did not change as we have a flag there expressing semantic. I think the index size grew for 3dm geometries but I could not find a way to test it as pg_total_relation_size against an index on 3dm geometries gives me always the same value, with or without padding.

We have to decide whether to backport this in 2.1 and 2.0

[robe]

I'm okay with backporting to 2.1. Not sure its worth the bother possibly disrupting 2.0.

[strk]

r13260 in 2.1 branch (2.1.6) — ok to not backport to 2.0

[strk]

See #3056 for a related dimensional confusion (overlapping objects should have be distant 0)