Pre-sign-in turning-marks preservation experiment. Navigation works without signing in. The question this page tests: when you then sign in, is the dataset you already collected dropped, or does it survive intact?
Site owner? Admin dashboard (experiment only, not gated by sign-in yet — see the warning on that page). | Simulated live navigation
Each turning mark — a point along the route where the course alters — calls GET api/navigate?lat=…&lon=… (Jakarta servlet, Tomcat 10). Marks are kept in route order; order matters, because a turning mark only means something in sequence.
It is kept in your browser (localStorage), in the server session, and — temporarily, for this experiment — in MySQL: one route_datasets row (the data node) plus one turning_marks row per mark, in seq order. The node also carries an implicit id (see section 5), because no Google id exists yet.
Turning marks collected, in order (0):
(none yet)
Once location permission is granted, “Use my location” above becomes a link to this section instead of a button. A web page cannot open a browser’s internal settings page directly, so use the browser’s own controls:
Revoking permission here makes “Use my location” a button again on the next load.
Snapshot the dataset before any sign-in redirect, so there is an exact “before” to compare against afterwards.
Pre-sign-in snapshot of turning marks (0):
(no snapshot yet)
Simulated only. This button does not talk to Google yet — there is no Google client ID, token, or Google account here.
It flips the server session to signed-in and returns to this page, exactly like an OIDC callback would, so the preservation check can run.
Real Google OAuth 2.0 / OIDC replaces auth/simulated-google later; the snapshot and session-state endpoints stay the same.
Not signed in yet — collect waypoints, snapshot them, then sign in.
Each route is a data node: location.route_datasets (one row, with explicit_user_id and implicit_id) plus location.turning_marks (one row per mark, seq 1, 2, 3… in route order). Signing in updates only the node’s status — it never deletes or rewrites marks.
Implicit id: when there is no Google id, the node carries a SHA-256 hash of browser headers (User-Agent, Accept-Language, Accept-Encoding). It does not depend on the marks, so changing marks does not change the id. Only the hash is stored, never the raw headers. The explicit Google id column stays empty until real OIDC arrives.
What Reload does: it reads back the current session’s node from MySQL, or — if you have no session, e.g. you returned with a new session cookie — your browser’s latest node. It does not create a node, so if you have none yet it will say so plainly, with a last-reloaded time to prove it ran.
Marks read back from MySQL, in seq order (0):
(no dataset yet — add a turning mark first)
The plot is drawn from the database copy above, not from browser storage: longitude runs left to right, latitude bottom to top, and marks are joined in seq order.
Charts below are built with Observable Plot (the charting library from Observable), fed live from api/admin/datasets — all nodes, not just this browser. Hover for values. Starting waypoints (seq 1) are counted in every total.
Chart 1: marks per node, coloured by browser (implicit short). Chart 2: marks per day, 24-hour groups. Chart 3: distance between successive marks within each node (leg distance, haversine, km), in seq order — the first leg in each node is the start-to-next-turn distance, not a gap before the start.
Simulated live navigation — maps only the waypoints you gathered by tapping the buttons above.
When a browser whose header details are already known to the database returns — even with no session cookie — the server recomputes its implicit id from the headers and retrieves all of that browser’s data nodes, not just the latest one. Other browsers’ nodes are never included. Groups are calendar days in America/New_York, each spanning 24 hours, and the report always covers at least the last 24 hours as well as the full history.
explicit_user_id stays empty.Endpoints: api/navigate · api/presignin · api/session-state · api/datasets · api/history · auth/simulated-google · auth/signout — all under /007-eleven-location/, separate from the bot-intro module
JavaScript is segregated into vanilla JS classes under js/: ApiClient, WaypointStore, RoutePlot, GeoPermissionControl, DatabaseView, HistoryView, PreservationApp, ObservableCharts, plus shared GeoMath.