# Swiss Dwellings v3.0.0 — findings

Research date: 2026-10-18. Purpose: extract evidence for source-layout replication and original apartment generation. All local outputs are in this folder; source CSVs remain unchanged. This is the apartment dataset, separate from swissBUILDINGS3D.

## What the data supports

This is a useful library of semantic 2D apartment layouts, fixtures, openings, room-level simulations and building context. It is suitable for building conditional geometric priors and source exemplars. It is not a representative Swiss housing survey, a building-code manual or construction documentation. No generator was trained or validated in this study.

## Publisher description, distinguished from our measurements

The [Zenodo record](https://zenodo.org/records/7788422) describes plans supplied by Archilyse commercial clients, manual quality assurance, approximately 45,000 apartments and a 5% maximum apartment-area deviation with a reported median deviation of 1.2%. Those accuracy figures are publisher claims; we did not compare plans with surveys or buildings. Site-local coordinates are in metres, +x east/+y north; elevation is relative to a building terrain baseline. Many heights are defaults. The metadata lists CC BY 4.0: retain attribution, the versioned DOI, license link and notices of modifications when reusing it.

The live record returned HTTP 429 during this run. Its previously saved primary API record and complete description were read locally; `publisher-description-readable.txt` is a readable copy. Metadata says version 3.0.0; its changelog dates that release to 2023-03-31. The record-level publication date is 2022-09-20, so those two dates should not be conflated.

## Complete-file evidence and populations

All four local CSV byte sizes and CRC32 values match their entries in the saved release ZIP central directory. SHA-256s are in `source_manifest.json`. This verifies the extracted members against that directory, not the full ZIP's published MD5.

- `geometries.csv`: **3,255,905 element records**, 13 columns; 522,183 are areas. All polygon records parsed and passed Shapely validity checks; no empty or non-polygon records were found. Individual validity does not establish floor-plan consistency or 3D closure.
- `simulations.csv`: **367,678 rows**, 369 columns = 8 identity/usage fields + 361 measure fields. They comprise 25 layout, 126 sun, 126 view, 12 noise/window-noise and 70 connectivity fields. Every simulation row is labeled RESIDENTIAL.
- `locations.csv`: **3,026 buildings**, 503 columns = building ID + 65 climate + 437 walkshed fields.
- `location_ratings.csv`: **3,025 buildings**, 7 columns = building ID + 6 ratings/segments.

Actual schema counts differ from several prose counts in the description. Use the CSV inventory for implementation. The area geometry covers **1,466 sites, 3,184 buildings, 8,941 plans and 13,905 floors**. There are 45,175 distinct apartment labels among area records and 45,242 site/apartment pairs across all uses. For residential areas there are **44,957 site/apartment keys**, of which **44,947** have at least one simulation. These are defined source groups, not an independently certified dwelling census. The publisher's 45,176 headline is not used as an exact analysis denominator.

## Joins: verified and reusable

The area/simulation join uses `(site_id, building_id, plan_id, floor_id, unit_id, area_id)`, after removing the numeric `.0` suffix from geometry area IDs. Both sides are unique on this key. All 367,678 simulation rows match exactly, with **zero apartment-ID or usage conflicts**. All area IDs are present, but there are **207,147 duplicate area IDs globally**; an `area_id`-only join would multiply records across repeated floors/plans. Apartment IDs also repeat across sites: always keep site ID.

The remaining **154,505 area rows have no simulations**. Much of this is expected scope: shafts, voids and public/commercial areas. Residential omissions also include all 603 TERRACE, 186 GARDEN and 178 PATIO polygons, plus **81 habitable-type area records** across 17 site/apartment keys. Ten residential keys have no simulated rooms. These omissions are explicit; missing rows are never replaced with zero-valued simulations.

Building IDs are unique in both context files and no building ID spans sites in the area census. Context joins preserve row counts. Locations match 474,515 / 522,183 area rows; ratings match 474,496 / 522,183. Missing context remains missing. Full building context stays normalized in `joined_buildings.parquet`; selected room/context fields are in `joined_areas.parquet`.

## Identity problems and reference eligibility

Among matched residential keys, 1,628 span floors, 1,662 span units and 5 span buildings. Some multi-floor groups could be real multi-level apartments; this was not resolved case by case. Single-valued ID columns in `apartment_features.csv` retain the first source value and have accompanying `*_count` fields: do not treat those first values as unambiguous when counts exceed one.

The label `d41d8cd98f00b204e9800998ecf8427e` equals MD5(empty string) and occurs at 11 residential sites. At site 11863 it aggregates **65 units, 7 floors, 219.5 source rooms and 5,730.4 m²**. At site 788 it spans 6 buildings. This strongly suggests a placeholder-label problem; its original encoding intent was not independently confirmed. These 11 keys are quarantined from generation priors, with raw source groups retained in the audit outputs.

The first generator-reference cohort contains **42,242** keys at **1,401 sites**: one building/floor/unit, 20–250 m² net area, source room count 1–7, no unmatched habitable areas and no empty-string-MD5 label. These are deliberate research eligibility limits, not claims that excluded homes are invalid or undesirable.

## Apartment sizes and programs

Across all 44,947 matched source keys, median source net area is **78.9 m²**, with p10–p90 **47.1–113.9 m²**. Medians are more informative here than unfiltered maxima. The generation cohort's conditional distributions are:

- **1.5 source rooms** (n=682): net area 30.5 / 38.3 / 50.9 m²; median corridor share 8.9%.
- **2.0 source rooms** (n=3,904): net area 44.3 / 52.3 / 63.5 m²; median corridor share 11.1%.
- **2.5 source rooms** (n=4,149): net area 49.6 / 61.7 / 74.0 m²; median corridor share 10.1%.
- **3.0 source rooms** (n=7,197): net area 59.5 / 69.3 / 83.2 m²; median corridor share 11.9%.
- **3.5 source rooms** (n=9,464): net area 69.7 / 82.2 / 98.7 m²; median corridor share 12.0%.
- **4.0 source rooms** (n=4,564): net area 74.6 / 87.5 / 104.6 m²; median corridor share 12.6%.
- **4.5 source rooms** (n=7,446): net area 85.8 / 100.7 / 119.7 m²; median corridor share 12.6%.
- **5.0 source rooms** (n=1,208): net area 93.2 / 108.6 / 131.1 m²; median corridor share 13.4%.
- **5.5 source rooms** (n=1,252): net area 106.0 / 124.2 / 149.7 m²; median corridor share 13.5%.

Values above are **p10 / median / p90**, not minimum / target / maximum. The source counts are computed from contributions: ROOM, BEDROOM and LIVING_ROOM contribute 1; LIVING_DINING and KITCHEN_DINING contribute 1.5; kitchens, bathrooms, halls and outdoor labels contribute 0. A 3.5-room source apartment generally has a living/dining zone and two ROOM/BEDROOM slots. A generic ROOM is not a confirmed bedroom. Use the source weights rather than inventing a universal Swiss room-count definition.

For 3.5-room reference apartments (n=9,464), net area is **69.7 / 82.2 / 98.7 m²**, median hall share **12.0%**. Nearly all have one separately segmented KITCHEN and one LIVING_DINING. Separate semantic polygons can still be openly connected. Use the joint source programs in `generation_reference.json`, not independently sampled type counts that may not form a coherent program.

## Room geometry and proportion priors

The following use matched residential area instances, including repeated floors, rather than unique-design weighting. Figures are p10 / median / p90. Area is recomputed from WKT; aspect is long/short side of the minimum rotated enclosing rectangle (MRR); fill is polygon area divided by MRR area.

- **ROOM** (82,618 records): area 10.5 / 14.4 / 19.7 m²; aligned aspect 1.1 / 1.4 / 1.8; median rectangle fill 0.998.
- **BEDROOM** (22,975 records): area 10.6 / 14.0 / 17.1 m²; aligned aspect 1.1 / 1.4 / 1.9; median rectangle fill 1.000.
- **LIVING_ROOM** (8,449 records): area 16.1 / 20.6 / 29.8 m²; aligned aspect 1.1 / 1.3 / 1.7; median rectangle fill 0.981.
- **LIVING_DINING** (24,200 records): area 19.3 / 28.4 / 39.2 m²; aligned aspect 1.1 / 1.4 / 2.2; median rectangle fill 0.870.
- **KITCHEN** (44,075 records): area 5.5 / 8.0 / 12.5 m²; aligned aspect 1.1 / 1.5 / 2.2; median rectangle fill 0.979.
- **BATHROOM** (68,420 records): area 1.8 / 3.8 / 5.6 m²; aligned aspect 1.1 / 1.4 / 2.0; median rectangle fill 0.997.
- **CORRIDOR** (53,374 records): area 2.8 / 7.5 / 15.1 m²; aligned aspect 1.1 / 1.7 / 3.3; median rectangle fill 0.854.
- **BALCONY** (43,078 records): area 2.9 / 7.2 / 16.0 m²; aligned aspect 1.4 / 2.4 / 4.6; median rectangle fill 0.990.
- **LOGGIA** (4,400 records): area 3.3 / 7.8 / 14.3 m²; aligned aspect 1.2 / 2.0 / 3.7; median rectangle fill 0.988.

The source `layout_biggest_rectangle_width` is an inscribed-rectangle measure; our MRR short side is an enclosing measure. They are not interchangeable and neither is a guaranteed passage clearance. For example, median CORRIDOR MRR short side is 2.11 m versus source biggest-rectangle width 1.44 m; an L-shaped hall can have a wide enclosing box and a narrow turn. Bedrooms/generic rooms have median fills around 1.0; living/dining (0.870) and halls (0.854) benefit from nonrectangular shapes. Do not turn every room into a box.

Source window incidence is about 93.9% for BEDROOM, 92.1% for ROOM, 90.6% for LIVING_DINING, 67.7% for KITCHEN, 25.1% for BATHROOM and 7.2% for CORRIDOR. These describe source annotations, not proof of daylight adequacy or permission to create windowless occupied rooms. Fixture flags, area dimensions and room-environment distributions remain available per type in the JSON outputs.

## Exterior spaces and net-area semantics

Among all matched keys, **77.9%** have a BALCONY polygon and **8.8%** a LOGGIA polygon; more than one can occur in an apartment. These flags can overlap. The generator cohort has about **89.0%** with at least one semantic BALCONY, LOGGIA, TERRACE, PATIO or GARDEN. Coverage is collection-specific, not a national prevalence estimate.

Do not define outdoors as `layout_net_area == 0`: both BALCONY and STAIRCASE have zero net contribution, while LOGGIA and WINTERGARTEN contribute positive source net area. Also, terraces/gardens/patios lack simulation rows here. `zero_net_area_m2` preserves the source accounting; `exterior_space_area_m2` separately sums the five explicit exterior labels from full geometry. LOGGIA may appear in both source net and semantic exterior totals, so these totals must not simply be added together.

## Circulation and openings: bounded sample, not full topology certification

Seed 42 selected 400 source plans uniformly from the eligible topology pool, then one single-floor/unit apartment per plan. This sample has no country-wide sampling weights. It uses simulated residential areas and 94,618 source floor-context elements, with relevant doors/windows/separators selected spatially. It is distinct from the stricter generation cohort.

Door polygons within the tested distance of exactly two rooms create candidate passage edges. Boundary proximity of at least 0.5 m can create an open-passage candidate after subtracting source walls buffered by 2 mm. Door ambiguities are retained; we do not connect every near pair indiscriminately. The inferred room graph is connected for **217/400 at 1 cm**, **387/400 at 5 cm**, and **358/400 at 10 cm**. Increasing tolerance can introduce ambiguity and reduce accepted edges. The 5 cm setting is a sensitivity-study choice, not a source precision claim or universal snapping tolerance.

At 5 cm, the sample contains 2,751 door edges and 386 open candidates. Frequent pairs include hall–ROOM (629), hall–bathroom (555), hall–living/dining (241), hall–kitchen (240), hall–BEDROOM (212), living/dining–balcony (179) and kitchen–living/dining (156). Those are edge counts, not percentages of apartments or conditional transition probabilities. A hall-centered circulation family with a linked living/kitchen/outdoor zone is a supported starting proposal; exceptions must be allowed.

No overlapping simulated-room area was found in the 400 examples, but this does not test overlap against every wall/fixture or prove gap-free coverage of an apartment outline. Graph connectivity does not establish entrance-to-every-room traversal, door operation, obstacle clearance or accessibility.

Apartment-near opening MRR long-side medians are approximately **0.84 m DOOR**, **0.95 m ENTRANCE_DOOR** and **1.30 m WINDOW**. They are polygon span proxies, not clear openings; they include different door/window types and source outliers. Common 2.0 m door heights and 1.9 m window heights are heavily repeated assumptions. No construction standard follows from these counts.

Near-rectangular separator thickness proxies and bathroom–kitchen gap measurements are in `construction_proxies.json`. The nearest bathroom–kitchen gap across 399 sampled apartments is **0.1 / 0.2 / 3.2 m** (p10 / median / p90); 229 are under 0.4 m. This is a proximity observation, not proof of a shared plumbing wall or vertical service stack.

## Simulations, location and ratings

The publisher's units are klx for solar illuminance, steradians for views and dBA for noise; connectivity fields are simulated grid/path descriptors. Solar fields describe 18 specified times on three dates in 2018, not annual energy performance, contemporary measured illuminance or daylight autonomy. We profiled every simulation field and retained selected metrics for joined analysis. Distances to a room type can be missing when that type is absent; blanks must not become zero distances. Exact zero noise values are common and do not establish physically silent rooms.

Building-level analyses exclude the five cross-building apartment keys. They include **3,169** buildings, of which **3,007** have annual temperature normals and **3,002** have an overall location rating. Most preselected rank correlations with median apartment size/hall share are weak (all absolute Spearman values below 0.15 in the examined set). Overall location rating vs building median net area is about +0.04. There is no demonstrated rule here that a high rating implies a larger or better geometric layout.

Walkshed fields are sparse: observed supermarket/school/park counts start at 1, with many blanks. We retained blanks; absence of a recorded tag may mean no tagged amenity or unavailable information. The description does not settle that distinction for every row. The saved correlations therefore use nonmissing pairs and are conditional on that coverage. Never sum all tag categories as unique amenities: tags overlap and include compound values.

Ratings are **building context**, not room quality, architectural correctness or overall apartment utility. Demand segment codes and pedestrian bands are categorical/ordinal; do not average demand-segment numbers. Climate/amenities are useful external conditioning/evaluation context, but they do not supply the surrounding buildings, terrain or full georeferencing needed to recreate the original environmental simulations.

About 96.3% of matched room records have height exactly 2.6 m. Combined with the publisher warning, this makes height a useful adjustable modeling default, not a measured distribution of real ceiling heights. Geometry alone also does not identify wall assemblies, structure, construction year, load-bearing roles, door swings or current legal compliance.

## Repetition and verification

There are **26,389** conservative signatures of `(site, source-plan, sorted simulated area IDs)` among 44,947 matched keys. Within `(site, plan, area_id)`, repeated records have identical WKT in every checked group. One-per-signature median net area is 80.6 m² versus 78.9 m² per apartment instance. A signature is not a globally deduplicated design: identical layouts in different plans/sites can remain distinct. Split any future training/validation by site, retaining plan groups, instead of randomly splitting room or floor instances.

All joins have explicit cardinality checks. WKT areas agree with source layout areas to maximum relative difference 1.97e-8 (allowing rounding in this statement). An independent shoelace calculation on 512 seeded area geometries has maximum relative difference below 6e-16. Known-answer checks cover ID normalization, rectangle measures and simple connected/disconnected/wall-blocked graph cases. Six source examples were rendered and visually reviewed. These are separate forms of evidence; none substitutes for generated-design validation.

**Quality confidence: 85/100 — reproducible descriptive research and generation reference.** Evidence includes complete-member integrity checks, a full individual-polygon validity scan, complete simulation joins, independent area checks and bounded topology/visual checks. Largest uncertainty: topology candidates and descriptive priors have not been validated as a generator or as a nationally representative architectural rule set.