Source-linked AI summary
Trajectools Demo: Towards No-Code Solutions for Movement Data Analytics
Anita Graser, Melitta Dragschnig
TL;DR
Movement-data libraries require programming expertise and have limited visualization, while GIS no-code tools do not support spatio-temporal movement data. This paper presents Trajectools, a QGIS plugin wrapping MovingPandas functions, and demonstrates a workflow for matching GPS vehicle tracks to a GTFS segment. The demonstration reports computed segment speeds, while noting sparse GPS reporting affects them and actual segment length should be used for correction before comparison with scheduled speeds.
Problem
Movement-analysis libraries are fragmented and require programming skills, while GIS no-code tools do not extend to spatio-temporal movement data.
Source: §I · p. 1Method
Trajectools wraps selected MovingPandas functions as QGIS Processing algorithms and uses a model combining trajectory tools with GIS operations to match vehicle tracks to a selected GTFS segment.
Source: §II · p. 1, §III · p. 3Results
The demonstration produces trajectories and computed average segment speeds, but sparse reporting affects the computed speeds, which should be corrected using actual segment length before comparison with scheduled speeds.
Source: §III · pp. 3–4Takeaways & Limitations
The authors present Trajectools as a prototype for adding mobility-data support to other GIS-based no-code environments.
Source: §IV · p. 4Sparse GPS reporting affects computed trajectory speeds, so actual segment length should be used for correction before comparison with scheduled GTFS speeds.
Source: §III · pp. 3–4
Abstract
from arXiv · showhide
This demo paper presents the conceptual foundations and the first steps towards implementation of a novel no-code solution for movement data analytics based on the open-source Python library MovingPandas and the open-source geographic information system QGIS. The resulting Trajectools plugin is available open-source at https://github.com/movingpandas/qgis-processing-trajectory.
I. INTRODUCTION
Movement data analytics libraries remain fragmented, programming-intensive, and limited in visualization, while GIS no-code tools do not support spatio-temporal movement data. Trajectools addresses this gap by bringing movement-data analysis into a GIS-based no-code environment.
I. INTRODUCTION
- Movement-analysis libraries across Python, R, and other languages remain fragmented, require programming skills, and have limited visualization capabilities.These barriers make the libraries difficult to learn and limit their use and transfer of research advances to other disciplines, industry, and the wider public.Source: §I · p. 1
- GIS-based no-code workflow tools are popular for spatial analysis, but existing tools do not extend to spatio-temporal movement data.Other widely accessible visual analytics systems also have very limited spatio-temporal capabilities.Source: §I · p. 1
- Integrating movement libraries into GIS is hindered by incompatible data models: GIS Simple Features lacks a standardized temporal dimension, while OGC Moving Features is not widely adopted.The paper notes that this mismatch complicates movement-data handling in GIS workflows.Source: §I · p. 1
II. TRAJECTOOLS CONCEPT & IMPLEMENTATION
Trajectools wraps selected MovingPandas functions as algorithms in QGIS Processing, using GIS vector layers to pass movement data through modular workflows. The implementation supports trajectory processing and visualization while retaining compatibility with existing GIS tools.
II. TRAJECTOOLS CONCEPT & IMPLEMENTATION
- Trajectools adds trajectory algorithms to QGIS Processing by wrapping a subset of MovingPandas functions, with additional functions planned as development progresses.The implementation uses the Python plugin extension capabilities of QGIS and the open-source nature of both tools.Source: §II · p. 1
- Raw inputs are GIS point layers with timestamps and trajectory IDs; algorithms produce processed trajectories or derived outputs such as significant points and flows.Inputs may come from CSV, GPX, or GIS-readable databases, and a layer may describe one or more trajectories.Source: §II · p. 1
- The implementation uses SF-based vector layers and shared trajectory ID and timestamp fields as interfaces, preserving attribute names to support chaining tools.A common base class defines input points, trajectory ID, timestamp, and speed units; timestamp formats and CRS are inferred automatically wherever possible.Source: §II · pp. 1–2
- Trajectory manipulation tools output both points and linestrings, enabling follow-up analysis and chaining; available tools include creation, overlays, and splitting.Splitting criteria include observation gaps, stops, and time intervals; outputs are populated with speed, direction, and trajectory movement attributes.Source: §II · p. 2
- The point output visualizes speed and direction, while trajectory styling visualizes movement direction.Fixed speed-gradient limits (currently 0–50 km/h) aid comparison across runs but may not suit all applications; users can alter the limits.Source: §II · pp. 2–3, Figure 2 · p. 2, Figure 3 · p. 2
- Event-extraction tools produce non-trajectory outputs, including origin-destination points and stop points, which can feed other algorithms but not trajectory-input algorithms.Other described examples include flows and home ranges, represented as lines or polygons respectively.Source: §II · p. 3
III. DEMONSTRATION
The demonstration uses a QGIS Processing model to identify public-transport vehicle tracks matching a selected GTFS route segment and compute segment speeds. The resulting speeds are affected by sparse GPS reporting and should be corrected using actual segment length before comparison with scheduled speeds.
III. DEMONSTRATION
- The model identifies vehicle trajectories matching a selected GTFS route segment despite the lack of common keys between GPS tracks and the schedule.It selects a GTFS segment, finds nearby candidate tracks, filters for matching start and end locations to enforce direction, then clips at those locations to exclude stop waiting times.Source: §III · p. 3
- The model produces intermediate outputs that help users understand and debug the analysis, and the GUI allows these outputs to be deactivated.The automatically generated model GUI is shown in Figure 5.Source: §III · p. 3, Figure 5 · p. 4
- The model combines Trajectools splitting and clipping with default Processing Toolbox algorithms for spatial analysis and attribute-based joins.This demonstrates interleaving new trajectory tools with existing GIS algorithms rather than rebuilding those capabilities.Source: §III · p. 3
- Sparse GPS reporting affects computed trajectory speeds, so actual segment length should be used to correct speeds before comparison with scheduled GTFS speeds of 21–24 km/h depending on time of day.The tracks can cut corners between reported locations, affecting the computed distance.Source: §III · pp. 3–4, Figure 6 · p. 4
IV. OUTLOOK
The authors present Trajectools as a prototype for adding mobility-data support to GIS-based no-code environments. Future work includes adding MovingPandas functionality and integrating related movement-analysis libraries.
IV. OUTLOOK
- Trajectools and its conceptual approach can serve as a prototype for adding mobility support to other GIS-based no-code environments.The authors describe further integration work as ongoing to achieve feature parity with MovingPandas by adding cleaning, resampling, smoothing, and aggregation.Source: §IV · p. 4
- Future work envisions integrating scikit-mobility and Trackintel algorithms into Trajectools for use within the no-code environment.The authors expect shared (Geo)DataFrame data types to make exchange between libraries relatively straightforward.Source: §IV · p. 4