Geospatial Functions

Consumer View

Nexyron's current geospatial MVP is intentionally small and composable.

It does not introduce a second spatial storage engine or a new query-language subsystem. Instead, it gives Cypher a small point workflow plus WGS84-oriented helpers that work directly against normal numeric properties or temporal-object payloads:

• point
• distance
• geo_distance_m
• geo_within_bbox
• geo_within_radius

That design is deliberate. It lets geospatial filtering compose with the existing LPG, temporal, document-style, and analytical query surface without changing the architecture.

Functions

• geo_distance_m
• point
• distance
• geo_within_bbox
• geo_within_radius

Conceptual Explanation

The implemented geo surface is value-level rather than storage-level.

That means the normal modeling pattern is:

• keep latitude and longitude as regular numeric properties or object payload fields
• build native point values with point({...}) when you want a point object in the query pipeline
• use distance(point1, point2) for point-native calculations
• use timeseries declarations when those coordinates are part of visible temporal rows
• use temporal properties with structured coordinate payloads when you want node-attached location history that also participates in the global timeline
• use these scalar functions inside WHERE, projections, ordering, or rollup expressions

This is why the MVP stays fast to adopt:

• no new physical store
• no new parser clause family
• no query-path fork away from the existing expression evaluator