Vulture and MapWhiteboard
One tool works on your own inbox, the other on a map that a whole workshop edits at once. What each really does, and how mature it is.
How do Vulture and MapWhiteboard differ in purpose and maturity?
Vulture is a personal AI sandbox: forwarded e-mails and crawled web pages go into a private collection you can question (Vidzeme uses it for policy monitoring); in the Beta it has become less central. MapWhiteboard is a shared map with live cursors and features; a simplified instance is deployed and it supports pilot discussions about boundaries, corridors and land use.
- Vulture: forward-to-ingest, private Qdrant collection, GPT-4o answers, URL crawling
- The Vidzeme Planning Region uses Vulture to track policy developments
- MapWhiteboard: OpenLayers and HSLayers-NG with a WebSocket API; rated TRL 7 in D4.1
- Monaghan's technical pilot TP1 pairs MapWhiteboard with action-foresight and system dynamics
Vulture and MapWhiteboard: a private sandbox and a shared map
main tellingdepth: standard3 min markdown
These two tools have opposite jobs. Vulture is a personal sandbox for AI experiments on your own material. MapWhiteboard is a shared map where a group works on the same view at the same time.
Vulture: a sandbox, not a core service
Vulture was built for user needs identified in the WP3 buddy exercises (D4.1 §6.4). Users forward e-mails to a dedicated address, with PDFs, web clippings or WhatsApp messages attached. Forwarding is a deliberate act, which D4.1 links to GDPR compliance. Each item lands in a private collection that only that user can see. It is split into chunks and embedded in a Qdrant vector database, and the user can then ask questions in plain language; GPT-4o writes the answer from the retrieved context. Users can also register URLs for Vulture to crawl for topics they care about.
Pilot use: in the Latvian pilot, the Vidzeme Planning Region uses Vulture to monitor and analyse policy developments (D4.1 §6.4).
Status: an alpha in D4.1. In the Beta it has “remained largely stable and has become less central than originally expected”, partly because tools such as OpenClaw and more integrated AI workflows elsewhere took over some of its role. Its outputs are provisional and lack the reproducibility and provenance guarantees of the core services. D4.2 therefore plans selective maintenance: functions that prove useful move into structured platform services (D4.2 §3.5).
MapWhiteboard: working together on one map
D4.1 compares MapWhiteboard to Miro and Figma, applied to maps. It lists pre-defined maps with editable layers, GeoJSON upload and download, WMS layers, shared cursors, simultaneous editing, user-created layers and publishing of features through web services. The tool is built on OpenLayers and HSLayers-NG with a WebSocket API, and D4.1 rates it TRL 7 (D4.1 §6.9).
Status: for the Beta, a new simplified instance has been developed and deployed. It exchanges cursors between OpenLayers maps and features between vector layers. That covers basic shared navigation and shared objects, but it is not yet a full participatory planning suite with moderation and saved annotations (D4.2 §3.8).
Pilot use: MapWhiteboard supported collaborative spatial interpretation wherever pilots had to discuss boundaries, corridors, land use, infrastructure or local assets (D4.2 §6.3). In County Monaghan, technical pilot TP1 combines it with action-foresight and system dynamics to define and implement the rural-urban RAP (project fact sheet).
D4.2 wants MapWhiteboard and the MAA tool built into RAP and foresight workflows instead of running as separate applications (§11.1).
How-to: Using Vulture · Running a MapWhiteboard session.
How to use Vulture: forward, ask, crawl
another tellingexample world: latviadepth: intro..standard2 min markdown
When to use it: you receive a steady stream of calls, newsletters and policy updates and want to ask questions across all of it, or to keep watch on a few web pages.
What you need
- The alpha at jackdaw.avinet.no/vulture (D4.1 §6.4).
- One or more e-mail accounts you forward from. A user profile is created automatically at first use, and several addresses can belong to one profile.
Steps
- Forward content to Vulture’s dedicated address, by hand or with an automatic rule: e-mails with attachments, PDFs, web clippings or WhatsApp messages from any device or e-mail client.
- Decide each time what goes in. Forwarding is deliberate by design; D4.1 ties this to GDPR compliance and data security.
- Let it index. Each item is validated, analysed for context, chunked and embedded into your private collection in a Qdrant vector database. Only you can access it.
- Ask in plain language. Vulture retrieves the most similar chunks, and GPT-4o writes the answer from them. D4.1’s examples: tracking events and deadlines, identifying reports, finding funding opportunities and policy updates.
- Register URLs to crawl and define the questions or topics you care about; Vulture extracts the relevant information from the linked pages.
- Refine your prompts. D7.4’s guidance: the more you use and refine your prompts, the more precise the results become.
What you get
A self-expanding personal RAG over your own material: answers, summaries and extracted information. D4.2 calls such outputs provisional and exploratory, not formal platform evidence (§3.5).
Pilot use
In the Latvian pilot, the Vidzeme Planning Region uses Vulture’s URL crawling and targeted extraction to monitor and analyse policy developments (D4.1 §6.4).
Watch out
- It is a sandbox: lighter integration, weaker guarantees on reproducibility, provenance and long-term maintenance (D4.2 §3.5).
- In the Beta it has become less central than planned; tools such as OpenClaw and more integrated workflows took over parts of its role. Expect selective maintenance, not new features.
- Before an answer goes into a RAP or a brief, find the original e-mail or page and cite that.
A shared, auditable evidence base is the job of the Advisor, not Vulture.
How to run a MapWhiteboard session with stakeholders
another tellingexample world: italy|slovakiadepth: intro..standard2 min markdown
When to use it: a meeting has to agree on something that lives on a map, such as a boundary, a corridor, a land-use conflict or local assets (D4.2 §6.3).
What you need
- A session set up for you. The pack gives no public address; MapWhiteboard runs in the web-mapping environment of the platform, and restricted sessions use its shared authentication (D4.2 §3.8). Ask your pilot’s technical partner.
- A base map and the layers you want to discuss; GeoJSON data if you bring your own.
- One facilitator who keeps notes.
Steps
- Open the shared map. Pre-defined maps combine base layers with editable layers (D4.1 §6.9).
- Bring everyone in. Each connected session shows the others’ cursors live (D4.2 §3.8).
- Navigate together to the place in question and let people point rather than describe.
- Draw on the shared layer. Features drawn on a vector layer are exchanged between sessions, so each person sees the others’ lines and areas (D4.2 §3.8).
- Add context, where your instance supports it. D4.1 lists WMS layers, GeoJSON upload, user-created editable layers and simultaneous editing of attributes (§6.9).
- Secure the result. Download the drawn features as GeoJSON or publish them through web services if available (D4.1 §6.9); otherwise capture them before the session ends.
What you get
A shared visual workspace: synchronised cursors, exchanged features and a common map the group has inspected together (D4.2 §3.8).
Pilot use
- Apulia (Italy): collaborative map work and vector drawing supported municipal dialogue on local territorial development and community engagement (D4.2 Table 7).
- Slovakia: MapWhiteboard was part of the set-up for participatory foresight and defining the rural-urban boundary (D4.2 Table 7).
Watch out
- The Beta is a new simplified instance. It covers shared navigation and shared objects, not a participatory planning suite with workflow, moderation or persistent annotations (D4.2 §3.8).
- The feature list in D4.1 (TRL 7) describes the earlier, fuller tool. Check what your instance offers before the workshop.
- D4.2 wants MapWhiteboard linked to the MAA tool, the Hub and the advisory services; until then, record who said what in the MAA tool or your minutes.
Related
- Builds on: The PoliRural+ tool ecosystem
Sources
- D4.2 PoliRuralPlus Platform Beta, §3.5 Vulture productivity sandbox; §3.8 MapWhiteboard collaborative mapping; §6.3 Usability, performance and functional observations; §11.1 Remaining development priorities. PDF
- D4.1 PoliRuralPlus platform design, §6.4 Vulture; §6.9 MapWhiteboard Evolution. PDF
- PoliRural+ public fact sheet (Grant Agreement facts), technical pilot TP1. poliruralplus.eu
- D7.4 Exploitation plans and business models, edition 1, How to Use VULTURE. PDF