This family covers two geometries that share a shape — a sequence of connected coordinates — but differ in the one property that determines how they must be handled: order. A road centerline or a river is an unordered (or arbitrarily ordered) polyline; traversal direction is a property of the thing it represents, not of the geometry file. A device trajectory is an ordered, timestamped sequence of positions where the order is the information — a home→highway→store sequence and a store→highway→home sequence are the same three points in a different, meaningful order. That difference is why trajectories carry a materially higher privacy exposure than any other member of this catalogue, addressed further down.
- Cardinality
- Unordered for roads and rivers; strictly ordered and timestamped for trajectories
- Governed by
- A mapping vendor for roads/transit; the recording device for trajectories
- Not a geometry
- A route name or transit-line id, distinct from its actual path geometry
- Converts via
- Line/corridor intersection against the H3 grid, order preserved when present
Members
| Member | Ordered? | What it represents |
|---|---|---|
| Road centerline | No (direction is attribute data, not sequence) | A street or highway segment |
| Transit line | Yes (route direction matters) | A bus/rail route path |
| River | No | A natural watercourse |
| Utility network line | No | A pipeline, cable, or conduit run |
| Device trajectory | Yes, plus timestamps | An individual's or vehicle's journey |
| Journey / trip | Yes, plus timestamps | A trajectory bounded to one origin-destination trip |
Required metadata
| Field | Why it's required |
|---|---|
| CRS | Standard EPSG:4326 normalization, as with any other geometry family |
| Direction (lines) | Needed for transit and utility-flow semantics even though the geometry itself may be stored unordered |
| Timestamps (trajectories) | What makes a trajectory a trajectory rather than an unordered line; without them, order is unverifiable |
| Sampling rate (trajectories) | Determines achievable resolution and how much GPS noise to expect between fixes |
| Consent state (trajectories) | Governs both the resolution and the retention window a trajectory may legally be processed at |
Common risks
GPS noise and boundary oscillation affect both members, but bite hardest on trajectories: a noisy fix sitting near a cell edge flips the assigned cell back and forth between two neighbors on successive samples, inflating a transition count that never actually happened; roads and rivers suffer the corridor-scale version of the same problem, where a path skimming a cell edge produces a jagged, duplicated cell sequence rather than a clean corridor. Both are mitigated the same way — smoothing, snapping within the accuracy radius, and debouncing repeated A→B→A transitions — before the sequence is trusted for corridor analysis. Direction loss: treating a transit line or utility network as undirected when direction is operationally meaningful (which platform serves which stop first, which way current or flow moves) silently drops information the geometry file never encoded in the first place; direction has to be carried as attribute data alongside the line, not inferred from vertex order.
An ordered, timestamped, high-resolution trajectory can uniquely identify a person from a home/work pattern alone, independent of any single point's individual precision. This risk does not exist for an unordered road or river line, and it does not exist for a single point in isolation — it is specific to the ordering and density of positions in a trajectory. Coarsen space or time, drop the ordering, or aggregate to origin-destination pairs before trajectories leave a privacy boundary; see privacy and minimum aggregation.
How it converts to H3
Both members convert by intersecting the line against the H3 grid — a plain line-to-cell intersection for roads and rivers, or a buffered-corridor fill when the line needs to be treated as a band with width — documented on line and corridor to H3. Trajectories use the same geometric intersection but additionally require the ordering and timestamps to be carried through the conversion so that dwell extraction and sequence analysis remain possible downstream; converting a trajectory without preserving order collapses it into an unordered multipoint and should be treated as a multipoints case instead, with the ordering loss recorded explicitly rather than silently dropped.