Metadata-driven spatial data infrastructure
The first GeoAI demos needed one Python function per dataset. The Beta lets metadata decide which data and tools to use, so metadata quality now matters a great deal.
What changed between the PoliRural+ proof of concept and the Beta in how data reaches the AI tools?
The proof of concept hard-coded Python functions for fixed datasets, with metadata hidden in code comments. The Beta relies on explicit metadata and service descriptions, so Raven can select datasets and set up generic tools over them, which makes metadata quality decisive.
- Proof of concept: hard-coded functions; Beta: generic tools set up over described data
- Raven resolves data references and tool contexts for JackDaw
- Standards stack: ISO 19115/19119, Micka, Layman, STAC, OGC API – Records, RO-Crate, I-ADOPT
- Pilots must describe coverage, validity, licences and known limitations
Metadata as infrastructure: from hard-coded functions to Raven
main tellingdepth: standard..technical3 min markdown
The early proof-of-concept demonstrations ran chat flows on hard-coded Python functions, with metadata often tucked into code comments. That was enough to prove the interaction logic, but not to reuse or scale. The second release puts the weight on explicit, higher-quality metadata. This lets the platform move from fixed tool-and-data pairs to generic tools that can run over many datasets (D4.2 §3.2).
Raven
Raven selects the relevant data resources and sets up tools on top of them as needed. Its inputs are catalogue metadata, service descriptions, dataset identifiers, access URLs, spatial descriptors and repository information. Its outputs are discoverable records, publishable services, resolved data references and tool contexts that JackDaw can use (§3.2). In the pilots, Raven let teams register local datasets, state their spatial and temporal validity, and make them available to other tools without manual code changes (§6.3). For the final release, Raven’s metadata should also drive tool selection, access control, provenance tracking and checks of whether a dataset suits a task (§11.1).
The standards stack
| Layer | Standard or tool | Source |
|---|---|---|
| Geographic metadata | ISO 19115 (data), ISO 19119 (services) | D4.1 §6.5 |
| Catalogue and harvesting | Micka: INSPIRE metadata, harvesting via CSW and WMS | D1.1 §3.2 |
| Layer publishing | Layman: WMS and WFS, access control | D1.1 §3.2 |
| Spatio-temporal discovery | STAC, OGC API – Records (from FOCAL) | D4.2 §9.1 |
| Packaging and semantics | RO-Crate with JSON-LD; I-ADOPT variables (from FAIR2Adapt) | D4.2 §9.4 |
What pilots have to provide
D4.2’s first corrective action is better guidance for preparing pilot data. It covers metadata completeness, spatial coverage, temporal coverage, licences and known limitations (§6.4). Without these, the same tool behaves unevenly from one dataset to the next.
Why this is a research result
D4.2 concludes that metadata “has become a core operational element of the platform”. It supports interpretation, tool selection, access management, provenance and AI-assisted workflows, not only catalogue search. Its quality “directly affects the reliability of downstream services”, JackDaw included (§12). The open data layers this applies to, such as Copernicus, are covered in chapter 4.
Hub4Everybody: from project website to evidence infrastructure
another tellingdepth: standard2 min markdown
Hub4Everybody grew out of the PoliRural Hub, whose user portal moved from Liferay to Wagtail CMS to make content easier to manage. D1.1 describes it as a generic framework that is “now the base for many new solutions ranging from Web pages to commercial platforms” (D1.1 §2).
Map management built in
D1.1 names three components (§3.2):
- Micka, a metadata catalogue and search engine that handles INSPIRE metadata and harvests from CSW and WMS sources;
- HSLayers NG, a framework for interactive web maps that combine WMS, WFS and vector data;
- Layman, which publishes layers from desktop GIS or the web, with access control and support for OGC standards.
Plan and reality
D4.1 planned the Hub as a universal data repository that would feed JackDaw, use Magpie for data discovery, analyse texts for named entities and policy changes, and add AI to e-learning (§6.1). In the D4.2 Beta, the Hub is the main entry point: a place for communication, publications, documents and service links. It has changed “more in content scope than in platform logic”. One part of the plan is now running: documents added to the PoliRural+ library feed the retrieval layer behind JackDaw, so the Hub is “not only a publication surface, but also part of the evidence infrastructure” (D4.2 §3.1).
The limit is editorial. As the library grows, its value depends on consistent classification, metadata quality and curation. Without them, a bigger repository gets harder to navigate (§3.1).
Reuse elsewhere
BioClima uses the Hub to publish data, methods and training materials. INTERESH can reuse it for soil-health Living Labs. KijaniSpace relies on hybrid deployments, with local instances or adapted portals where cloud access is unreliable (D4.2 §9.2, §9.3, §9.5).
Check yourself: Plugging a local dataset into GeoAI
The Vidzeme Planning Region is building a regional monitoring framework for its Development Programme. The pilot has a spreadsheet of territorial indicators and wants JackDaw to answer questions on it, such as “Which municipalities are falling behind on indicator X since 2022?” What do you do first?
A) Ask a developer to write a dedicated function for this dataset
B) Register the dataset through Raven with complete metadata: spatial and temporal coverage, licence, known limitations
C) Upload the spreadsheet to the Hub4Everybody library so the RAG can read it
D) Search for it with Magpie first
Choose one, then read why it works or where it breaks.
Feedback on each option
- A) That is how the first proof of concept worked, and why it was left behind. One hard-coded function per dataset neither scales nor gets reused (D4.2 §3.2). It works for a demo and breaks at the second dataset.
- B) The Beta route. Raven lets pilots register local datasets, state their spatial and temporal validity, and make them available to other tools without code changes. D4.2 asks pilots for exactly this metadata: coverage, licences and known limitations (§6.3, §6.4). How good these descriptions are decides how well JackDaw answers.
- C) Only partly. Documents in the Hub library feed the retrieval layer behind JackDaw (§3.1), so the text can be quoted. But RAG retrieves text chunks, while indicator analysis, maps and comparisons need the dataset as structured, described data.
- D) Magpie finds what is already in a catalogue. A new local dataset is not there yet, and search cannot make up for missing records (§3.4). It is useful afterwards, for finding comparable layers.
Related
- Builds on: JackDaw, the PoliRural+ GeoAI agent