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 | Buildings, roads, POIs, land use | Global, variable quality | Free | | USGS 3DEP | DEM, LiDAR point clouds | 1m (US), 10m (US) | Free | | Copernicus DEM | Elevation | 30m global | Free | | NLCD | Land cover classification | 30m (US) | Free | | Census TIGER | Boundaries, roads, tracts | US | Free | | Ordnance Survey | Buildings, terrain, addresses | UK | Mixed | | Google Earth Engine | Satellite imagery, derived products | 10m--1km, global | Free (research) | | Mapbox | Vector tiles, satellite | Global | Freemium | | Local government GIS portals | Parcels, zoning, utilities, trees | City-level | Usually free |

2.3 GIS Tools

• QGIS: Free, open-source, full-featured desktop GIS. Plugin ecosystem. Python scripting (PyQGIS). Best for data preparation and analysis before importing to design tools.
• ArcGIS Pro: Industry standard. CityEngine integration. Geodatabase management. Advanced spatial analysis. Expensive license.
• Mapbox: Web-based tiles and APIs. Excellent for interactive maps. Mapbox GL JS for web dashboards.
• Google Earth Engine: Planetary-scale raster analysis. JavaScript/Python API. Best for satellite time-series analysis (vegetation change, urban growth, heat island).

2.4 Grasshopper GIS Plugins

• Elk (free): Imports OSM data (buildings, roads, topography) into Grasshopper. Supports .osm files. Terrain from .img files. Simple but effective for urban context models.
• Heron (free): Imports Shapefiles, raster images, topography. More format support than Elk. GeoTIFF import for terrain. Reprojection built in.
• Meerkat (free): Real-time GIS data streaming. OpenStreetMap tiles. WMS/WMTS service connections.
• Urbano (commercial): Urban mobility analysis. Walkability scoring. Amenity accessibility. Network-based analysis integrated with Grasshopper geometry.
• DeCodingSpaces Toolbox (free): Space syntax, network analysis, urban morphology metrics computed directly on GIS-imported geometry.

2.5 Typical GIS-to-Design Workflows

1. Terrain modeling: Download DEM (GeoTIFF) -> import via Heron -> create mesh surface -> drape site boundary -> cut/fill analysis.
2. Site boundary extraction: Download parcel Shapefile from local GIS portal -> import via Heron -> extract target parcel polygon -> set as design boundary.
3. Context building generation: Download OSM buildings -> import via Elk -> extrude by height attribute (or estimate floors x 3.5m) -> use as solar/wind context.
4. Road network import: OSM road centerlines -> import -> offset for right-of-way widths -> classify by road type.
5. Land use mapping: Zoning Shapefile -> import -> color-code by zone type -> overlay with site boundary -> identify constraints.
6. Walkability analysis: Import road network + POIs -> compute walking distances via network -> generate isochrone maps -> identify underserved areas.

---

3. Sensor Data & IoT

3.1 Sensor Types for Buildings

| Sensor | Measures | Range | Accuracy | Placement | |---|---|---|---|---| | Thermocouple/RTD | Temperature | -200 to +850 C | +/-0.5 C | Duct, room, outdoor | | Capacitive RH | Relative humidity | 0--100% | +/-2% | Room center, avoid direct airflow | | NDIR CO2 | CO2 concentration | 0--5000 ppm | +/-50 ppm | Breathing zone (1.2m height) | | Photodiode/Lux | Illuminance | 0--100,000 lux | +/-5% | Desktop height, avoid direct sun | | PIR | Occupancy (binary) | 5--12m range | N/A | Ceiling, corner mount | | MEMS microphone | Sound level | 30--130 dBA | +/-1.5 dB | Wall, 1.5m height | | Electrochemical | PM2.5, VOC, O3, NO2 | Varies | +/-10--20% | Representative location | | Ultrasonic | Distance/presence | 0.2--6m | +/-1cm | Desk, doorway |

3.2 Building Management Systems (BMS)

Modern BMS systems (Siemens Desigo, Honeywell Niagara, Johnson Controls Metasys, Schneider EcoStruxure) centralize HVAC, lighting, and fire/safety data. Key concepts:

• Points: Individual data values (supply air temp, damper position, setpoint). A typical office building has 5,000--50,000 points.
• Trends: Historical time-series logs of point values. Typical interval: 5--15 minutes.
• Alarms: Threshold-triggered events.
• Schedules: Time-based control programs.

3.3 Data Protocols

• BACnet: Building Automation and Control Networks. The dominant building protocol. Defines object types (analog input, binary output, schedule). IP-based or MS/TP (RS-485). Read via BACnet libraries (BAC0 for Python).
• Modbus: Simple register-based protocol. RTU (serial) or TCP (Ethernet). Each device has a register map. Common for submetering, VFDs.
• MQTT: Lightweight publish/subscribe messaging. Ideal for IoT sensors. Broker-based (Mosquitto, HiveMQ). JSON payloads. Topics structured as building/floor/zone/sensor_type.
• REST API: HTTP-based. Many modern BMS and IoT platforms expose REST endpoints. JSON responses. Polling-based (not real-time without webhooks/WebSockets).

3.4 Time-Series Data Handling

• Storage: InfluxDB (purpose-built time-series DB), TimescaleDB (PostgreSQL extension), or cloud (AWS Timestream, Azure Time Series Insights).
• Sampling rate: Environmental sensors: 1--5 minute intervals. Energy meters: 1--15 minute intervals. Occupancy: 1--5 minute intervals.
• Missing data: Forward-fill for slow-changing variables (temperature). Interpolation for gradual variables. Flag and exclude for fast-changing variables (occupancy).
• Aggregation: Downsample to hourly/daily for long-term storage. Preserve min/max/mean/count.
• Anomaly detection: Z-score method for univariate, Isolation Forest for multivariate. Flag sensor drift (gradual offset), sensor failure (flatline or NaN), and impossible values (negative CO2).

3.5 Digital Twin Sensor Integration

A digital twin is a live 3D model synchronized with real-time sensor data. Architecture:

[Physical Building]
    |
    v
[Sensors + BMS] -- BACnet, Modbus, MQTT
    |
    v
[Data Ingestion Layer] -- Node-RED, Apache Kafka, custom ETL
    |
    v
[Time-Series Database] -- InfluxDB, TimescaleDB
    |
    v
[API Layer] -- REST/GraphQL endpoints
    |
    v
[3D Visualization] -- Unity/Unreal, Three.js, Forge Viewer
    |
    v
[Digital Twin Dashboard] -- color-coded zones, real-time charts, alerts

Sensor data maps to 3D model via spatial identifiers (room ID, zone ID, floor number). Color gradients on room surfaces represent temperature, CO2, occupancy density. Historical playback enables pattern discovery.

---

4. Occupancy Analytics

4.1 Sensing Technologies

| Technology | Accuracy | Granularity | Privacy Impact | Cost | |---|---|---|---|---| | PIR sensors | 85--90% (binary only) | Room-level, binary | Low | Low | | WiFi probe requests | 70--80% (counting) | Zone-level, count + dwell | Medium--High | Low (uses existing infra) | | Bluetooth beacons | 80--90% | Zone-level, individual tracking | High | Medium | | Camera + AI counting | 95%+ | Entry-level, count + direction | High (even anonymized) | Medium--High | | Badge/access card | 99% (entry only, no exit) | Door-level, individual | Medium | Low (uses existing infra) | | Desk sensors (ultrasonic/PIR) | 95%+ | Desk-level, binary | Low | Medium | | CO2-based estimation | 60--75% | Room-level, count estimate | None | Low | | LiDAR people counting | 95%+ | Entry-level, count + height | Low--Medium | High |

4.2 Occupancy Density Mapping

Convert raw sensor counts to spatial density:

1. Assign sensors to spatial zones (rooms, departments, floors).
2. Compute occupancy rate: actualcount / designcapacity.
3. Aggregate over time: peak (95th percentile), typical (median), average (mean).
4. Visualize as heat map overlay on floor plan.

Key metrics:

• Utilization rate: Hours occupied / total available hours (a room used 4 of 8 workday hours = 50% utilization).
• Peak occupancy: Maximum simultaneous occupants (drives HVAC sizing).
• Diversity factor: Peak of whole building / sum of individual room peaks (typically 0.6--0.8).
• Frequency: How often a space is used per week.

4.3 Design Implications of Occupancy Data

• Right-sizing: If meeting rooms average 30% utilization, reduce count and add more informal collaboration zones.
• HVAC zoning: High-variability zones need VAV with fast response. Consistently occupied zones can use simpler systems.
• Circulation sizing: Peak flow data from entry sensors drives corridor width and elevator sizing.
• Flexible programming: Low-utilization spaces become candidates for multi-use or hot-desking.
• Post-occupancy feedback: Compare design assumptions (occupancy schedules in energy models) with reality.

---

5. Space Syntax

5.1 Core Concepts

Space syntax, developed by Bill Hillier and Julienne Hanson at UCL in the 1980s, quantifies the configurational properties of spatial networks. It reveals how the structure of space itself shapes movement, encounter, and social outcomes.

Axial map: The minimum set of longest straight lines (axial lines) that pass through all convex spaces and make all connections in a spatial system. Constructed by drawing lines of sight and access.

Key measures (computed on the axial graph where nodes = axial lines, edges = intersections):

| Measure | Definition | Interpretation | |---|---|---| | Connectivity | Number of lines directly intersecting a given line | Local accessibility | | Depth | Shortest topological distance from one line to another | Remoteness | | Mean Depth | Average depth from a line to all other lines | Overall accessibility | | Integration (Rn) | Reciprocal of Relative Asymmetry (normalized mean depth) | Global accessibility; high = well-connected | | Integration (R3) | Integration computed within topological radius 3 | Local accessibility within 3 steps | | Choice (Rn) | Number of shortest paths passing through a line | Through-movement potential; high = likely route |

5.2 Axial Analysis

Global integration formula:

RA = 2(MD - 1) / (k - 2)

Where MD = mean depth, k = number of lines in the system.

Real Relative Asymmetry (normalized for system size):

RRA = RA / D_k

Where D_k is the diamond value for a graph of k nodes.

Integration = 1 / RRA. Higher values = more integrated (accessible).

Choice counts how many shortest paths between all pairs of nodes pass through a given node. Normalized choice (NACH) enables cross-system

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Amanbh997
• Source: Amanbh997/Claude-skills-for-Computational-Designers
• License: MIT

Install and usage instructions live in the source repository linked above.