nexyron.temporal_geo_dbscan
Generic Description
Cluster one temporal property history of geographic points using DBSCAN.
Simple example:
CALL nexyron.temporal_geo_dbscan(42, 'position', 0, 10000, 75.0, 3)
YIELD ts, lat, lon, cluster_id, is_noise
RETURN ts, lat, lon, cluster_id, is_noise
Temporal and streaming procedures inspect registered temporal history, rollups, time ranges, and global event timelines.
Consumer-Level Explanation
Use this procedure when one node has a temporal location history and you want to group those historical samples into dense geographic clusters.
Inputs:
node_idpropertyfromtoeps_mmin_pts
The property history can currently hold either:
- native point values
- object payloads like
{lat, lon}or{latitude, longitude}
Conceptual Explanation
This procedure does not introduce a new geo-track storage model.
It uses the current temporal-property model:
- read hidden temporal history for one node property
- normalize each value into a WGS84 point
- run in-memory DBSCAN over the filtered time range
- return cluster labels for each historical sample
That keeps geo clustering on top of the current architecture instead of adding a second temporal geo subsystem.
More Detailed Explanation
In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with YIELD and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.
Advanced Example
MATCH (r:Runner {name: 'Mia'})
CALL nexyron.temporal_geo_dbscan(id(r), 'position', 1710000000000, 1710086400000, 60.0, 4)
YIELD ts, value, lat, lon, cluster_id, is_noise
RETURN ts, lat, lon, cluster_id, is_noise, value
ORDER BY ts
Real Use Cases
- find repeated stop zones or dwell areas in one runner, courier, or vehicle history
- separate dense local movement from isolated outlier samples
- pre-label historical temporal positions before session alignment or downstream feature work
- compose the procedure output with
YIELD,WITH, andRETURNrather than hiding follow-up logic outside Cypher
Real Limitations And Tradeoffs
- This first implementation is per-subject and bounded-window oriented.
- It uses direct point-to-point distance checks, not a geospatial index.
- It currently clusters WGS84 points only; cartesian temporal points are not part of this procedure.
- procedure calls are explicit contracts; missing state, unsupported parameters, or absent artifacts should fail rather than silently falling back