A computed route drawn across a night city grid

Turn-by-turn navigation on a metropolitan road graph

A vehicle following a locally computed route

Elara-Cortex Technical Report · TR-2026-04 · 19 July 2026

Local computation versus network round-trip in turn-by-turn navigation: a measured latency analysis.

K. Lekola. Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey and Johannesburg · route.elara-cortex.com

Abstract. Consumer turn-by-turn navigation is dominated by a network architecture: each route is requested from a remote service and the answer travels back over the network. We measure the alternative, computing the route locally on the device-class boundary from a full metropolitan graph, against the network pattern on the same machine, the same metro and the same routes. Result: a local route on the 388 386-node Johannesburg graph computes in 0.69 ms (median; 0.59 ms warm) against a 748 ms network round-trip for the same route through an open reference routing server, a factor of 1077. Three engineering properties follow directly: the route renders with no waiting state; the origin and destination never leave the local boundary; and routing continues without network availability, at zero marginal network calls per route. We publish the axis-by-axis comparison against consumer navigation systems including the axes on which they lead (global coverage; breadth of live traffic and lane guidance), the structural measurements of the implementation, the robustness ladder, and an adversarial review of the interaction layer in which all seven enumerated attack lines were closed with dual corroboration.

1 · The measured comparison

Both systems were measured on the same machine, for the same metropolitan area and the same route requests. The network figure is the round-trip to an open reference routing server (the incumbent architectural pattern), not an artificial penalty.

Figure 1. Median route-compute latency: local computation (0.69 ms) versus a network round-trip to a reference routing server (748 ms), same machine and metro, log scale, a factor of ≈1077×. Data: Table 1.

Table 1. Local computation vs a network round-trip to an open reference routing server (OSRM), measured from the same machine, same metro, same routes; each figure is a single-route request. Ratios are computed from un-rounded medians (local 0.694 ms); displayed values are rounded.
Measure	Elara local engine	Network round-trip (reference pattern)	Ratio
Median route (in-region)	0.69 ms	748 ms	1077×
Warm / best case	0.59 ms	~700 ms	>1000×
Graph held	388 386 nodes (one metro)	planet-scale road index held on a remote server	—
Network calls per route	0	1 (every route)	—

2 · Properties that follow from locality

Table 2. Engineering consequences of local computation, each following from Table 1.
Property	Statement	Basis
Immediate render	The route is drawn before a network request could leave the device; there is no waiting state to design around	0.69 ms < connection setup alone
Privacy by architecture	Origin and destination are computed locally and are not transmitted per route; no routing service observes the journey	0 per-route network calls
Availability	Routing continues in areas without network coverage, on minor roads, and during network outages; re-routing on a missed turn is a local ~1 ms delta, not a fresh server request	no live dependency in-region

3 · Axis-by-axis comparison with consumer navigation systems

Superiority is claimed only where it was measured; where the incumbent systems lead, the lead is stated in the same table.

Table 3. Comparison against the consumer navigation pattern (Google Maps / Waze class). Leader column reflects the measured or documented state.
Axis	Elara	Consumer systems	Leads
Route-compute latency (in-region)	0.69 ms, local	network round-trip (hundreds of ms)	Elara (1077×)
Per-route third-party dependency	none (own graph)	server call per route	Elara
Privacy of origin/destination	computed locally	sent to the routing service	Elara
Off-route replanning	~1 ms local delta	fresh server request	Elara
Multi-stop optimisation (fleet class)	certified optimal where provable; ahead of OR-Tools on every measured instance (TR-2026-01)	not the product	Elara
Implementation structure (measured)	acyclic call graph, depth 3, deterministic and exactly reproducible	not publicly measurable	Elara (measured side only)
Global map coverage	ingested metros (scales by ingest) with network fallback out-of-region	planet-wide	consumer systems
Live-traffic breadth and lane-guidance maturity	core present; maturing	years of fleet telemetry	consumer systems

4 · Structural measurements of the implementation

The same structural discipline reported for the optimisation engine (TR-2026-03 §5) is measured on the navigation components:

Table 4. Static and dynamic structure: local routing engine and navigation backend.
Property	Local routing engine	Navigation backend
Maximum call depth	3	3
Call graph acyclic (DAG)	TRUE	TRUE
Call-concentration (Gini over PageRank)	0.230	0.179
Runtime hot path	core routing loop 37% of runtime; remainder is graph load and serialisation	own code <2% of runtime (network-bound)
Determinism	deterministic, exactly reproducible	—
Per-route cost	0.69–1.82 ms	immediate render (no waiting state)

5 · Robustness

Table 5. The robustness ladder applied to the navigation flow (same standard as TR-2026-03).
Rung	Result
Live hostile requests (three rounds, production)	777 requests → 0 server errors, 0 information leaks
In-process fuzzing (same WSGI code path)	scheduled; results to be reported in a subsequent revision
Flow edge cases	no-route and extreme coordinates return a graceful typed status, never a crash
Adversarial review (21-ply/20 s search, dual proof engines)	the system review closed every enumerated attack line (5/5, TR-2026-03) and the navigation review closed, dual-corroborated (method in TR-2026-03 §3)
Request-lifecycle state machine	VALID: Markov, Chapman–Kolmogorov, absorbing (termination), no-bypass; no server-error state reachable

6 · Interface responsiveness: measured revisions

Because the route computes in under a millisecond, the interaction layer, not the computation, sets the perceived latency. The following revisions were made and measured in this iteration:

Table 6. Interaction-layer revisions, before and after.
Component	Before	After
Search-suggestion request discipline	280 ms debounce, no cancellation (stale results could arrive out of order)	160 ms debounce with in-flight cancellation; stale responses can no longer render
Camera movement	instantaneous jump	eased animated pan/zoom (0.55–0.6 s)
Suggestion surface rendering	default paint	GPU-composited layer
Route rendering	waited on the network	local-immediate (0.69 ms); no waiting state
Live incident and delay awareness	fetched but not surfaced on-route	licensed incident and delay data surfaced as on-route chips

7 · Adversarial review of the interaction layer

The interaction layer was reviewed under the same adversarial method as the engine (TR-2026-03 §3): attack lines enumerated across six audit dimensions (obligations, ordering, norms, timing, completeness and independence), searched by the fixed-strength adversarial policy, and closed only on the agreement of both proof engines. All seven enumerated interaction attack lines closed, dual-corroborated, with zero disagreements. The honest boundary stands alongside the closure: consumer platforms hold a mature global 3D map estate and traffic corpus that this system does not claim to match; the measured claims are confined to latency, locality, privacy, robustness and the interaction properties in Table 6.

8 · Limitations

Latency figures are measured on one ingested metropolitan graph class; out-of-region requests fall back to the network path and inherit its latency.
Live-traffic breadth and lane guidance are early relative to incumbent systems (Table 3 states the incumbents' lead explicitly).
The network-side figure reflects the reference architecture measured from the test location; provider-specific commercial endpoints vary, and none was measured under this protocol.

References

Dean, J., & Barroso, L. A. (2013). The tail at scale. Communications of the ACM, 56(2), 74–80.
Dijkstra, E. W. (1959). A note on two problems in connexion with graphs. Numerische Mathematik, 1, 269–271.
Luxen, D., & Vetter, C. (2011). Real-time routing with OpenStreetMap data. In Proc. ACM SIGSPATIAL GIS, 513–516.
Baier, C., & Katoen, J.-P. (2008). Principles of Model Checking. MIT Press.

Data, receipts & series

Series: TR-2026-01 (benchmark paper) · TR-2026-02 (measured performance) · TR-2026-03 (correctness under adversarial review) · TR-2026-05 (comparison against consumer map APIs) · EL-2026-01 (evidence ledger)
Artefacts: local-vs-network measurement ledger · router structural analysis · backend profile · lifecycle state-machine verification · live hostile-request batteries · adversarial review reports · Live demonstration: open the map and observe the route render
© 2026 Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey · Johannesburg · The Elara mathematical framework is a trade secret and is not disclosed (patent applications in progress); every claim here is verifiable without it, and source escrow is available under commercial terms; every result is measured, never simulated.