This organization hosts the source code for the MobilityDB ecosystem — an open-source platform for geospatial trajectory data management and analysis.

For the conceptual overview, type system, tutorials, quickstarts, and encoding specifications, see libmeos.org — the project's public front door. This page is the repository map: where each piece of code lives.

The project is developed by the Computer & Decision Engineering Department of the Université libre de Bruxelles (ULB) under the direction of Prof. Esteban Zimányi. ULB is an OGC Associate Member and member of the OGC Moving Feature Standard Working Group (MF-SWG).

Detailed explanations and application scenarios are in the project's textbook:

Mahmoud Sakr, Alejandro Vaisman, Esteban Zimányi. Mobility Data Science: From Data to Insights. Springer, 2025.

The companion datasets and reproducible scripts live in MobilityDataScienceBook.

Evidence that the ecosystem is complete, correct, and ready for real-world deployment — measured, not asserted. Two published assessments, one per platform group, each covering function-surface coverage, BerlinMOD query-result parity (identical results across engines), and BerlinMOD performance benchmarks:

• Streaming — parity & benchmarks — MobilityFlink / MobilityKafka / MobilityNebula.
• Databases — parity & benchmarks — MobilityDB / MobilityDuck / MobilitySpark.

Each section below maps to a colored box in the figure (its heading marker matches the box color); the figure draws the main components of each box, and the bullets list all of them.

The interchange band drawn beneath MEOS: trajectories move between the engines and the MobilityLakehouse without re-encoding — the data-side complement of the SQL layers' portable computation. The MobilityLakehouse repository is the single home for the overview, the format specification, the getting-started guide, and the live AIS Iceberg Explorer demo.

• TemporalParquet — the on-disk form: a Parquet footer convention for temporal types (specification).
• MobilityLakehouse — the storage architecture: TemporalParquet files organised as Apache Iceberg tables (or DuckLake tables over the same files) under an Iceberg REST catalog, Apache Polaris recommended, and read by MobilityDB, MobilityDuck and MobilitySpark without conversion.

• MEOS — Mobility Engine, Open Source: the canonical C library underlying every other piece.

MEOS-API is a machine-readable description of the MEOS C-library API, generated from the MEOS headers via libclang:

• IDL JSON (meos-api.json) — the function and type catalog.
• Shape-metadata catalog — argument/return shape annotations for faithful code generation.

From this catalog the ecosystem generates the language bindings (PyMEOS, JMEOS, GoMEOS, meos-rs, MEOS.NET, MEOS.js — JMEOS also backs the MobilityFlink and MobilityKafka stream layers) and the HTTP API contracts (OpenAPI / MCP / runtime server, shown in the HTTP / API layer below).

Three SQL surfaces share the same MEOS-backed type system, function catalog, and BerlinMOD reference queries — the same query text runs against any of the three. The parity contract: the same BerlinMOD reference queries run across all three surfaces and must return identical results, validated by the cross-platform conformance suite in MobilityDB-BerlinMOD.

• MobilityDB · PostgreSQL — the project's reference SQL surface (PostgreSQL extension), spatiotemporally indexed via mest.
• MobilityDuck · DuckDB — peer SQL layer for analytics / columnar workloads.
• MobilitySpark · Apache Spark — peer SQL layer for distributed, large-scale workloads (MEOS-backed UDFs + DataFrame integration).

The same edge-to-cloud model runs on the streaming side, each tool in its canonical role. The published reference architecture is MobilityNebula (EDBT 2026), with real railway data (SNCB) as the application demonstration. The parity contract matches the SQL-layer one: the same BerlinMOD reference queries run across all three platforms in three streaming forms — continuous (always-on), windowed (tumbling / sliding / session), and snapshot (query at time T, ≡ the batch result at the same scale factor) — the snapshot form anchored to the batch BerlinMOD outputs. The Flink and Kafka platforms reach MEOS through a single MEOSBridge over JMEOS; MobilityNebula calls MEOS C directly.

• MobilityNebula · NebulaStream — the edge.
• MobilityKafka · Apache Kafka — the streaming transport backbone.
• MobilityFlink · Apache Flink — stream processing in the cloud.

• MobilityAPI · OGC API – Moving Features — a thin compiled (Go) server over moving-feature collections. It holds no temporal engine of its own: every temporal expression is named SQL the engine evaluates, so the same tier runs over MobilityDB, MobilityDuck or MobilitySpark, and its streaming surface reaches MEOS in process or through the Flink and Kafka bridges. It carries the Part 1 Annex A abstract test suite as its own tests, against a MobilityDB built from master.
• MobilityAPI-Python · OGC API – Moving Features — the same standard in Python over PyMEOS, the line MobilityAPI grew out of.

Three further HTTP surfaces are projected from the MEOS-API catalog over the MEOS algebra:

• OpenAPI — an OpenAPI 3.1 contract.
• MCP — a Model Context Protocol tool manifest, so LLMs / agents call the MEOS algebra directly.
• runtime — a runnable HTTP server, auto-generated from the catalog, that serves each MEOS function as an endpoint; the MEOS backend behind it is swappable (a compiled libmeos, or a stub for testing).

Each binding follows its language community's naming convention.

• PyMEOS — Python; the reference binding, built on the CFFI layer PyMEOS-CFFI, and the basis for MobilityPandas and MobilityAPI-Python; examples in PyMEOS-Examples.
• JMEOS — Java / JVM; also backs the MobilityFlink and MobilityKafka stream layers via MEOSBridge; examples in JMEOS-Examples.
• GoMEOS — Go; idiomatic wrappers over the MEOS C ABI.
• meos-rs — Rust; safe bindings to MEOS.
• MEOS.NET — .NET / C#; MEOS for the .NET runtime.
• MEOS.js — JavaScript / TypeScript; MEOS in the browser and Node; examples in MEOS.js-examples.

• MobilityPandas — MovingPandas backed by PyMEOS.
• MobilityOpenTripPlanner — OpenTripPlanner multimodal trip planning.
• MobilityMapMatching — map matching as a service.
• MobilityDB-PublicTransport — GTFS / NeTEx integration.

• MobilityDeck — deck.gl.
• MobilityFlink-Deck — deck.gl on the Flink stream layer.
• MobilityOpenLayers — OpenLayers.
• MobilityLeaflet — Leaflet.
• MobilityQGIS — QGIS integration.
• MobilityGeoServer — GeoServer.
• MOVE — QGIS plugin for visualizing MobilityDB query results.
• Franchise — notebook SQL client for exploring MobilityDB / MEOS-backed SQL.

• MobilityDB-AWS — deployment recipes and images for Amazon Web Services.
• MobilityDB-Azure — deployment recipes and images for Microsoft Azure.
• MobilityDB-GCP — deployment recipes and images for Google Cloud Platform.
• MobilityDB-docker — official Docker images for MobilityDB.

• meos-feedstock — conda-forge feedstock for the MEOS C library.
• pymeos-feedstock — conda-forge feedstock for PyMEOS.
• pymeos-cffi-feedstock — conda-forge feedstock for PyMEOS-CFFI.

BerlinMOD is the project's benchmark — a synthetic-trajectory generator and moving-object-database comparison tool that generates data on an OpenStreetMap base map via pgRouting, and the cross-platform conformance suite for the portable SQL dialect: the same queries run on all three SQL surfaces and must return identical results.

• MobilityDB-BerlinMOD — the BerlinMOD generator and benchmark itself, with the base maps of Brussels (default, BerlinMOD/brussels) and Hanoi (Vietnam, BerlinMOD/hanoi).
• MobilityDB-Brussels — a MobilityDB implementation of BerlinMOD.

• MobilityDB-workshop — hands-on workshop materials.
• MobilityDataScienceBook — companion datasets and scripts for the textbook.

• libmeos-website — source of libmeos.org, the project's public front door.
• mobilitydb-website — source of the MobilityDB project website.

• MobilityDB-Semantic — semantic trajectories in MobilityDB; reproducible artifacts accompanying the research.
• MobilityDB-TPCDS — a TPC-DS-based temporal data-warehouse benchmark; reproducible artifacts accompanying the temporal-OLAP article.
• FoundationModel — a semantics-enriched trajectory foundation model for urban and maritime mobility: enrichment pipelines and a Transformer-based encoder; the code of the accompanying Master's thesis.

mest provides Multi-Entry GiST and SP-GiST access methods for PostgreSQL — variants of GiST / SP-GiST that index complex and composite types more efficiently. The repository ships three extensions:

• mest — multi-entry R-tree / Quadtree for the PostgreSQL multirange and path types.
• postgis-mest — multi-entry R-tree / Quadtree / Kd-tree for PostGIS geometry / geography.
• mobilitydb-mest — the same for MobilityDB's MEOS types (spanset, tgeompoint) — the spatiotemporal indexes MobilityDB relies on, including in the cross-platform BerlinMOD benchmark.

Preserved in read-only form for historical reference and to keep existing links resolvable. Each carries an in-README banner pointing at its successor.

• MobilityDB-python → PyMEOS
• MobilityDB-JDBC → JMEOS
• pg_mfserv → MobilityAPI
• MobilityPySpark → MobilitySpark

The MobilityDB project has received funding from the European Union's Horizon Europe research and innovation programme under grant agreements No 101070279 MobiSpaces and No 101093051 EMERALDS.