February

Data That Lives Everywhere, Visible in One Place

Spatial data is everywhere. Government portals publish flood zones and transport networks. Research institutions share climate observations and biodiversity surveys. Cities publish planning boundaries and air quality readings. International organisations maintain global datasets on health, agriculture, and infrastructure. It’s all out there — thousands of datasets, on hundreds of portals, in dozens of formats.

The problem isn’t availability. It’s fragmentation. Every portal is its own silo. The data inside one can’t see the data inside another. If you want to combine datasets from two different sources — say, overlay coastal erosion data from a research institute onto a government land-use map — you’re downloading files, wrestling with coordinate systems, converting formats, and loading everything into specialist GIS software. The skill required to combine public data is wildly disproportionate to the skill required to understand it once it’s combined.

February removes that barrier. Point it at any open data portal — a national catalogue, a city portal, a research repository, anything that speaks CKAN or DCAT — and it finds every mappable dataset, classifies the formats, checks which URLs actually work, and puts everything on one interactive map. Load a second portal and its datasets appear alongside the first. A third. A fourth. No integration work. No format conversion. No downloads.

But finding data is only half the problem. The other half is doing something with it together. February is built around sharing and collaboration from the ground up. Save your map as a link — not a screenshot, but a live view of the latest data from every source you’ve loaded, with your layer choices and your annotations. Send it to a colleague. They see what you see. They can fork your map, add their own layers, and share that. A team can work on the same map simultaneously, building a shared spatial picture from sources none of them could have combined alone.

February doesn’t store data. It brokers access. The data stays where it lives — on the portals, in the repositories, behind the APIs. February makes it visible, explorable, and shareable. One URL in, every mappable dataset out. Then share what you find.

Every Map, One Table

Imagine dozens of organisations each have a drawer full of maps. The environment agency has flood maps. The transport authority has road maps. A university research group has maps of soil quality. A city council has maps of cycle lanes and planning zones. An international body has maps of satellite-observed land cover.

Every drawer is in a different building. Every map uses a different scale. There’s no master index. If you want to see whether a proposed cycle lane runs through a flood zone with poor soil drainage, you’d need to visit three buildings, find the right drawers, photocopy the maps, and line them up on a lightbox. You’d need to know which buildings exist, which drawers to open, and how to align maps drawn at different scales.

That’s how open data works today. The maps exist. Combining them is a specialist job.

February goes to every building, finds every map, puts them all on the same table at the same scale, and lets you point at any spot and see everything that’s been mapped there. You don’t need to know where the drawers are. You don’t need to understand map scales or coordinate systems.

And when you find something interesting, you share a link. Your colleague sees exactly the same maps — live, current, from every source — without visiting any buildings themselves. They can add their own maps to the table. That’s February: find, explore, share.

Six Steps from Portal to Shared Map

1. Connect

Enter a data portal URL — any CKAN or DCAT-compatible catalogue. A national portal, a city open data site, a research data repository. February hits the API, walks every dataset, and classifies each resource by format.

2. Classify

GeoJSON, WMS, WFS, KML, Shapefile, CSV with coordinates, ArcGIS Feature Services. Each resource is tagged by format and health-checked. Broken URLs are flagged before you see them. Coordinate systems are detected and reprojected automatically — no configuration needed regardless of source.

3. Browse

The legend groups every projectable dataset by publishing organisation. Search narrows by keyword. Format pills filter by type. Broken links are greyed out. You see what the portal actually contains, spatially, at a glance. Connect a second portal — its datasets appear alongside the first.

4. Explore

Toggle checkboxes to load layers onto the map. Geometry is auto-detected — polygons get fills, lines get strokes, points get markers. Change colours and symbols to tell layers apart. Combine datasets from different portals, different organisations, different countries on one map.

5. Discover

SPARQL-powered discovery. Click any point on the map to find datasets whose coverage intersects that location — including datasets from portals you haven’t loaded yet. Discovery extends beyond what you’ve crawled into the wider linked data web.

6. Share and Collaborate

Save your map state to a short URL — every portal, every active layer, your viewport, your styles. Choose your sharing model: read-only snapshots for reports and presentations, fork-on-edit so recipients can build on your work without changing your original, or fully collaborative maps where a team works on the same view together. Staleness detection warns if source data has changed since you shared.

Real Problems, Visible Answers

Environmental investigation

A journalist wants to check whether bathing beaches sit near sewage discharge points. They load the national data portal, toggle on water quality monitoring and wastewater discharge layers. Two datasets from two different agencies, one map. The proximity is immediately visible. No specialist software, no Freedom of Information request — the data was always public, just never shown together. The journalist shares the map link in their article. Readers see live data, not a static image.

Cross-border research

A team studying water quality across a river catchment that crosses a national border loads two countries’ data portals into February simultaneously. Datasets from both jurisdictions appear on the same map, in the same coordinate system. River monitoring points that were invisible on separate portals become a continuous network. The team shares a collaborative map — researchers in both countries add layers from their own institutional repositories. A single shared view of a cross-border environmental picture emerges from data that was never designed to be combined.

Teaching and public engagement

A university lecturer teaching urban planning loads the city’s open data portal into February. Students can see planning zones, transport routes, green spaces, and air quality monitoring stations on one map. They fork the lecturer’s base map, add their own analysis layers, and submit their coursework as a shareable link. A community group uses the same approach — loading their local portal and sharing annotated maps at a public consultation, turning abstract data into visible evidence.

Portal audit and data quality

A data officer loads their own organisation’s portal into February to see what it actually contains geospatially. The broken link indicators immediately flag dead URLs they didn’t know about. The format pills reveal that most of their spatial data is locked in formats that non-specialist users can’t open. The legend shows three departments publishing overlapping datasets for the same area. February becomes a diagnostic tool — showing not just what the portal has, but what’s actually usable and what needs fixing.

Under the Bonnet

Portal support

Any CKAN-compatible portal (Action API v3) or DCAT-AP endpoint. Tested against national, regional, city, and institutional portals across Europe. Also supports static DCAT-AP RDF feeds and GeoSPARQL endpoints for linked data discovery.

Geospatial formats

GeoJSON (native), WMS/WFS (proxied from source), KML/KMZ (converted on the fly), Shapefile (extracted and reprojected), CSV with coordinates (auto-detected), ArcGIS Feature Services (queried directly). Coordinate systems detected and reprojected automatically via EPSG lookup.

Architecture

Django backend, PostgreSQL + PostGIS. MapLibre GL JS frontend with vector tiles and client-side rendering. Protomaps self-hosted basemap tiles — no third-party tile service dependency. Server-side format conversion and proxying solves CORS and format fragmentation for the end user.

Discovery

SPARQL-powered spatial discovery via GeoSPARQL endpoint. Click-to-discover finds datasets by spatial intersection, including from catalogues not yet crawled. Discovery layer is independent of the portal crawl — it queries enriched linked data.

Sharing and collaboration

URL-encoded map state: selected portals, active layers, viewport, styles. Three sharing modes: read-only snapshot, fork-on-edit, collaborative. Staleness detection compares current source metadata against snapshot timestamp. No user accounts required — session-based uploads, link-based sharing.

Security

SSRF protection on all outbound requests (blocks private IP ranges, metadata endpoints). CSP headers. GeoJSON input sanitisation. Input validation on all user-supplied URLs and file uploads.

Deployment

Docker + docker-compose. Django, PostgreSQL + PostGIS, self-hosted tile server. Self-hostable. Open source, licence TBC.