About

Built to make geographic data
usable at human speed.

DaedalMap is an open geographic query engine with a map-first interface. Ask a place-based question, get a usable answer, and keep the path from public demo to serious analyst workflows within the same system.

What it is

DaedalMap is designed for people who need answers about places, regions, and events without having to assemble a GIS workflow first.

What stays open

The engine, schema model, and demo path are meant to stay open. You should be able to understand how the system works and bring your own compatible data if you want to run the pipeline yourself.

What the paid layer is

The commercial value is not ownership of public data. It is the maintained operating layer: source curation, converter maintenance, schema cleanup, metadata, QA, packaging, freshness, and support.

Who it is for

DaedalMap is for people who need geographic answers but do not want to live inside shapefiles, disconnected portals, manual joins, or a custom GIS stack just to answer one practical question.

Analysts and researchers

Use the hosted app to move faster across disaster, demographic, economic, and risk questions without building a fresh workflow for every domain.

Network and member users

Get a working map product with maintained data instead of just a directory of sources or a promise that the tooling exists somewhere in the repo.

Teams with private workflows

Start with the hosted surface, then move into local or self-hosted use when privacy, speed, or offline operation matters more than convenience.

Technical users

Keep the option to inspect the engine, understand the schema model, and bring your own compatible data instead of getting trapped inside a sealed platform.

How it works

Public data is often technically available but operationally fragmented. DaedalMap is built around a simple split: keep the engine open, keep the schemas understandable, keep sample paths visible, and make the paid value the work required to turn messy source material into reliable, ready-to-use packs.

The hosted app is the easiest entry point. A user opens the map, asks a geographic question, and the runtime uses the active catalog of compatible packs to answer it. That can start with a public demo path and expand later into broader access, maintained pack libraries, premium workflows, or local/private installs.

That keeps the business model honest. Users are not paying for a legal fiction about raw data ownership. They are paying for packaging, maintenance, current releases, and a faster path from question to answer.

1. Ask in plain language

The interface is map-first and query-first. The point is to let someone ask about risk, disasters, demographics, infrastructure, or change over time without starting from raw files.

2. Move across domains

The same system can work across multiple kinds of geographic data instead of forcing every question into a separate source, portal, or workflow.

3. Use maintained packs

Maintained packs are the operational product: cleaned, normalized, versioned, QA-tested releases that are ready to run instead of raw source material that still needs engineering work.

4. Keep one product model

The same engine can support public hosted use, broader account access, local analyst installs, and self-hosted deployments. The trust model changes. The product logic does not.

Open

What stays public

  • Open runtime engine
  • Open schema and data model
  • Sample and demo path
  • Bring-your-own-data compatibility
  • Visibility into how the system works

Maintained

What the paid layer covers

  • Source discovery and curation
  • Converter maintenance and normalization
  • Pack QA, metadata, and packaging
  • Freshness, update cadence, and support
  • Hosted convenience and broader access paths

Hosted and local

The hosted app at daedalmap.io is the easiest way to see the system working. Over time that same model can extend into member access, analyst installs, and self-hosted deployments for teams that need more privacy, more control, or offline operation.

The goal is one engine, one pack model, and one clear path from demo use to serious production use.