/data-driven-design

title: Data-Driven Design
description: GIS integration, sensor data, occupancy analytics, space syntax analysis, urban data analytics, climate data processing, and API data sources for evidence-based AEC computational design
version: 1.0.0
tags: [data-driven, GIS, sensors, IoT, space-syntax, occupancy, analytics, API, climate-data, evidence-based]
auto_activate: true
user_invocable: true
invocation: /data-driven-design

Data-Driven Design

This skill provides comprehensive guidance on integrating quantitative data into every stage of the architectural and urban design process. It covers geospatial data, environmental sensing, occupancy analytics, spatial network analysis, climate processing, urban datasets, and the APIs that serve them. The goal is to replace intuition-only design with evidence-based reasoning while preserving creative agency.

---

1. Data-Driven Design Philosophy

1.1 Evidence-Based vs. Intuition-Based Design

Traditional design relies heavily on precedent, aesthetic judgment, and professional intuition. These are valuable but unverifiable. Evidence-based design augments intuition with measurable inputs:

| Dimension | Intuition-Based | Evidence-Based | |---|---|---| | Site analysis | Walkthrough, photos | GIS layers, sensor grids, satellite imagery | | Program sizing | Rules of thumb | Occupancy analytics, utilization studies | | Circulation | Designer judgment | Space syntax integration/choice values | | Orientation | Sun path intuition | EPW-parsed radiation/temperature analysis | | Massing | Formal exploration | Daylight/energy simulation feedback loops | | Post-occupancy | Anecdotal feedback | Sensor-driven POE dashboards |

Evidence-based design does not eliminate intuition. It provides a quantitative substrate on which creative decisions rest, making design rationale transparent, defensible, and reproducible.

1.2 Data as Design Input, Not Just Validation

The critical shift: data must enter the design process at the very beginning, not after decisions are made. In the traditional workflow, simulation runs after design is locked, serving only to confirm or reject. In a data-driven workflow:

1. **Pre-design data collection** -- site climate, demographics, transport, land use, environmental constraints 2. **Data-informed brief** -- program areas derived from utilization studies, not guesses 3. **Generative exploration** -- design options generated with data constraints embedded 4. **Continuous feedback** -- every design iteration evaluated against data-derived KPIs 5. **Post-occupancy loop** -- sensor data feeds back into future project templates

1.3 The Data-to-Design Pipeline

[Raw Data Sources]
    |
    v
[Acquisition] -- APIs, sensors, manual surveys, open data portals
    |
    v
[Cleaning & Validation] -- missing value handling, outlier detection, CRS alignment
    |
    v
[Processing & Analysis] -- statistical summaries, spatial analysis, temporal patterns
    |
    v
[Translation to Design Parameters] -- the critical creative step
    |
    v
[Parametric Model Integration] -- Grasshopper data trees, Dynamo lists, scripted geometry
    |
    v
[Design Evaluation] -- simulation, scoring, multi-criteria comparison
    |
    v
[Visualization & Communication] -- dashboards, reports, AR overlays

1.4 Ethical Considerations in Data Use

• **Bias recognition**: Census data reflects historical segregation. Transport data skews toward car owners. WiFi tracking data skews toward smartphone owners. Understand what populations are invisible in your dataset.
• **Consent and transparency**: Occupancy data collection must be disclosed to building users. GDPR, CCPA, and equivalent regulations apply.
• **Algorithmic fairness**: When data drives automated design decisions (e.g., park placement), audit for equitable outcomes across demographics.
• **Data provenance**: Document the source, date, methodology, and known limitations of every dataset used in design decisions.

1.5 Privacy and Anonymization

• Aggregate occupancy data to zones and time windows (minimum 15-minute bins, minimum 5-person zones) to prevent individual identification.
• Strip MAC addresses, device IDs, and personal identifiers before storage.
• Use k-anonymity (k >= 5) for any published spatial movement data.
• Separate data collection infrastructure from building access control systems.
• Establish data retention policies: raw sensor data purged after 12 months, aggregated statistics retained indefinitely.

---

2. GIS Integration

2.1 GIS Fundamentals for Designers

**Coordinate Reference Systems (CRS)**:

• **Geographic CRS**: Latitude/longitude on an ellipsoid (WGS84 = EPSG:4326). Units: degrees. Not suitable for distance/area measurement.
• **Projected CRS**: Flat plane projection. UTM zones (EPSG:326xx for north, 327xx for south), State Plane (US), British National Grid. Units: meters or feet. Required for accurate geometric operations.
• **Rule**: Always know your CRS. Always reproject to a projected CRS before measuring distances or areas.

**Projections**:

• **Conformal** (preserve angles): Mercator, Transverse Mercator, Lambert Conformal Conic. Best for navigation and local design.
• **Equal-area** (preserve area): Albers, Mollweide. Best for thematic mapping at continental/global scale.
• **Equidistant** (preserve distance along certain lines): Azimuthal Equidistant.
• For site-scale AEC work, UTM or local State Plane projections are almost always appropriate.

**Vector vs. Raster**:

• **Vector**: Points (trees, sensors), lines (roads, utilities), polygons (parcels, buildings). Precise geometry. Attribute tables. Formats: Shapefile, GeoJSON, GeoPackage, KML.
• **Raster**: Grid of pixels. Each pixel holds a value (elevation, temperature, land cover class). Formats: GeoTIFF, IMG, ASCII Grid. Resolution matters: 1m DEM vs. 30m DEM.

2.2 Key GIS Data Sources

| Source | Data Types | Resolution/Coverage | Cost | |---|---|---|---| | OpenStreetMap