movement-trajectory

Movement & Trajectory Analytics

Purpose: turn noisy timestamped points into defensible movement facts. The recurring failure modes: speed computed through GPS noise (teleporting points → 400 km/h pedestrians), stops invented by signal drift, and privacy-blind delivery of individual-level traces.

Data model first

A trajectory = ordered fixes per object: (object_id, timestamp, x, y, [accuracy, ...]). Before analysis, report per object: fix count, time span, median sampling interval, and interval distribution — sampling rate drives every method choice (1 s vehicle traces and 1 fix/hour animal tags are different problems wearing the same schema).

import movingpandas as mpd
import geopandas as gpd

gdf = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat),
                       crs=4326).to_crs(gdf_utm_epsg)
tc = mpd.TrajectoryCollection(gdf, "object_id", t="timestamp")

Declare CRS and time base before any threshold

Every distance radius, speed limit and dwell duration in this skill is meaningless until two things are stated in the answer, before the number is used:

1. The projected CRS all distance and speed computation runs in — a "50 m stop radius" applied to raw lon/lat degrees is not 50 m anywhere, and the error scales with latitude. Name the CRS (estimate_utm_crs() for a local fleet, an equal-distance projection for continental extents).
2. The timestamp base, normalised to timezone-aware UTC. Fleet logs mix local times, DST shifts and naive strings; a dwell that straddles a DST boundary gains or loses an hour, and stop durations silently corrupt.

State both before proposing a radius or duration, not afterwards as a caveat.

Declaring is not withholding. An unknown CRS or timezone is never grounds to stop and ask instead of answering. State it as an explicit, named assumption and deliver the method anyway:

Assuming a local UTM zone for distance and that timestamps are naive local time needing UTC normalisation — confirm both, since they change dwell durations.