---
title: Geospatial Functions
url: https://nexyron.tech/docs/cypher/functions/geospatial
description: Nexyron's current geospatial MVP is intentionally small and composable.
---

# 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](https://nexyron.tech/docs/cypher/functions/geospatial/geo-distance-m)
-   [point](https://nexyron.tech/docs/cypher/functions/geospatial/point)
-   [distance](https://nexyron.tech/docs/cypher/functions/geospatial/distance)
-   [geo\_within\_bbox](https://nexyron.tech/docs/cypher/functions/geospatial/geo-within-bbox)
-   [geo\_within\_radius](https://nexyron.tech/docs/cypher/functions/geospatial/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