Project presentation
TritonNav · Google Slides
View presentationProduct · Engineering · Research2025 — 2026Research case study
TritonNav
A campus-aware pedestrian navigation prototype, connecting destination research, interface design, and open-source routing—and testing the result on a real iPhone.
- Role
- Founder · Product designer · Software engineer
- Context
- UC San Diego · Pedestrian wayfinding
- Evaluation
- One evaluator · Physical iPhone trials
- Status
- Working prototype · Local routing evaluated
Real iPhone captures · Prototype route previews · Displayed ETAs are interface state, not additional field measurements.
23
Measured walks
Completed iPhone trials with numeric timing pairs
0.96 min
Mean absolute error
Primary measured-only timing sample
2
Route failures
Recorded checks, not a timing-sample failure rate
40
Unique trial IDs
Across 41 keyed workbook records
Curated research navigator
AI Research Guide
Evidence-grounded answers from this study and its paper. Curated, not generated; no live AI or personalized retrieval.
01 / The problem
A campus destination is more than a pin.
On a campus, a room code can be more useful than a building name. A college can mean an entire neighborhood. And the center of a building is rarely the place a person should walk to.
TritonNav explores a narrower, concrete problem: resolve familiar UC San Diego destinations and display genuine pedestrian routes in a mobile-first interface. It is not complete indoor navigation, and it does not certify accessible paths.
RQ1 · Timing agreement
How do recorded walking durations compare with Valhalla ETAs in usable physical-iPhone trials?
RQ2 · Failure modes
Which routing, destination, and rendering problems appear in the field workbook?
RQ3 · Sensitivity
Do approved corrections or modeled scenarios change the descriptive timing result?
02 / Design response
Resolve the place. Then compute the path.
The interface brings destination search, a visible starting point, route geometry, and a destination/ETA sheet together over the map. The supplied iPhone captures show this route-preview state, not a claim about every destination or current deployment behavior.
The product separates three responsibilities: campus destination intelligence, pedestrian route computation, and map rendering. That boundary matters: a routing engine can compute a plausible path to the wrong place.
01 · Search
Resolve a campus room, building, college, housing location, entrance, or place.
02 · Anchor
Prefer an entrance coordinate over a building centroid where campus data provides one.
03 · Route
Send origin and destination coordinates to the internal walking-route adapter.
04 · Render
Draw the normalized GeoJSON LineString with MapLibre and display the returned route information.
03 / System architecture
A modular stack, evaluated on the ground.
Next.js/React provides the mobile web interface. Capacitor wraps the hosted application in an iOS shell. MapLibre GL JS uses OpenFreeMap for the basemap and renders the markers and returned route.
The local evaluation used Docker-hosted Valhalla with routing tiles built from a UCSD-area OpenStreetMap PBF. The solid path below is the verified local architecture; the dashed production path remains planned. A deployed web application cannot reach a routing service on the developer’s localhost.
Campus-aware resolution
The campus data layer translates familiar destination labels into routable coordinates. GIS and entrance provenance are provisional; resolving a label is not proof that its placement is correct.
Entrance-aware routing
Entrance coordinates are preferred where available, rather than routing blindly to a centroid. Field errors show why these anchors still need verification.
Valhalla + route adapter
POST /api/routes/walking reads the server-side VALHALLA_BASE_URL, calls Valhalla, validates the response, and returns normalized route data. The browser does not receive the routing-service address or credentials.
MapLibre + Capacitor
MapLibre renders OpenFreeMap tiles and GeoJSON LineString routes. Capacitor provides the iPhone container and native permission configuration while preserving the web codebase; this is not a React Native implementation.
04 / Evidence audit
Completion is not the same as a measured walk.
The source workbook contains 41 keyed records and 40 unique trial IDs: Trial ID 25 occurs twice. Of the keyed records, 39 are marked complete and two incomplete. One additional completed row has no trial ID and is excluded from keyed counts.
The primary timing sample includes only 23 completed physical-iPhone trials with numeric original actual durations and Valhalla ETAs. Untimed interface checks and a Mac check are not physical walking observations. The strict 17-trial subset requires entered and timestamp-derived durations to agree within 0.5 minutes.
Signed error is actual time minus Valhalla ETA; negative values mean the recorded walk was faster. All timing results are descriptive, not population-level validation.
05 / Measured results
Walks were shorter than the estimates, on average.
In the 23-trial primary sample, recorded walking time averaged 5.70 minutes, compared with 6.48 minutes estimated by Valhalla. Mean signed error was −0.78 minutes; mean absolute error was 0.96 minutes.
The stricter timestamp-consistent subset produced a similar descriptive result. This does not establish calibrated accuracy across campus users or repeatability for individual routes.
Primary measured-only · 23 trials
- Signed error
- −0.78 min
- Absolute error
- 0.96 min
Strict measured-only · 17 trials
- Signed error
- −0.76 min
- Absolute error
- 1.00 min
06 / Field issues
A correct route to the wrong entrance is still a failure.
Eight records report at least one wrong turn, four contain narrative issues, two record routing failures, and two describe incorrect destination placement. These categories overlap; adding them would not produce a unique count of affected trials.
CSB Building → Marshall College
No route was returned; the notes report a college diagram. Current resolver diagnostics cannot resolve both historical endpoints.
RIMAC → Seventh College Housing
The recorded check showed neither a route line nor a map. Historical label resolution also exposes campus-data gaps.
Peterson Hall → Sixth Market
The destination was reportedly placed near DIB instead of the intended market.
Center Hall → Pepper Canyon Hall
The duplicated Trial ID 25 record reports four wrong turns, an incorrect entrance, and placement at Bonner Hall despite a completed label.
07 / Exploratory only
Sensitivity checks are not additional measured walks.
Trial 2’s approved ETA normalization converts a date-typed source value to 3.0 minutes. The resulting 24-record normalized set has signed error −0.75 minutes and absolute error 0.92 minutes. It remains outside the primary measured-only analysis.
Substituting timestamp-derived durations for seven conflicting entries produces signed error +0.42 minutes and absolute error 2.33 minutes. Trial 23’s entered four-minute duration conflicts with a 33-minute timestamp span; that discrepancy must be reconciled, not silently corrected.
Twelve untimed checks were filled as hypothetical scenarios using a current Valhalla ETA × 0.875, the strict sample’s median actual-to-ETA ratio. The resulting 36-record exploratory set has signed error −0.88 minutes and absolute error 0.99 minutes. Because ETA helps generate the scenario durations, these values cannot independently validate Valhalla.
08 / Limits & changes
The next improvement is better evidence, not a stronger claim.
One evaluator, mostly unique routes, coarse timing, absent numeric GPS-accuracy logging, provisional GIS/entrances, and inconsistent source units limit what this study can establish. Distance was not analyzed because source entries mixed units. No accessibility or deployment-readiness claim follows from these results.
What changed through the audit was the interpretation of success: completion labels no longer stand in for walks, measured values stay separate from corrections and models, and route-engine behavior is considered alongside destination placement. These are documented evidence and architecture decisions, not an invented before/after redesign.
The evaluation supports the feasibility of a modular open-source campus-navigation architecture. It also makes the next experiment specific.
Repeat routes with multiple participants
Pre-register a compact route set and measure repeatability across people, walking speeds, and device conditions.
Verify GIS and entrances
Validate destination coordinates, canonical entity IDs, and selected entrances against reliable UCSD data.
Log precisely and trace issues
Capture timestamps, horizontal location accuracy, app commit, device/OS, provider metadata, and linked issue records. Separate checks from walks at collection time.
Evaluate accessibility; host routing
Evaluate with representative users and verified path data before making accessibility claims. Move Valhalla to a production HTTPS host before treating local routing as deployment-ready.
09 / Research artifacts
The full paper.
TritonNav: Field Evaluation of a Campus-Specific Pedestrian Navigation Prototype
Diego Cordova · UC San Diego · September 30, 2026 · 7 pages
The system report, dataset audit, measured analysis, sensitivity checks, limitations, and references in one document.
Paper preview · Page 1 of 7
PDF reader availability varies by browser. Open the full document in a new tab.
