Browse documentation
Use cases / Maps & spatial tools

Maps & spatial tools

Keep the map editable while workers inspect its data.

Source documentationView source ↗
On this page

Keep your map editable while workers inspect it. This is an implementation pattern, not a claim that a specific production application uses zerocopy.

The problem#

A map editor may have lane records, route metadata, selection state, and derived indexes. Copying all of that into every analysis worker can make data movement part of every operation.

Put the large, shareable collections in the data layer. Keep small UI state, such as open panels and pointer position, in the normal application store.

Share the inputs. Return the answer.#

The main thread owns the editable collections. Dedicated workers receive snapshots and run independent checks. Results can be small: invalid lane IDs, counts, or route warnings.

Use the connection pattern from the direct-read quickstart, but supply a map-specific state such as { features: SharedMap<...> }. Inside that connected worker:

ts
// With map-specific state containing a features collection.
const snapshot = shared.current;
const featureIds = ['road-1', 'road-2'];
const unknown: string[] = [];

for (const id of featureIds) {
  if (!snapshot.features.has(id)) unknown.push(id);
}

There is no RPC inside this loop. Your existing worker can call it directly. An optional task executor can schedule the whole calculation.

Keep edits and results in order#

Capture an application edit revision when you request an assessment. Before applying its result, check that the relevant inputs have not changed. Do not infer exact input pinning from a task Promise or from a pool batch.

Independent workers can receive the same root group with state.connect([workerA, workerB]). Use a pool when interchangeable jobs need scheduling. Keep separate workers when they have distinct roles or long-lived local indexes.

Divide the dataset deliberately#

A tile or layer can be a useful unit of work. However, objects near a tile boundary may need neighboring data. Share the required input roots together and make the dependency explicit.

Do not assume that dividing work into tiles automatically gives one writer per arena. Logical partitioning and memory ownership are separate design choices. Measure retained memory and snapshot lifetime before choosing a compaction policy.

When to use another tool#

Zerocopy does not replace a spatial database, coordinate system, geometry algorithm, or GPU buffer pipeline. It supplies shared immutable collections and optional worker execution.

Use typed arrays when a packed numeric buffer is the right representation. Use a spatial index when the query needs one. Compare the full workflow, including conversion and attachment, rather than one lookup in isolation.

Try real worker reads or connect your existing workers.

Found something unclear?Improve this guide ↗

Type a topic to find a guide.

↓ ↑ to move · Enter to open · Esc to close

Browse documentation →