Every technical layer, explained

The parser accepts direct latitude and longitude plus common Apple Maps, Google Maps, Amap, and Baidu links. It extracts a place name and coordinates from URLs, query parameters, or a bounded page response, then returns the source, confidence, original system, and warnings.

• Input length is bounded, and coordinates must stay within latitude ±90 and longitude ±180.
• Short links follow only a limited number of redirects; local, private-network, and cloud-metadata addresses are rejected.
• Unrecognized input returns a clear error instead of inventing a plausible location.

input   https://maps.google.com/.../@37.795490,-122.393700
output  source=google_maps · system=WGS84 · confidence=0.94

Different maps may expose WGS84, GCJ-02, or BD-09. WLOC preserves the original values and system while normalizing the internal target to WGS84, rounded to six decimal places for reusable favorites, routes, and regression baselines.

• Amap and some mainland-China map contexts are treated as GCJ-02.
• Baidu inputs are treated as BD-09 and converted through GCJ-02 to WGS84.
• Domestic offset conversion is skipped outside mainland China, and conversion warnings disclose possible meter-level error.

original   31.230416, 121.473701 · GCJ-02
canonical  31.xxxxxx, 121.xxxxxx · WGS84

WLOC encodes the current target, favorites, routes, device profile, diagnostic events, and settings as JSON, then writes the snapshot atomically to the app's Application Support directory. The app restores from that snapshot without requiring a cloud account.

• Saved places and routes are not uploaded into a searchable coordinate history by default.
• Resetting or uninstalling the app removes the local snapshot; export is user initiated.
• Parsing and conversion requests serve a real-time response, while website analytics are disclosed separately.

WLOC prepares official setup resources from the current target and device profile. In a compatible, explicitly authorized environment, the saved target takes priority over the default. With no target, the path remains in pass-through and keeps the real network-location result.

• This is a network-location test path, not a global write to the GPS receiver or Core Location.
• A static target represents one state; a route advances through nodes, timing, pause, and resume state.
• Whether a target app adopts the result still depends on its permissions, cache, account, and server decisions.

mode=active      → saved test target
mode=route       → current route node
mode=passthrough → real network-location result

Diagnostics first checks whether the official Worker is reachable, then checks device setup, current mode, target coordinates, route state, and whether a recent location request and matching result were observed. That separates service, setup, request, cache, and target-app behavior.

• The health check returns environment and version so service failure is not mistaken for location failure.
• Device status distinguishes active, route, and passthrough, with timestamps for save, clear, request, and result evidence.
• A running route with no request and an observed request with no confirmed result produce different warnings.

Stopping a route or clearing the target returns the supported path to passthrough. The team then reopens the target app and confirms that an old city, geofence, or nearby list is not still coming from cache.

• WLOC can clear its own target and route state, but it cannot force-close another app.
• It cannot clear the system locationd cache on behalf of iOS.
• Complete evidence includes both the test state and the restored real-location state.