A Proposal:
by Carlo H. Séquin, February 1996
Symbolic Building Design with Nested Spaces
Abstract
The idea is explored to restrict the designer of a building floorplan at the symbolic level to the use of strictly nested spaces. The specifications for a corresponding 2D graphical polygon editor are outlined.
Introduction
The Symbolic Building Plan is one of the abstract building representations that can help to bridge the gap between initial bubble diagrams and the actual architectural floorplans. It promises clarity of organization, a minimum of clutter, and ease of making non-local changes to a layout in the conceptual phase of building design.
In order to avoid ambiguity of the allowed operations in an interactive design phase and also to make the implementation efficient and tractable, certain restrictions on the allowed geometrical configurations have to be imposed. One such restriction might be a strictly nested hierarchy of polygon contours: Each polygon must be entirely contained within the contour at the next higher hierarchical level, and polygons at the same level cannot mutually overlap. Occasionally this may lead to a less than optimal description of a building, but normally an almost equally good representation can be found. This slight inconvenience seems well worth the efficiency and clarity that can be gained from a good hierarchy.
In this working paper, I explore these restriction and discuss the consequences for an ideally matched graphical editing system.
Symbolic Building Plan
In this representation, a building is viewed as a strictly nested set of regions (no overlapping contours). This is true for now for the 2D schematic floor plans, but will be extended logically to a corresponding abstracted 3D geometrical description of the building.
The regions may belong to the following levels, many of which can be nested themselves, and additional levels can be defined if desirable. The levels should not be made of fundamentally different data types; the differences come only from different attributes which may restrict certain operations available to the general set. A starter set of regions, in a top-down listing, might be:
- Building wings,
- Floor outlines,
- Suites or fire zones,
- Room clusters,
- Rooms
- Room areas, such as work-space, storage area ...
Areas within a region that are not covered by the union of the regions at the next lower level in the hierarchy may assume different meanings depending on the level:
- At the building wing level, such areas would normally be outside areas;
- at the floor level, such areas would typically be corridors, hallways ...;
- at the room level they may be of unspecified type, e.g. sleeping area.
Typically, each region carries a boundary -- and indeed the region is specified and defined by the geometrical description of this boundary. Different regions are implicitly defined by different boundary types:
- for building wings or floor outlines they are outside walls,
- for fire-zones they are fire walls and fire doors;
- for rooms they may be regular walls, doors, counters, or just conceptual demarcation lines;
- for room interiors they may be partitions, furniture pieces, or just conceptual region boundaries.
Regions can be dragged around and moved into regions that belong to a higher hierarchical level -- provided that the higher contour is large enough to accommodate the lower region contour without intersection. When a region moves, its characteristic boundary will go with it, shared boundaries are suitably replicated; e.g., rooms move with their walls, fire zones with their fire walls; but an ordinary room, sharing a fire wall, will move away to a different location with only an ordinary wall around it.
When regions are put into closer adjacencies than a certain minimum distance for their type of boundary, the boundaries will snap together and merge. When different areas are put into new adjacencies, the stronger (higher-level) boundary predominates on the shared section of the boundary. An ordinary room pushed against a fire-wall will assume that type of wall along the shared edge, rather than creating a breach by inserting a piece of ordinary wall into the fire zone perimeter.
Explicit operations are provided to merge two regions into a single one, or to split one region into two or more regions of the same type. Editing operations are provided to change the shape of a region without altering its area.
Various proximity, adjacency, and connectivity measures can be derived from this symbolic representation.
- Euclidean distance between room centers or closest corners.
- Walking distance through allowable portals and along walkable spaces (corridors).
- Direct adjacency by sharing a boundary segment (wall).
- Connectivity via a walkable shared portal, or a non-walkable opening (window).
- Visibility through a suitably aligned sequence of portals.
Nested Polygon Editor
We would like to have a special purpose graphics editor for this symbolic representation that strictly enforces the hierarchical nesting and non-overlap conditions on all the region boundaries, but at the same time maximally supports the construction of and experimentation with such symbolic layouts. Here are some ideas how the editor might achieve that.
Drawing regions:
A region is defined by its polygonal boundary. As the user draws such a polygon from scratch, a closed outline is maintained at all times, by rubber-banding the last boundary segment as well as the closing boundary segment to the first vertex.
Editing regions:
Previously drawn regions can be edited: points can be moved to new locations; and new vertices can be created on any existing edge and then dragged to new positions. It is prohibited to draw self-intersecting contours. When the user draws such an illegal segment, some methods of alerting or preventing the user form finalizing that segment in this position must be provided; various possibilities should be explored:
- Change color when the situation is illegal.
- Prevent cursor from crossing other edges of the contour; {this may be too restrictive; the user could paint himself in a corner}.
- Any other good ideas ??
Moving regions around:
When moving complete regions they should not be allowed to be dropped onto another contour. Perhaps use repulsive action for small overlap; but at the very least use a color/highlight indication for any illegal situation. Probably all offending contours involved in the intersection should be highlighted in some form, giving the user the option of adjusting the previously designed contours rather than the one most recently moved.
Griding:
A mode can be set where cursor movements are confined to a predefined grid of user-selectable grid units. Vertices will snap to this grid; and displacements of regions will happen in increments of integer grid units.
Snapping:
In this mode, the cursor snaps preferentially to vertices, then to edges.
Enforced cleanup:
Illegal situations stay highlighted in some form until they are corrected.
Should the user be prevented from doing any editing operations on other contours before the existing illegal situation is cleaned up ?
Querying:
Regions can have additional informations attached to them that is not always explicitly visible. Examples are: exact square footage, room number, function of room, designated occupant; special requirements ... This extra information should be readily retrievable with a simple mouse or menu action.
Automatic reporting:
Certain checking tools or evaluating agents could be running in the background and report certain events, such as: illegal constellations, violations of entries in the adjacency matrix, code violations (lack of exit doors, not enough stairwells)... Many of these issues might preferentially be checked in a batch mode at times when the designers has reached a certain stable point in the design activity. However, a few of these tests might be very helpful if they are running constantly during certain layout phases (e.g., connectivity checker of named nets in integrated circuit layout).
Issues
What is the right balance between efficient rule checking and obnoxious interference with an inspired but "loose" design spree ?
How narrow or how wide a range of concerns should be addressed in a particular view of the building design ?
How many different views can be practically glued to one underlying representation ?
<-- Back to CS 294-5 HomePage
Page Editor:
Carlo H. Séquin