# What does n-D stand for in the following operator definitions?

PostGIS shows a listing of operators that make reference to `n-D`

``````&&& — Returns TRUE if A's n-D bounding box intersects B's n-D bounding box.
&&&(gidx,geometry) — Returns TRUE if a n-D float precision bounding box (GIDX) intersects a geometry's (cached) n-D bounding box.
&&&(gidx,gidx) — Returns TRUE if two n-D float precision bounding boxes (GIDX) intersect each other.
<<->> — Returns the n-D distance between the centroids of A and B bounding boxes.
<<#>> — Returns the n-D distance between A and B bounding boxes.
``````

What does "n-D" mean?

# `n-D` is a shorthand for "n-Dimensional".

As if to say in this context, not explicitly a 2-d bounding operation but may include bounding boxes from other 3 dimensional geometries like polyhedrons.

You can compare that to the like-named operators that work on only 2d bounding boxes,

``````&& — Returns TRUE if A's 2D bounding box intersects B's 2D bounding box.
&&(geometry,box2df) — Returns TRUE if a geometry's (cached) 2D bounding box intersects a 2D float precision bounding box (BOX2DF).
&&(box2df,geometry) — Returns TRUE if a 2D float precision bounding box (BOX2DF) intersects a geometry's (cached) 2D bounding box.
&&(box2df,box2df) — Returns TRUE if two 2D float precision bounding boxes (BOX2DF) intersect each other.
<-> — Returns the 2D distance between A and B.
<#> — Returns the 2D distance between A and B bounding boxes.
``````

Generally, add more stuff (characters) for the operator that supports more stuff. That seems to be the convention.

• `&&``&&&`
• `<->``<<->>`
• `<#>``<<#>>`

n-D means "more than two but less than five". What you're seeing is some leakage from the programming side to the user side. When "more than two" index support was built, I built it generically, so it could handle arbitrary extra dimensions. As a result, all the internal functions end up having "nd" in their signatures, and that thinking leaked out into the documentation.

However, since the PostGIS data model only supports objects of up to 4 dimensions the "n-D" code never gets used with more than 4 dimensions. Also, some of the implementation code around the edges uses "no more than 4" as a simplifying assumption, so truly using the code as "n-D" would take some clean up and verification.

Because it's possible to have both indexes on the same geometry (you can build both a 2d and an nd index on a geometry column) we also needed distinct operators so the user could choose which kind of filtering to apply: hence, && as 2-d overlap and &&& as n-d overlap, as well as the other "more symbols please" operators outlined in the other answer.

One thing potentially under appreciated about higher dimensionality is the freedom you have to encode what you want in those higher dimensions. 'Z' has kind of an agreed meaning, but the 'M' dimension is usable for anything at all. So X/Y/Time data can be both stored (in a POINT M () or a LINESTRING M () for instance) and indexed using the n-d index. High-speed multi-dimensional searching in a unified space/time domain. Sounds good, right?