The problem
Geographic data lives across separate portals, formats, geographies, time ranges, and update cadences. Even when the facts are public, the working surface is fragmented.
About
Geographic data stays useful
when it stays organized.
Public data is scattered, hard to compare, and easy to lose when an agency changes course. DaedalMap keeps maintained packs over source-documented datasets so the same geographic truth stays usable across map, research, live watch, and agent access.
The solution
DaedalMap organizes maintained packs that are easier to compare, cross- reference, and inspect. Provenance, coverage, and packaging stay attached to the data instead of getting lost in the workflow.
Preservation matters
Some important datasets drift, break, or disappear. DaedalMap keeps preserved and maintained access paths where possible so useful public data does not vanish when a publisher stops caring about distribution.
One truth, four surfaces
Explore, Ops, Research, and Agents read from the same maintained pack layer. The access pattern changes. The runtime truth does not.
Why this exists
Useful public data should not require a full GIS rebuild every time.
At the core, DaedalMap solves a simple problem: data is scattered, hard to compare, and easy to lose. Different sources use different boundaries, different time conventions, different update habits, and different download paths.
DaedalMap organizes that terrain into maintained packs. Packs group usable datasets with shared geography, metadata, provenance, and runtime behavior so they can be queried, compared, and reused without rebuilding the joins every time.
The same maintained truth then shows up through four access patterns: map exploration, live watch, bounded research, and agent access. The long-term direction also includes easier download and self-host paths so teams can keep their own copies and run the same engine on their own infrastructure. That preservation and handoff path is still being tightened.
Built by
DaedalMap is built by Bryan Hellard. Background in robotics and systems engineering, focused on disaster impacts, response, and making geographic data accessible for decision-making.
Vice chair of STAR-TIDES, the global resilience and disaster-response network coordinated through George Mason University. Sibling project Disaster Clippy runs on the same distribution architecture, adding a conversational search layer over disaster-prep guides alongside DaedalMap's data layer.
Substack · LinkedIn · GitHub · X / Twitter · contact@daedalmap.com
One maintained pack layer, multiple access patterns
Disasters, demographics, economics, climate, and risk stay queryable in one system. The same underlying pack layer supports map exploration, Research workspaces, operational watch, and agent calls.
Open the map, load a corpus, watch a feed, or connect an agent. The access pattern changes. The maintained truth does not.
Discontinued Data
Public datasets DaedalMap hosts after their publishers stopped distributing them. Mirror provenance and drift notes per source, including the CIA World Factbook, FEMA Future NRI, and CEJST.
Current coverage
The full source map. Which families are in play, what they cover, and which packs ship on the live MCP catalog.
What stays open
- Open runtime engine
- Open schema and data model
- Hosted app access path
- Bring-your-own-data compatibility
- Visibility under the hood
What the maintained layer covers
- Converter maintenance and normalization
- Pack QA, metadata, and packaging
- Freshness, update cadence, and support
- Live data collectors
- Mirror discipline for preserved sources
- Hosted convenience and broader access paths
How access splits
One engine. Several access lanes.
The public GitHub repo is the open engine. The data layer is governed pack by pack by upstream source terms. The maintained work sits in the middle: normalization, preservation, metadata, crosswalks, QA, and packaging.
On top of that maintained layer, DaedalMap offers different access patterns. The hosted app is the easiest way in. Ops and agent access are paid hosted lanes because live collectors, machine-query infrastructure, and support all cost money to run. The local runtime is the controlled handoff for researchers and teams who need the same engine with more local control.
Run it yourself
Request the local research runtime.
Use the hosted app if you want the fastest path in. Use GitHub if you want the raw manual path. Request the local runtime when you want the same engine on your own machine with a guided research-oriented setup, larger local control, and the option to use your own LLM keys.