[rjb32]

Implement point.distance and point.withinBBox.

[rjb32]

Note

AI-generated summary.

Summary

Goal. Implement point.distance(a, b) and point.withinBBox(p, lowerLeft, upperRight), so the ticket's query runs: MATCH (a:City {name: 'London'}), (b:City) WHERE point.distance(a.location, b.location) < 50000 RETURN b.name.

Approach. Both functions are declared in a new point function namespace. Each is one db op (db.point_distance, db.point_within_bbox), lowered as db.replace is: each argument becomes a row-aligned nullable point chunk or a column of tagged cells, read per row by a point reader. The result is always nullable, because points in different CRSs have no distance and no box. Distance is Euclidean for cartesian points and haversine metres for wgs-84, on the IUGG mean radius of 6,371,008.8 m rather than Neo4j's 6,378,140 m, and 3D wgs-84 follows Neo4j's formula. A box whose lower left lies east of its upper right crosses the 180th meridian. docs/points.md describes the whole type.

Where to look.

• storage/metadata/Point.cpp:547 Point::distance
• storage/metadata/Point.cpp:570 Point::withinBBox
• query/ir/lowering/DBLowering.cpp:2928 lowerPointFunction: one lowering for both ops
• query/ir/exec/NLExecutor.cpp:10413 selectPointArgumentRead: the argument shapes it reads

point.distance(paris, london)                   = 343530.34 m   checked against an independent Python haversine
point.distance(cartesian, wgs-84)               = null
point.withinBBox(179.5, ll 179, ur -179)        = true    crosses the 180th meridian

Evidence

• Before: point.distance and point.withinBBox are not declared.
  After:

  test_query_ir_point_spatial_functions   [  PASSED  ] 17 tests.
  answersTheTicketQuery: London 0.0, Croydon 14708.388652
  

Merge Danger

Door: two-way

Blast Radius: query

Distances are 0.11% shorter than Neo4j's, because of the radius.