---
title: 'GPLAN: Dimensioned Floorplan Generation'
url: https://www.emergentmind.com/topics/gplan
type: topic
---

# GPLAN: Dimensioned Floorplan Generation

GPlan, more commonly styled **GPLAN** in the source publication, is a software system for **computer-generated dimensioned floorplans from given adjacencies**. It is positioned as a bridge between graph-theoretic floorplan research and architectural use: rather than only deciding whether a graph admits a layout, it allows a user to specify adjacency requirements and dimensional bounds through a GUI, and then produces one or many **dimensioned** plans satisfying those requirements. Its intended role is not to replace architects, but to generate feasible initial layouts that can later be refined by designers [2008.01803].

## 1. Scope, input modes, and floorplan classes

GPLAN is explicitly divided into two input modes. In the first mode, the user provides an **adjacency graph** in which vertices represent rooms and edges represent required adjacencies. From this graph, GPLAN generates floorplans with a **rectangular outer boundary**, preferring a **rectangular floorplan (RFP)** whenever one exists and otherwise producing an **orthogonal floorplan (OFP)**. In this graph-input mode, the system can generate **multiple topologically distinct alternatives** [2008.01803].

In the second mode, the user draws a **dimensionless layout** directly on the GUI. This mode is intended especially for **irregular floorplans (IFPs)** with either rectangular or non-rectangular boundaries. GPLAN then assigns dimensions while preserving the **adjacencies, positions, and shapes** of the drawn rooms. Unlike the graph-input mode, this layout-input mode preserves the supplied topology rather than enumerating alternative topologies [2008.01803].

The paper uses standard floorplan terminology. An RFP is a partition of a convex, rectangular envelope into internally disjoint rectangles. An OFP still has a rectangular outer boundary, but some rooms may be orthogonal non-rectangles. An IFP removes even the rectangular-boundary requirement. Adjacency is defined by shared wall segments. The central graph associated with a floorplan is its **weak dual graph**, obtained by replacing each room by a vertex and connecting adjacent rooms. GPLAN’s graph-theoretic foundation relies on the fact that the weak dual of a floorplan with only 3-joints is a **planar triangulated graph (PTG)** [2008.01803].

This division of scope is important because GPLAN does not treat all floorplan-generation problems as instances of a single abstract optimizer. It separates the problem of **topology generation from adjacency constraints** from the problem of **dimensioning an already supplied topology**, and it uses different machinery in each case.

## 2. Graph-theoretic foundations for rectangular-boundary floorplans

For graph-input generation, GPLAN requires the input adjacency graph to be planar, triangulated, connected, and in practice **bi-connected**. If the graph is non-planar, non-triangulated, or not bi-connected, the system rejects it and reports an error. Within this admissible class, rectangular floorplan existence is governed by the theory of **properly triangulated planar graphs (PTPGs)** and **rectangular duals** [2008.01803].

A PTPG is a planar triangulated graph with no separating triangle and exterior face length at least 4. The central existence result quoted by the paper is:

\[
\textbf{Theorem 1. } \text{A bi-connected PTPG } G \text{ has a rectangular dual if and only if it has no more than four corner implying paths (CIPs).}
\]

This theorem drives GPLAN’s logic. Given a bi-connected PTG, GPLAN first checks whether an RFP exists. The paper mentions an integrated tool called **RFPchecker** that evaluates this condition and can explain failure in terms of non-triangulation, separating triangles, or excessive CIPs. If an RFP exists, GPLAN constructs it; if not, it modifies the graph and constructs an OFP instead [2008.01803].

For RFP construction, GPLAN extends the rectangular-dual approach of Kant and He by explicitly handling **4-completion** via corner-implying paths. Starting with a bi-connected PTG, the system selects four exterior vertices \(u_0,u_1,u_2,u_3\) in clockwise order, forms four boundary paths \(P_0,P_1,P_2,P_3\), adds four new vertices \(N,E,S,W\), connects each of them to all vertices on one boundary path, and adds the four outer edges

\[
(N,W),\ (N,E),\ (S,E),\ (S,W).
\]

The purpose is to transform the graph into a PTPG without separating triangles. Once the graph is 4-completed into a PTPG, GPLAN follows the rectangular-dual pipeline based on **regular edge labelling (REL)** and induced **horizontal** and **vertical \(st\)-graphs**. The workflow given in the paper is: 4-completion, computation of a regular edge labelling, extraction of horizontal and vertical \(st\)-graphs, generation of horizontal and vertical rectangular dual information, and assembly of the required rectangular dual [2008.01803].

This makes GPLAN a concrete implementation of a specific combinatorial tradition in floorplanning: PTGs, PTPGs, CIPs, RELs, rectangular duals, and \(st\)-graphs are not auxiliary concepts but the core representational layers through which topology is decided.

## 3. Orthogonal and irregular floorplan generation

When an RFP does not exist, GPLAN constructs an **orthogonal floorplan** rather than failing outright. The paper identifies three explicit causes of RFP nonexistence: the graph has more than four CIPs, the graph has separating triangles, or the exterior face is triangular. In these cases, GPLAN modifies the graph by adding **extra vertices** and, when necessary, extra triangulating edges so that the modified graph becomes a PTPG admitting an RFP. It then constructs an RFP for the modified graph and finally **merges the rooms corresponding to the added vertices** into neighboring rooms, thereby producing an OFP for the original graph [2008.01803].

The second input mode is especially important for irregular plans. Here GPLAN does not solve the existence problem from an adjacency graph; instead, the user supplies a concrete dimensionless layout. If some rooms are orthogonal non-rectangles, GPLAN partitions them into a minimum number of rectangles using the cited rectilinear polygon partitioning method. If the outer boundary is non-rectangular, GPLAN inserts extra temporary rooms so that the whole arrangement becomes rectangular for the purpose of network-flow dimensioning. After optimization, the auxiliary rooms are deleted and partitioned rectangles belonging to the same original room are recombined. The result is a dimensioned IFP that preserves the given **adjacency graph implicitly encoded by the sketch**, along with room **position and shape** [2008.01803].

This suggests a sharp methodological distinction inside GPLAN. Graph-input mode is a **topological generator** under rectangular-boundary assumptions. Layout-input mode is a **topology-preserving transformation tool** for irregular and user-sketched designs.

## 4. Dimensioning by linear optimization on \(st\)-graphs

After a topological solution is generated, GPLAN performs dimensioning as a **linear optimization problem on network-flow-like \(st\)-graphs**. Widths and heights are optimized separately using the vertical and horizontal \(st\)-graphs. The paper states the model as:

\[
\text{Minimize : } \sum w(e_{j,i}) - d_i^{\max}
\]

subject to

\[
\sum w(e_{j,i}) = \sum w(e_{i,k}) \qquad \forall i \in V(G)
\]

\[
\min(d_i) \le \sum w(e_{j,i}) \le \max(d_i) \qquad \forall i \in V(G) \tag{1}
\]

where \(d_i^{\max}\) is the maximum dimension of room \(i\), \(\sum w(e_{j,i})\) is the total inflow to vertex \(i\), and \(\sum w(e_{i,k})\) is the total outflow from vertex \(i\). The paper notes that the scan typography is imperfect, but its intended interpretation is that flow conservation enforces geometric consistency and lower/upper bounds enforce user dimension constraints [2008.01803].

The worked example exposes the kinds of generated constraints. The paper lists flow-balance equalities such as

\[
W_{N1} = W_{12} = W_{25}, \qquad
W_{N5} = W_{54},
\]

\[
W_{N6} = W_{64} + W_{67}, \qquad
W_{54} + W_{64} = W_{43} + W_{48},
\]

and dimension bounds such as

\[
4 \le W_{N1} \le 5.5,\qquad
3 \le W_{12} \le 5,
\]

\[
4.4 \le W_{N5} \le 6,\qquad
7 \le W_{N6} \le 10.5.
\]

These are shown separately for width and height through the vertical and horizontal \(st\)-graphs [2008.01803].

The paper states that GPLAN improves on the earlier model of Upasani et al. by replacing direct width/height minimization with an objective based on the gap to the maximum bounds, resulting in smaller total floorplan area. In practice, the software uses the **dual-simplex method**, chosen because it is much faster than stochastic alternatives and allows all topological candidates to be dimensioned within a reasonable time. Feasibility is therefore conditional: GPLAN produces a dimensioned plan when the resulting linear constraints are satisfiable, rather than guaranteeing feasibility under arbitrary inconsistent user bounds [2008.01803].

The architectural constraints handled are primarily adjacency requirements, rectangular or preserved non-rectangular topology, room width bounds, room height bounds, implied area control through width/height combination, rectangular boundary in graph-input mode, and preservation of positions and shapes in layout-input mode. By contrast, the paper explicitly does **not** present a general aspect-ratio model or explicit orientation constraints [2008.01803].

## 5. Enumeration, software workflow, and empirical behavior

A major claimed contribution of GPLAN is the generation of **multiple topologically distinct floorplans**. The paper defines two floorplans as topologically distinct when they have the same weak dual graph but different horizontal and vertical adjacency structures. For RFPs, GPLAN enumerates alternatives by iterating over different possible **boundary paths** and, for each boundary, finding different **RELs** using the concept of a **flippable item** from Eppstein et al. For one example graph, GPLAN examined **154 possible boundaries** and generated **1300 topologically distinct RFPs in 282.45 seconds** [2008.01803].

For OFPs, the enumeration procedure is broader. GPLAN enumerates all ways to augment a bi-connected PTG into a PTPG; if the graph has \(k>4\) CIPs, there are

\[
\binom{k}{4}
\]

ways to choose which four remain as corners after adding extra vertices, and each separating triangle may be removable in three possible ways. For each augmented PTPG, GPLAN generates all possible RFPs as above, then merges the extra rooms in all valid ways to obtain OFPs. On the example corresponding to the paper’s Figure 17b, GPLAN generated **256 topologically distinct OFPs in 26.56 seconds** [2008.01803].

At the implementation level, GPLAN is developed in **Python** and provides a **GUI** through which the user can draw an adjacency graph or a dimensionless layout, enter dimensional constraints for each room, request multiple floorplans, check RFP existence via RFPchecker, and generate dimensioned output plans. The illustrated workflow is input graph or layout, topology generation or preservation, dimensional input, linear optimization, and dimensioned floorplan output [2008.01803].

The case studies emphasize both regeneration and design support. In one example, GPLAN re-generates the **Villa Trissino** floorplan by extracting its underlying adjacency graph and then generating a corresponding dimensioned plan; it also generates topologically distinct alternatives to that historical plan. In another, the **Banstead Home School Plan** is drawn directly in the GUI and then dimensioned, illustrating the dimensionless-layout mode for a complex existing plan [2008.01803].

## 6. Assumptions, limitations, and terminological ambiguity

GPLAN’s assumptions are explicit. It assumes orthogonal geometry; graph-input mode assumes adjacency graphs are planar triangulated and bi-connected; the system focuses on floorplans with 3-joints; RFP generation depends on PTPG/CIP theory; OFPs are produced by graph augmentation and room merging; and IFP generation from graphs is not solved directly, so the user must provide the dimensionless IFP topology explicitly [2008.01803].

Its limitations are equally explicit. Although GPLAN can generate very many solutions, the paper notes that users cannot inspect all of them manually, so future work is needed to rank or filter solutions using boundary preferences, daylight, circulation, and other architectural criteria. GPLAN does not automate circulation design, detailed functional reasoning, or comprehensive architectural evaluation. For irregular floorplans, it does not generate topologically distinct alternatives from an adjacency graph; it only dimensions a user-supplied layout. The authors stress that architects still need to refine the generated layouts [2008.01803].

A recurring source of confusion is nomenclature. In the architectural context considered here, GPLAN denotes the floorplan-generation system just described. Later literature uses visually similar names for unrelated systems: **GenePlan** is a domain-dependent generalized planner for classical PDDL domains [2603.09481]; **G-PlanET** is a benchmark and modeling framework for grounded planning for embodied tasks with language models [2209.00465]; **GPlan** in Amap denotes a generative framework for spatiotemporal intent-sequence recommendation [2605.28888]; and **GenPlan** denotes a generative sequence-model planner for adaptive behavioral planning [2412.08565]. These works are conceptually adjacent only at the level of “planning” as a broad label; they are not extensions of GPLAN’s floorplan methodology.

Within architectural computation, GPLAN remains notable for combining **graph theory** and **linear optimization** into a user-facing system that turns adjacency requirements or sketched layouts into **dimensioned floorplans**. Its significance lies less in black-box generation than in its explicit synthesis pipeline: weak-dual graph reasoning for topology, REL and \(st\)-graph constructions for rectangularization, and flow-based optimization for dimension assignment [2008.01803].

Source: https://www.emergentmind.com/topics/gplan