TGIS/AI

TGIS — Strategy & Direction


The Core Idea

Build a Transport Global Intelligence System (TGIS) — an AI-powered layer that sits above the world's fragmented transport data platforms and lets anyone, regardless of technical skill, query, combine, and make sense of that data through natural language.

The system acts as connective tissue between dozens of existing platforms, datasets, and knowledge sources that today require specialist skills to navigate individually and are almost never used together.

Why This Matters Now

Three forces have converged:

  1. The UN Decade of Sustainable Transport (2026–2035) launched in December 2025 with an Implementation Plan that calls for progress monitoring across six priority areas. Proposals for a global tracking framework exist — from SuM4All, TDC, and SLOCAT among others - but he data infrastructure to underpin the Decade's accountability goals remains largely unbuilt.
  2. AI/LLM capabilities have reached the point where natural language querying of complex, heterogeneous data is technically feasible and affordable. This was not possible three years ago.
  3. The data already exists — our audit of 25 sources found 14 with open REST/SDMX APIs requiring no authentication, and another 6 with free access. The problem is data fragmentation.

What Makes This Different

There is no shortage of transport data tools. There are maps, dashboards, databases, and now AI chatbots — ADB's Asian Transport Outlook is exploring one ("Transport Genie"), a CKAN-based chatbot is being deployed on open data portals, and TDC's equivalent is under development. What none of them do is bridge across data types and sources. Each queries a single organisation's data. Nobody builds the bridge.

TGIS creates a data layer above these tools — one that could make TDC's chatbot better, not substitute for it. TDC is the bedrock: the shared data catalogue that the community maintains. TGIS adds cross-source intelligence on top, letting any agent (including TDC's own) pull from multiple sources in a single query.

The hard part is bridging data that was never meant to talk to each other:

  • Policy documents + GIS data: A question like "what road investments are planned in regions with the highest climate vulnerability?" requires combining narrative policy documents with spatial infrastructure data. Today that takes a specialist weeks. An AI agent could synthesise it in minutes.
  • Financial data + infrastructure data: Comparing cost-per-kilometre of tarred road across countries means joining IATI/DAC spending data with road network inventories. Nobody does this routinely.
  • Real-time monitoring + static indicators: Overlaying port disruption alerts (PortWatch) with trade dependency indicators (World Bank) gives early warning capability that neither dataset provides alone.

The principle: show that data which was never designed to be connected can be connected through AI, and that the combination yields answers no single platform can deliver.

Governance and Ownership

TGIS will be led and developed by RIDE, with support from the Frontier Tech Hub, in partnership with multilateral development banks (ADB, AfDB, EBRD, EIB, CAF, IDB), UN agencies (UNECE, UNDESA), TDC, SLOCAT, and other organisations. The vision is a system that is inclusive from the start, drawing on data and expertise from across the sector.

The relationship with TDC is particularly important. TDC serves as the foundational data commons — the shared catalogue of what transport data exists globally. TGIS does not duplicate or compete with TDC. Instead, TGIS builds an AI service layer on top that makes TDC's datasets (and data from other platforms) discoverable and queryable by AI agents. If TDC is the library catalogue, TGIS is the librarian that can read across all the books and answer questions that span multiple sources.

Our Contribution

Our role is the how. The domain expertise lives with Oxford, UNECE, WRI, UK International Development / FCDO, GIZ, MDBs, country governments and the wider coalition. Our contribution is:

  • AI architecture expertise — how do you make heterogeneous data AI-queryable? How do you combine unstructured text (policy docs) with structured data (indicators) with geospatial (maps)?
  • Data integration patterns — what does it mean to get data "AI-ready"? What are the practical steps from "25 data sources with different APIs" to "one conversational interface"?
  • Proof of concept — demonstrating the art of the possible with working examples
  • Honest brokerage — reality-checking what is actually feasible

We bring a toolkit and a way of working. The sector brings the knowledge, the data, and the users.

The Key Design Questions

1. Who is this for?

Two user archetypes:

  • Senior policymakers in partner governments — not tech-savvy, need plain-language answers to complex questions about transport investment, safety, infrastructure condition
  • Technical staff in road agencies, port authorities, rail authorities — more data-literate but siloed in their mode, currently navigating multiple disconnected platforms

A critical point from the Frontier Tech Hub: behaviour change. Giving people a tool does not mean they will use it. If they do not interrogate data today, a new tool alone will not change that. The system must be designed around how people actually make decisions.

2. Global or local?

Both. A transport minister in Ghana cares about Ghana, not global averages. A UNDESA analyst tracking the Decade needs the global view. The system must work at both scales — a "global-local intelligence system" that lets users zoom to their context while drawing on the full breadth of available data.

3. One mode or multi-modal?

Most users will approach through a single mode (roads, maritime, rail, air). But the real value is in the connections between modes — port capacity affecting road freight costs, rail alternatives reducing road damage, climate vulnerability across networked infrastructure. The interface should allow mode-specific entry points while enabling cross-modal insight.

4. What are the first ten data connections?

For any proof of concept, we need to start narrow and deep rather than broad and shallow. The initial selection should:

  • Cover different transport modes (not all roads)
  • Include different data types (GIS + structured + narrative)
  • Use the most accessible, well-documented sources
  • Demonstrate the principle of cross-source synthesis

From the data access audit, the most integration-ready candidates:

SourceTypeMode CoverageAccess
OPSIS / open-giraGeospatial infrastructure networksMulti-modal (road, rail, air, maritime)3 REST APIs, no auth
Transport Data Commons (TDC)Multiple datasets via single APIMulti-modalCKAN API, emerging
World Bank Open DataIndicators, LPI, spendingCross-cuttingREST, no auth, CC-BY
PortWatch (IMF/Oxford)Maritime trade monitoringMaritime/portsArcGIS REST, no auth
IATI / DACFinancial flows, aid spendingCross-cuttingREST, no auth
ADB Asian Transport OutlookStatistical observatory (450+ indicators, 51 economies)Multi-modalReports, ADB Data API
Africa Transport ObservatoryContinental transport dataMulti-modalWeb portal, limited API
SLOCAT NDC Transport TrackerClimate policy commitments for transportCross-cuttingExcel download
AfDB Data PortalAfrica Information Highway, infrastructure + economic indicatorsCross-cutting (Africa)REST API, open data

With a policy document corpus (RAG) layered on top, this gives us structured data, geospatial data, financial data, climate policy data, and narrative knowledge — spanning Asia-Pacific, Africa, and global sources rather than relying on any single institution.

Two Ways of Working with Geospatial

A distinction that matters for the tool's design:

  1. Querying maps — the user asks a natural language question; the AI agent queries geospatial data in the background and returns a text answer. ("Which East African road corridors have the highest climate risk?")
  2. Showing maps — the user asks a question and the answer IS a map, with the right layers applied. The AI agent does not just interpret spatial data; it presents it visually.

Both are needed. The first is technically more straightforward (text-to-GIS-query). The second requires the system to generate or compose visual outputs, which is harder but often more impactful — sometimes a map with red-and-green corridors says more than a paragraph.

Multilingual Access

TGIS should support simultaneous translation — users query in any language and receive responses in that language. Current LLMs handle this well for major languages. This matters because transport policymakers in partner countries work in French, Spanish, Arabic, Portuguese, and other languages, not just English. Building multilingual support from the start avoids the trap of anglophone-only tools that exclude most of the intended users.

Scope

  • A layer above existing platforms, not a replacement for them
  • An intelligence and planning tool, designed for analysis rather than real-time control
  • A proof of concept — building momentum toward a fuller system
  • AI and integration capability from our side; domain expertise from the sector

Timelines

Near-term (now through March 2026)

  • Landscape analysis and data audit (done)
  • Validate data priorities and fill gaps with domain experts (Oxford, FCDO, UNECE)
  • Build working examples of cross-source data synthesis
  • Aim toward something demonstrable for Transforming Transportation (second week of March 2026)

Medium-term (next financial year, from April 2026)

  • More capacity available for deeper work
  • Move from examples to a coherent proof-of-concept prototype
  • Refine user journeys based on feedback from the February/March events
  • Engage with WRI and other partners on sustained development

Long-term (aligned with the UN Decade, 2026-2035)

  • Position the system as the data backbone of the Decade
  • Expand from 10 to 50+ data sources
  • Build a federated, sustainable platform with proper governance
  • Move from UK International Development seed funding toward institutional sustainability

Open Questions

  • What are the top priority data gaps that partners can help identify?
  • How does the GIZ TDCI AI assistant relate to this — complement or overlap?
  • What does IE Connect's real-time data collection methodology look like, and can it feed in?
  • Which OECD/DAC indicator set is FCDO working to update, and can it inform the taxonomy?
  • What is the right institutional home for something like this long-term?
  • WB Road Safety Calculator: WB have agreed to provide access — what form does that take (API, data tables, embedded tool)?
  • Infrastructure resilience GIS: How do we integrate the GIRI/GMTRA prioritised investment layer into TGIS as a live service rather than academic outputs?
  • TRiP network: How does the UK university network for transport research connect to TGIS's evidence base?

This is a living document. It captures direction, not decisions. Updated as the work evolves.