Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3045 closed defect (fixed)

&&& operator confuses dimensions

Reported by: strk Owned by: strk
Priority: medium Milestone: PostGIS 2.1.6
Component: postgis Version: 2.0.x
Keywords: Cc: pramsey

Description (last modified by 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;

Change History (11)

comment:1 by strk, 9 years ago

Cc: pramsey added

comment:2 by strk, 9 years ago

Description: modified (diff)

comment:3 by strk, 9 years ago

Description: modified (diff)

comment:4 by strk, 9 years ago

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 ?

comment:5 by strk, 9 years ago

Owner: changed from pramsey to strk
Status: newassigned

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

comment:6 by nicklas, 9 years ago

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

comment:7 by strk, 9 years ago

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.

comment:8 by strk, 9 years ago

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

comment:9 by robe, 9 years ago

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

comment:10 by strk, 9 years ago

Milestone: PostGIS 2.0.7PostGIS 2.1.6
Resolution: fixed
Status: assignedclosed

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

comment:11 by strk, 9 years ago

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

Note: See TracTickets for help on using tickets.