1. 16 2. LINDENMAYER-SYSTEME
wurden eindrückliche Szenarios geschaffen (Abbildung 2.9). Natürlich wurden in diesen
Beispielen auch stochastische Verhaltensweisen in die Simulationen miteinbezogen.
Abbildung 2.9: (3D-)Umgebungssensitives L-System. Links: Ein Skelett aus Linien
und Ellipsoiden definiert eine implitzite Oberfläche. Rechts: Inner-
halb dieser Oberfläche gewachsene Pflanzenstruktur.
Dieses Beispiel führt vor, dass man zuerst intensiv die Eigenschaften eines Objektes
studieren muss, bevor man es mit einem L-System simuliert. Die entsprechenden Regeln zu
finden kann ziemlich anspruchsvoll und aufwendig sein, wie die vielen Beispiele unter-
schiedlichster Pflanzenarten aus Lindenmayers und Prusinkiewicz’ Arbeiten zeigen.
2.7 Open L-Systems
Interaktion mit der Umgebung ist ein wichtiger Aspekt in der Entwicklung von Pflanzen.
Während in umgebungssensitiven L-Systemen nur die Reaktion der Pflanze auf ihre Umgebung
simuliert wird, sind Open L-Systems in der Lage, beidseitige Kommunikation zu modellieren.
Das bedeuted, die Pflanze kann nun auch Änderungen in der Umgebung bewirken. Deshalb
wurden die Query-Module zu Kommunikations-Modulen der Form ?E(x1, x2, ... , xn) erweitert.
Die Parameter x1, x2, ... , xn senden und empfangen Information der Umgebung. Zusätzlich wird
der Umgebung immer der Status der Turtle (Position und Orientierung) mitgeliefert, d.h. dies
muss nun nicht mehr explizit angegeben werden.
Je grösser das Gleichungssystem zur Definition eines L-Systems wird, desto unüber-
sichtlicher wird dieses. Deshalb wurden weitere Konstrukte eingeführt:
• Produktionen können Zuweisungsstatements für lokale Variablen beinhalten. Diese
Zuweisungen sind in geschweiften Klammern und durch Semikolons getrennt.
• Das L-System kann Arrays verarbeiten. Auf einzelne Felder kann auf die selbe Weise
wie in der Programmiersprache C zugegriffen werden.
• Die Liste der Produktionen ist geordnet. Im deterministischen Fall wird die erste pas-
sende Funktion ausgeführt. Dabei werden die Produktionen, wenn nicht anders ange-
geben, von oben nach unten geprüft. Im stochastischen Fall bleibt alles beim Alten.
Das folgende, umfassende Open L-System modelliert das Wachstum einer Wurzel. Haupt-
aufgabe einer Wurzel ist das Beschaffen von Nährstoffen für die Pflanze. Durch das Aufsaugen
von Wasser wird aber lokal die Wasserkonzentration im Boden vermindert, was Wasser-
bewegungen im Boden verursachen kann (von wasserreichen zu entleerten Regionen).
Währenddessen wachsen die Spitzen der Wurzel mehr oder weniger dem Gradienten der

2. 2.7 OPEN L-SYSTEMS 17
Wasserkonzentration entgegen, den sie durch ihre Aktivitäten verändert haben. Es finden also
komplexe Interaktionen zwischen Wurzel und Boden statt. Das Modell beschränkt sich wieder
auf 2D. Zuerst werden die Funktionen der Kommunikations-Module erklärt, dann das Umge-
bungsmodell (der Boden) und anschliessend das Open L-System, das die Wurzel simuliert.
Kommunikations-Spezifikation: Die Pflanze interagiert mit der Umgebung mit Kommuni-
kations-Modulen der Form ?E(c, θ), die in den Spitzen des Wurzelsystems zu finden sind. Der
Parameter c repräsentiert die gewünschte (optimale) Menge Wasser, die die Spitze aufnehmen
möchte, und der Wert θ gewichtet den Einfluss des Gradienten auf die Richtung, in der die
Wurzelspitze wachsen soll. Hat die Umgebung die eingegangenen Daten verarbeitet, sendet sie
mit c die tatsächliche Wassermenge, die die Wurzelspitze erhalten kann, und θ ist nun ein
Winkel und beschreibt die Wachstumsrichtung.
Umgebungsmodell: Die Umgebung ist ein Feld C von
Wasserkonzentrationen, repräsentiert durch ein Array mit
jeweils der Menge Wasser pro Volumeneinheit. Die Wasser-
bewegungen im Boden folgen den Gesetzen der Diffusion
und werden mittels finiten Differenzen numerisch berechnet.
Auf eine Anfrage einer Wurzelspitze mit Position (i, j) nach
Wasser reagiert die Umgebung folgendermassen: Der neue
Wert für c, also die Menge Wasser, die die Wurzelspitze
erhalten kann, wird bestimmt, indem man die gewünschte (cin)
mit der an dieser Stelle verfügbare Menge Wasser vergleicht Abbildung 2.10:
und den kleineren Wert auswählt. Anschliessend wird die Definition von θout.
Wasserkonzentration an der abgetasteten Position um diesen
Wert dekrementiert. Der zweite Parameter θ des Kommunikations-Moduls, die Richtung, in
welche die Wurzelspitze weiterwachsen soll, wird berechnet wie in Abildung 2.10 dargestellt:
Der Vektor T ist eine lineare Kombination des Vektors H, welcher Position und Richtung der
Turtle repräsentiert, und des mit θin gewichteten Vektors ∇C, des Gradienten der
Wasserkonzentrationen. θout ist dann der Winkel zwischen den Vektoren T und H.
Wurzelmodell: Das Open L-System benutzt Arrays, um so unterschiedliche Parameterwerte
für die drei verschiedenen Verzweigungstiefen zu lesen. Diese Parameterwerte basieren auf
Biologie-Arbeiten über Wurzeln.
#define N 3 /* max. branching order + 1 */
Define: { array
Req[N] = {0.1, 0.4, 0.05}, /* requested nutrient intake */
MinReq[N] = {0.01, 0.06, 0.01}, /* minimum nutrient intake */
ElRate[N] = {0.55, 0.25, 0.55}, /* maximum elongation rate */
MaxLen[N] = {200, 5, 0.8}, /* maximum branch length */
Sens[N] = {10, 0, 0}, /* sensitivity to gradient */
Dev[N] = {30, 75, 75}, /* deviation in heading */
Del[N-1] = {30, 60}, /* delay in branch growth */
BrAngle[N-1] = {90, 90}, /* branching angle */
BrSpace[N-1] = {1, 0.5}, /* distance between branches */
}
ω : A(0,0,0) ?E(Req[0],Sens[0])
p1 : A(n,s,b) > ?E(c,θ) : (s > MaxLen[n]) || (c < MinReq[n]) → ε
p2 : A(n,s,b) > ?E(c,θ) :
(n ≥ N-1) || (b < BrSpace[n]) {h = c/Req[n]·ElRate[n];}
→ +(nran(θ,Dev[n])) F(h) A(n,s+b,b+h) ?E(Req[n],Sens[n])

3. 18 2. LINDENMAYER-SYSTEME
p3 : A(n,s,b) > ?E(c,θ) :
(n < N-1) && (b ≥ BrSpace[n]) {h = c/Req[n]·ElRate[n];}
→ +(nran(θ,Dev[n])) B(n,0) F(h)
/(180) A(n,s+h,h) ?E(Req[n],Sens[n])
p4 : B(n,t) : t < Del[n] → B(n,t+1)
p5 : B(n,t) : t ≥ Del[n]
→ [ +(BrAngle[n]) A(n+1,0,0) ?E(Req[n+1],Sens[n+1]) ]
p6 : ?E(c,θ) → ε
Die Entwicklung startet mit einem Apex A, gefolgt von einem Kommunikations-Modul ?E. Die
Parameter vom Apex repräsentieren die Verzweigungstiefe, die momentane Länge dieser
Achse und die Distanz zum letzten Verzweigungspunkt. Im den folgenden Abschnitten werden
die Produktionen p1 bis p3 illustriert, die das mögliche Schicksal eines Apex’ beschreiben.
Überschreitet die Länge s einer Achse mit Verzweigungstiefe n den vordefinierten
Maximumwert MaxLen[n], oder reicht die erhaltene Menge Wasser c nicht mehr aus (d.h. liegt
unter dem Minimum MinReq[n]), stirbt der Apex ab und die Wurzelspitze wächst nicht mehr
weiter (Produktion p1).
Ist die Verzweigunstiefe n gleich der maximalen Verzweigungstiefe N-1, oder die Distanz
b zur letzten Verzweigung kleiner als die Schwelle BrSpace[n], generiert der Apex ein neues
Wurzelsegment F (Produktion p2). Die Länge h von F wird berechnet, indem man das Ver-
längerungsinkrement ElRate[n] mit dem Verhältnis zwischen erhaltener (c) und gewünschter
(Req[n]) Menge Wasser multipliziert. Zuvor wird die Turtle um den Winkel nran(q,Dev[n])
gedreht, wobei nran ein Zufallszahlengenerator mit Normalverteilung ist. Die Standardab-
weichung Dev[n] simuliert andere Einflüsse auf die Wachstumsrichtung der Wurzelspitze, die
in diesem Modell nicht berücksichtigt wurden.
Ist die Verzweigunstiefe n kleiner als die maximalen Verzweigungstiefe N-1, und die Dis-
tanz b zur letzten Verzweigung gleich oder grösser als der Schwellwert BrSpace[n], so tritt
Produktion p3 in Kraft, welche eine neue Verzweigung B generiert. Alles weitere läuft wie in p2
ab.
Produktion p4 modelliert die Verzögerung von Del[n] Ersetzungschritten. Danach wird eine
neueVerzweigung mit Apex und Kommunikations-Modul eingefügt (p5). Die letzte Produktion
p6 ist dafür zuständig, die (oben gebrauchten) Kommunikations-Module zu löschen.
Abbildung 2.11: 2D-Modell einer Wurzel, die mit dem Wasser im Boden interagiert.
Die Hintergrundfarben illustrieren die Wasserkonzentrationen
(Blau: hoch, Schwarz: tief).

4. 2.7 OPEN L-SYSTEMS 19
Das Resultat der Simulation ist in Bild 2.11 dargestellt. Die Spitze der Hauptachse (Ver-
zweigungstiefe 0) folgt, mit kleinen, zufälligen Abweichungen, dem Gradienten der
Wasserkonzentrationen. Die Äste der höheren Verzweigungsebenen sind auf den Gradienten
nicht sensitiv und haben eine grössere Standardabweichung. Durch die Wasseraufnahme der
Wurzelspitzen werden lokale Regionen völlig entleert und können auch nicht mehr durch Dif-
fusion (aus wasserreichen Regionen) aufgefüllt werden. Als Folge dieser tiefen Wasser-
konzentrationen stoppt das Wachstum einiger Wurzelverzweigungen, noch bevor diese ihre
volle Länge erreicht haben. Bild 2.12 zeigt eine dreidimensionale Erweiterung des vorher-
gehenden Modells. Das linke Bild illustriert den Kampf zweier Wurzel um Wasser, was auch
der Grund ist, weshalb die beiden sich immer mehr von einander entfernen. Rechts wachsen die
Wurzeln langsamer, der Einflussbereich von jedem Wurzelsystem ist kleiner und die Haupt-
achsen sind näher zusammen. Diese 2 Wurzelsysteme interagieren miteinander und benützen
zur Kommunikation die Umgebung bzw. den Boden als Medium.
Abbildung 2.12: Dreidimensionale Version des Wurzel-Modells. Wasserkonzentra-
tionen werden durch halb-transparente Iso-Oberflächen dargestellt.

5. 20 2. LINDENMAYER-SYSTEME

6. 3System Architektur
Das CityEngine System ist die Implementation der in Abbildung 3.1 dargestellten Pipeline: Im
ersten Schritt werden die Eingabebilder in die CityEngine eingelesen, und ein für diese Zwecke
erweitertes L-System generiert daraus ein Strassennetzwerk. Dieses kann mit dem Strassen-
editor nachträglich verändert werden. Dann werden die Räume zwischen den Strassen in
Grundrisse (Allotments) unterteilt, auf welchen die Gebäude platziert werden. Im vierten
Schritt werden durch ein zweites L-System den Gebäudegrundrissen entsprechende Shape
Grammar Strings generiert. Im letzten Schritt werden die Strings, welche die Formen der
Gebäude beschreiben, interpretiert und als texturierte Geometrie ausgegeben. Die Geometrie-
daten der virtuellen Stadt können schliesslich mit einem 3D-Renderer visualisiert werden.
Abbildung 3.1: Die Pipeline der CityEngine. Die eingerahmten Boxen repräsen-
tieren die Daten, welche die Tools in den schwarzen Boxen als Input
respektive Output haben.
21

7. 22 3. SYSTEM ARCHITEKTUR
Die Eingabedaten, welche aus Graustufenbildern und Parametern bestehen, sind verant-
wortlich für das Verhalten des gesamten Systems, also für das Aussehen der resultierenden vir-
tuellen Stadt. Die Eingabebilder können durch Zeichnen oder Scannen von topographischen
und statistischen Karten (wie in [9]) erstellt werden. Die Inputs lassen sich in folgende Kate-
gorien unterteilen:
• Topographische Karten: Wasser/Land, Vegetation (Parks), Elevation
• Soziostatistische Karten: Populationsdichte, Landnutzung, Alter
• Kontrollbilder: Strassenmuster
Die ersten beiden Eingabebilder, Wasser/Land und Vegetation, werden binär interpretiert. Die
Landnutzungskarte unterscheidet zwischen Residential, Commercial oder Industrial. Den rest-
lichen Bildern können Skalierungswerte und Offsets übergeben werden. Abbildung 3.2 (links
oben) zeigt von jeder Kategorie ein Eingabebild. Die Eingabeparameter können aus statis-
tischen Datensammlungen entnommen oder abgeleitet werden. In [16] finden sich beispiels-
weise Angaben zur Anzahl Kreuzungen pro Fläche, woraus die durchschnittliche Strassenlänge
berechnet werden kann, welche ein Parameter der CityEngine ist. Die Parameter können jeder-
zeit interaktiv verändert werden, wodurch das Verhalten des Systems beeinflusst werden kann.
Ein erweitertes L-System, dessen Verhalten hierarchisch kontrolliert werden kann, generiert
die Strassennetzwerke. Auf einer globalen Ebene des L-Systems, kann das Strassenmuster
bestimmt werden (durch die Rules und deren Kontrollbilder), und auf einer lokalen Ebene kann
beispielsweise bestimmt werden, wieviele Strassen maximal in einer Kreuzung münden. Der
L-System Mechanismus wurde so erweitert, dass das Einbinden beliebig vieler Strassenmuster
oder das Ändern von Parametern keine Modifikation der Produktionsregeln erfordert. Eine
zusätzliche Erweiterung zu bestehenden L-Systemen wurde entwickelt, um Zyklen und
Intersektionen im generierten Strassennetzwerk zu erkennen (selbstsensitive L-Systeme).
Die Populationsdichte einer Stadt wird beeinflusst durch den Bau von Strassen [10]. Die
inverse Interpretation dieser Tatsache benutzt das L-System um die Strassen zu kreieren. Nach
[10], ändern aber nicht alle Strassen die Population in ihrer lokalen Umgebung (Beispiel: eine
Strasse die zwei Städte miteinander verbindet). Deshalb verwendet das L-System zwei Arten
von Strassen: Highways und Streets. Diese unterscheiden sich durch Funktion und Verhalten.
Die Highways verbinden Regionen mit hoher Populationsdichte global, indem sie das Eingabe-
bild absuchen. Die Streets bedecken, abhängig von der Populationsdichte, die Flächen zwischen
den Highways, so dass der Zugang zu den Highways stets sichergestellt ist. Diese beiden Stras-
sentypen zusammen bilden das Strassennetzwerk der virutellen Stadt (Abbildung 3.2 links
unten).
Ist das Strassennetzwerk kreiert, werden die Zwischenräume mit einem geometrischen Par-
zellierungsalgorithmus in Allotments unterteilt. Auf den Grundrissen werden stochastische,
parametrische L-Systeme ausgeführt, die die entsprechenden Shape Grammar Strings gene-
rieren. Mit der CityEngine Shape Grammar kann die Form der Gebäude beschrieben werden.
Der Benutzer programmiert diese L-Systeme und überwacht deren Verteilung. Dadurch kann er
den Stil der Bauten in der virtuellen Stadt spezifizieren. Die Programmierung der L-Systeme
fällt leicht, da die CityEngine Shape Grammar für derartige L-Systeme entworfen wurde.
Der 3D-Interpreter, welcher die Strings parst, erzeugt Polygon-Geometrien mit Textur-
kooridnaten, welche sich entweder für prozedurale Shader eignen oder planares Mapping
erlauben. Die Geometriedaten können anschliessend in Alias¦Wavefronts Maya eingelesen wer-
den. In Maya können den Geometrien Shader zugewiesen, eine Umgebung kann integriert und
die Stadt kann visualisiert werden (siehe Abbildung 3.2 rechts).

8. 23
Abbildung 3.2: Mit der CityEngine generierte virtuelle Stadt. Links oben: Drei der
Eingabebilder (Elevation, Populationsdichte und Rule Kontrollbild).
Links unten: Generiertes Strassennetz. Rechts: Gerenderte Geometrie.

9. 24 3. SYSTEM ARCHITEKTUR

10. 4Erzeugung der
Strassennetzwerke
4.1 Das erweiterte L-System
Um ein Strassennetzwerk zu generieren, wird ein kompliziertes L-System Regelwerk mit einer
grossen Zahl von Parametern und Konditionen benötigt. Die Anzahl der Produktionen steigt
rasch, und falls man neue Regeln implementieren will, müssen viele der bestehenden Produ-
ktionen neu angepasst werden. Je grösser das L-System wird, desto unübersichtlicher und
unflexibler wird es. Das L-System der CityEngine hat deshalb bloss noch eine ausführende
Rolle, das heisst, es übernimmt nur noch die Produktion der Module. Das Bestimmen der
Parameter wird von externen Funktionen kontrolliert. Das L-System ist ideal geeignet, um diese
externen Funktionen hierarchisch zu ordnen.
Da das L-System nur ein Template generiert und die Parameter nicht durch das L-System
bestimmt werden, sind fast keine konditionalen Produktionen nötig. Dadurch wiederum wird
innerhalb der Module die Anzahl der Parameter, die für das L-System sichtbar sein müssen,
reduziert. Es resultiert ein sehr übersichtliches L-System, das nur noch die für die Wachstums-
steuerung nötigen Komponenten beinhaltet (im Sinne von Datenstrukturen). Das generische
Template, welches immer drei Strassenverzweigungen erzeugt, wird Ideal Successor genannt.
Die Erzeugung einer Strasse in diesem L-System durchläuft folgende Phasen (siehe auch
Abbildung 4.1):
1. Initiert werden neue Strassen durch den Ideal Successor. Dessen drei Verzweigungen
bestehen aus Modulen, die je eine Strasse symbolisieren. Den Parametern dieser
Module werden keine Werte zugewiesen.
2. Die externe Funktion globalGoals wird aufgerufen. Diese bestimmt die Parameter-
werte der in Punkt 1 erwähnten Module. Mit dieser Funktion kann das Verhalten einer
Strasse bezüglich ihres Wachstums auf einer globalen Ebene kontrolliert werden.
3. Die externe Funktion localConstraints wird aufgerufen. Die in Punkt 2 vorge-
schlagenen Parameter werden von dieser Funktion überprüft. Falls die Strasse nicht in
die lokale Umgebungssituation passt, wird versucht, deren Parameter entsprechend zu
justieren. Ist es aus umgebungsbedingten Gründen unmöglich eine Strasse im System
einzufügen, wird sie von dieser Funktion verworfen.
25

11. 26 4. ERZEUGUNG DER STRASSENNETZWERKE
Abbildung 4.1: Die Erzeugung einer Strasse. Die Bestimmung der Parameterwerte
folgt hierarchischen Funktionen.
Die Funktion globalGoals bewirkt, dass die Strassen einem globalen Muster folgen, und die
Funktion localConstraints implementiert den umgebungssensitiven Teil eines L-Systems.
Durch diese beiden Funktionen wird das Verhalten des L-Systems vollständig kontrolliert.
Deshalb kann die Funktionalität des L-Systems erweitert werden, ohne dass die Produktionen
verändert werden müssen. Das Regelwerk des L-Systems, das die Strassennetzwerke erzeugt,
sieht folgendermassen aus:
ω: R(0,initialRuleAttr) ?I(initRoadAttr,UNASSIGNED)
p1 : R(del,ruleAttr) < ?I(roadAttr,state) : del < 0 → ε
p2 : ?I(roadAttr,state) : state == UNASSIGNED
{localConstraints(roadAttr) adjusts the parameters for: state, roadAttr}
→ ?I(roadAttr, state)
p3 : ?I(roadAttr,state) : state != UNASSIGNED → ε
p4 : R(del, ruleAttr) : del < 0 → ε
p5 : R(del, ruleAttr) > ?I(roadAttr,state) : state == SUCCEED
{globalGoals(ruleAttr,roadAttr) creates the parameters
for: pDel[0-2], pRuleAttr[0-2], pRoadAttr[0-2]}
→ +(roadAttr.angle) F(roadAttr.length)
B(pDel[1],pRuleAttr[1],pRoadAttr[1])
B(pDel[2],pRuleAttr[2],pRoadAttr[2])
R(pDel[0],pRuleAttr[0]) ?I(pRoadAttr[0],UNASSIGNED)
p6 : R(del, ruleAttr) > ?I(roadAttr, state) : state == FAILED → ε
p7 : B(del, ruleAttr, roadAttr) : del > 0 → B(del-1,ruleAttr,roadAttr)
p8 : B(del, ruleAttr, roadAttr) : del == 0
→ [ R(del, ruleAttr) ?I(roadAttr,UNASSIGNED) ]
p9 : B(del,ruleAttr,roadAttr) : del < 0 → ε
Das Axiom ω initialisiert das System mit einem Rule Modul R, gefolgt von einem Insertion
Query Modul ?I. Diese beiden Module treten im L-System immer zusammen auf und repräsen-
tieren eine Strasse. Der Parameter del des Rule Moduls bestimmt, ob eine Strasse exisitiert
(del ≥ 0) und ruleAttr ist eine Sammlung von Parametern, die den Rules zum Übergeben von
Werten dienen. Reichen also für die Programmierung einer Rule die lokalen Informationen und
die Strassenparameter nicht, kann ruleAttr ein neues Element hinzugefügt werden. Mit dem
Insertion Modul können, unabhängig vom Rule Modul, die Local Constraints überprüft werden.
Der Eintrag roadAttr, welcher wie ruleAttr eine Sammlung von Parameter ist, beschreibt eine

12. 4.2 GLOBAL GOALS 27
Strasse mit Parametern wie Winkel, Länge, Typ etc. Der Parameter state dient als Kontroll-
element.
Die ersten drei Produktionen kontrollieren das Insertion Modul. Falls eine Strasse gar nicht
existiert (Parameter del des im Kontext stehenden R Moduls kleiner als Null), tritt Produktion
p1 in Kraft, und das zugehörige Insertion Module wird gelöscht. Produktion p2 ruft die local-
Constraints Überprüfung auf. Diese benötigt als Eingabewert die Strassenparameter (roadAttr),
welche überprüft, und falls nötig, geändert werden. Als Rückgabewert erhält man neben den
(evtl. angepassten) Strassenparametern die Variable state. Wenn die Strasse erfolgreich in der
Umgebung eingefügt werden konnte, wird state auf SUCCESS gestetzt, andernfalls auf-
FAILED. Produktion p3 sorgt aus folgendem Grund dafür, dass ein Insertion Modul nur zwei
Ersetzungsschritte lang existiert: wurde die localConstraints Überprüfung durchgeführt (d.h.
state != UNASSIGNED), werden die Werte in Produktion p5 aus dem Kontext gelesen, und das
Insertion Modul wird nicht mehr benötigt.
Die Produktionen p4 - p6 behandeln das Rule Modul. Existiert eine Strasse nicht (del < 0),
wird diese durch die Produktion p4 gelöscht. Produktion p5 repräsentiert das Template des
L-Systems, das für das Wachstum verantwortlich ist. Das Template fügt die von den Local Con-
straints überprüfte Strasse ein (da state den Wert SUCCESS hat) und erzeugt drei neue Strassen:
zwei Verzweigungen und eine Strasse “geradeaus”. Die Parameter der neuen Strassen werden
von globalGoals (also den Rules) bestimmt: Als Eingabewert werden die Parameter der
erzeugten Strasse (roadAttr) und ruleAttr benötigt. Als Rückgabewert erhält man drei neue
Strassen in Form von Arrays (pDel[0-2], pRuleAttr[0-2] und pRoadAttr[0-2]). Durch das Tem-
plate werden diese drei Strassen (respektive deren Module) in jedem Fall eingefügt. Dies erklärt
auch den Sinn der Produktionen p1 und p4, welche die Module löschen, falls die Funktion glo-
balGoals gar keine Strasse vorgeschlagen hat (pDel[0] < 0). Produktion p6 löscht das R Modul,
falls die localConstraints Überprüfung negativ ausfiel.
Die letzten drei Produktionen kontrollieren das Branch Modul B. Dieses Modul verzögert
den Start des Wachstums einer Verzweigung, indem der Parameter del heruntergezählt wird
(Produktion p7). Ist del gleich Null, tritt Produktion p8 in Kraft. Diese Produktion initiert eine
neue Verzweigung mit den im Branch Modul gespeicherten Parametern ruleAttr und roadAttr.
Wie beim Rule Modul, wird auch hier der Parameter del (zusätzlich) zur Überprüfung der Exis-
tenz einer Strasse verwendet (Produktion p9): falls del < 0 ist, wird die Verzweigung nicht ini-
tiert.
4.2 Global Goals
Die Funktion globalGoals setzt die Initialwerte der Strassenmodule, indem alle aktiven Rules
aufgerufen werden. Die Vorschläge jeder Rule werden entsprechend den Gewichten der Rules
in einem einzelnen Vorschlag vereinigt. Das Gewicht bzw. der Einfluss einer Rule wird über ihr
Kontrollbild bestimmt. Mit einer Rule kann das Erscheinungsbild eines Strassennetzwerkes
kontrolliert werden, indem sich die Strassen dem von der Rule implementierten Strassenmuster
anpassen. Abbildung 4.2 zeigt mögliche Strassenmuster (aus [7]). Eine Rule schlägt maximal
drei neue Strassen für das Template vor: Eine Strasse ungefähr geradeaus, eine Strasse ungefähr
nach links und eine Strasse ungefähr nach rechts.
4.2.1 Western Rule
In [10], kategorisiert Füsser Strassen in zwei Klassen: Hauptstrassen (Highways) und siedlungs-
orientierte Nebenstrassen (Streets). Ausserdem vergleicht er das Auftreten von rasterartigen
Mustern mit dem von radialen Mustern: Erstere treten vor allem in polyzentrischen Städten auf

13. 28 4. ERZEUGUNG DER STRASSENNETZWERKE
Abbildung 4.2: Eine Auswahl von möglichen Strassenmustern.
und radiale Muster findet man eher in monozentrischen Städten. Highways können beide Arten
von Mustern repräsentieren, Streets hingegen treten nur in raster- bzw. schachbrettförmigen
Strassenmustern auf. Deshalb bestehen die Strassennetze solcher Städte aus verschiedensten,
beliebig zueinander angeordneten Schachbrettmustern mit unterschiedlichen Häuserblock-
flächen. Die Grenzen zwischen diesen Mustern bilden Highways, die die Gleichförmigkeit der
Muster unterbrechen [16]. Die Western Rule erzeugt derartige Strassenmuster.
Wie weiter oben bereits erwähnt, verbinden die Highways Zentren hoher Populationsdichte
miteinander. Die Western Rule korrigiert den Winkel eines Highway so, dass dieser der gröss-
ten Populationsdichte folgt. Die Western Rule bestimmt diese Richtung, indem innerhalb des
benutzerdefinierten Bereiches Strahlen mit zufällig geänderten Winkeln die ideale Route
suchen. Entlang dieser Strahlen wird die Populationsdichte abgetastet. Jeder Wert wird mit der
inversen Distanz gewichtet und aufsummiert. Die Richtung mit der grössten Summe wird
schlussendlich vom Highway eingeschlagen. Abbildung 4.3 illustriert den Vorgang. Findet eine
reine Highway-Verzweigung statt, wird dieser ein Wert mitgegeben (ruleAttr.branchDistance),
der die Distanz bis zur nächsten Verzweigungen darstellt (gleich wie im L-System für die Wur-
zeln in 2.7). Der Benutzer definiert sämtliche Parameter wie Längen, Winkel oder Wahrschein-
lichkeiten (alle mit Standardabweichung).
Abbildung 4.3: Links: Ein Strahl sucht die Richtung der höchsten Population.
Rechts: Ein generiertes Highwaynetzwerk, das die Populations-
zentren miteinander verbindet.
Im Gegensatz zu den Highways folgen Streets nicht der grössten Populationsdichte, sondern
einem Schachbrettmuster. Dieses wird durch Highways initiert, die nach links oder rechts eine
Street-Verzweigung produziert haben. Dabei wird die Länge der Street und die Blockfläche des
Schachbrettmusters (ruleAttr.area) bestimmt und für das L-System wird eine Verzögerung
bestimmt, damit die Highways zuerst ihre Gebiete erschliessen können. Durch eine Länge und
die Fläche ist das Aussehen des Schachbrettmusters festgelegt, und, nachdem der Delay runt-
ergezählt wurde, beginnt das Schachbrettmuster zu wachsen. Der Benutzer kann bestimmen,
wie regelmässig dieses aussehen soll. Wird eine Street eingefügt, dekrementiert sie an dieser
Stelle die Population in einem Diffusionssystem mittels finiten Differenzen (gleich wie im
L-System für die Wurzeln in 2.7). Sobald Streets auf Zonen ohne Population stossen, stoppt das

14. 4.2 GLOBAL GOALS 29
Wachstum. Alle oben erwähnten Parameter kann der User kontrollieren. Abbildung 4.4 zeigt
links den Strassenplan von San Francisco, auf dem zwei aufeinandertreffende Schachbrett-
muster dargestellt sind. Rechts in der Abbildung wird ein mit der Western Rule generiertes
Strassennetz gezeigt.
Abbildung 4.4: Western Rule. Links: Ein Strassennetzausschnitt von San Francisco.
Rechts: Ein generiertes Strassennetz.
4.2.2 Grid Rule
Über die mit der Western Rule erzeugten Schachbrettmuster der Streets hat der Benutzer wenig
Kontrolle, zumindest was deren Orientierung betrifft. Deshalb wurde die Grid Rule implemen-
tiert. Highways und Streets verhalten sich hier nur noch nach geometrischen Regeln. Der
Benutzer hat Kontrolle über das Schachbrett, indem er Position, Orientierung und Strassen-
längen mit Standardabweichungen eingeben kann. Sind diesen Parametern Werte zugewiesen,
wird das Gitter vollständig initialisiert. Die Strassen wachsen auf ähnliche Weise wie in der
Western Rule, nur gibt es keine Winkelabweichungen und die Strassenenden schnappen auf die
Gitterpunkte ein. Abbildung 4.5 zeigt links das berühmte Strassennetz von Manhattan. Rechts
in der Abbildung sieht man eine mit der Grid Rule generierte Rekonstruktion dieses Strassen-
netzwerkes.
Abbildung 4.5: Grid Rule. Links: Ein Strassennetzauschnitt von Manhattan (NYC).
Rechts: Ein generiertes Strassennetz (auch von Manhattan).
4.2.3 Radial Rule
Neben der Grid Rule existiert noch eine zweite geometrische Rule: die Radial Rule. Diese Rule
erzeugt die in Abbildung 4.2 illustrierten radialen bzw. konzentrischen Strassenmuster. Solche

15. 30 4. ERZEUGUNG DER STRASSENNETZWERKE
Strassenmuster sind vor allem in europäischen Städten zu finden (Paris, Brüssel). Dieses Stras-
senmuster hat ähnliche Charakteristika wie das der Western Rule. Auch hier werden die schach-
brettartigen verteilten Streets von den Highways unterbrochen [10]. Aus diesem Grund
verhalten sich die Streets in dieser Rule gleich wie diejenigen der Western Rule. Die Highways
werden, je nachdem wie ihr Winkel zum Zentrum ist, entweder in tangentiale oder radiale Rich-
tung gelenkt. Das Zentrum der Ringstrassen wird vom Benutzer definiert. Abbildung 4.6 zeigt
links einen Strassenplan des Zentrums von Paris, rechts ein mit der Radial Rule erzeugtes
Strassennetzwerk.
Abbildung 4.6: Radial Rule. Links: Ein Strassennetzausschnitt von Paris. Rechts:
Ein generiertes Strassennetz.
4.2.4 Topographical Rule
Die Strassenmuster von europäischen Städten reflektieren oft deren Topographie, indem die
grösseren Strassen den Höhenlinien folgen [16]. Diese Eigenschaft wird mit der Topographical
Rule simuliert, die wie die beiden geometrischen Rules auf der Western Rule basiert. Die High-
ways und die längeren Streets eines Schachbrettmusters folgen der geringsten Steigung. Kür-
zere Streets eines Schachbrettmusters folgen der grössten Steigung, falls diese nicht zu steil ist.
Ein weiterer Unterschied zu Western Rule besteht darin, dass Highways, wenn sie sich ver-
zweigen, meistens nur eine anstatt zwei Verzweigungen generieren. Das topographische Ver-
halten wird an einer Position erst aktiviert, wenn eine minimale Steigung im Gelände vorhanden
ist (und das Kontrollbild aktiv ist). Ist die Steigung in diesem Punkt kleiner als der vom
Benutzer definierte Schellwert, verhält sich die Topographical Rule gleich wie die Western
Rule. Abbildung 4.7 zeigt links das Strassennetzwerk von Zürich (aus [16]), indem anhand der
Strassen erkennt werden kann, wie das Gelände rechts neben dem Fluss aufsteigt. Rechts in
Abbildung 4.7 ist Strassennetzwerk abgebildet, das nur mit der Topographical Rule erzeugt
wurde. Man kann deutlich erkennen wie in den flacheren Regionen das Western Rule Verhalten
aktiv war.
4.2.5 Blending
Falls an einer Position mehrere Rules aktiv sind (Kontrollbildwert > 0), werden zuerst alle
aktiven Rules einzeln ausgewertet. Die vorgeschlagenen Parameter der Rules werden anschlies-
send entsprechend ihrem Kontrollbildwert gewichtet und aufsummiert. Der folgende
Pseudocode illustriert das Blending der Rules:

16. 4.2 GLOBAL GOALS 31
Abbildung 4.7: Topographical Rule. Links: Ein Strassennetzausschnitt von Zürich.
Rechts: Ein auf das Gelände projiziertes generiertes Strassennetz.
// 1. Which branches in template exist?
foreach Branch
w = 0
foreach Rule
if rule.branch exists
w += rule.w
else
w -= rule.w
if w > 0
branch exists
// 2. Is it a Highway or a Street?
foreach Branch which exists
wHighway = wStreet = 0
foreach Rule
if rule.branch exists
if rule.branch.type == “HIGHWAY”
wHighway += rule.w
else
wStreet += rule.w
if wHighway > wStreet
branch.wSum = wHighway
branch.type = “HIGHWAY”
else
branch.wSum = wStreet
branch.type = “STREET”
// 3. Blend the rules
foreach Branch which exists
branch.par = {0,..,0}
foreach Rule
if rule.branch exists && rule.branch.type == branch.type
branch.par += rule.branch.par * rule.w / branch.wSum
Im ersten Teil des Codes wird überprüft, welche der drei Branches, die das L-System Tem-
plate zur Verfügung stellt, existieren (da eine Rule nicht immer alle drei Branches vorschlägt).
Dies wird für jeden der drei Branches einzeln entschieden, indem das Gewicht (Kontrollbild-

17. 32 4. ERZEUGUNG DER STRASSENNETZWERKE
wert) jeder aktiven Rule aufsummiert resp. subtrahiert wird. Ist der resultierende Wert grösser
als Null, existiert der Branch.
Anschliessend wird für alle existierenden Branches überprüft, ob es sich um einen Highway
oder um eine Street handelt. Dies funktioniert ähnlich wie oben, nur werden hier zwei Gesamt-
gewichte mitgeführt, da diese im dritten Teil, dem Blending, wiederverwendet werden.
Nachdem für jeden Branch bestimmt wurde, ob er existiert und welchen Strassentyp er hat,
findet das Blending für jeden Branch statt (falls dieser existiert). Dabei haben nur noch die-
jenigen Rules Einfluss, die einen Branch vorgeschlagen haben (rule.branch exists) und den
entsprechenden Strassentyp unterstützen. Mit den im zweiten Teil berechneten Gesamtgewicht
werden (pro Branch) die vorgeschlagenen Parameter einer Strasse wie Winkel, Länge, etc.
linear geblendet. Abbildung 4.8 zeigt ein Blending der beiden geometrischen Regeln.
Abbildung 4.8: Blending von Rules. Links oben das Kontrollbild der Grid-Rule,
links unten das der Radial-Rule und rechts das resultierende Stras-
sennetzwerk.
4.3 Local Constraints
Die Strassenparameter, die die Funktion globalGoals vorgeschlagen hat, werden von der Funk-
tion localConstraints entsprechend der lokalen Umgebung justiert. Wenn immer ein Spezialfall
auftaucht, wenn beispielsweise eine Strasse auf Wasser trifft, wird dies durch den umgebungs-
sensitiven Teil der Funktion erkannt, und falls möglich, werden die Parameter geändert.
Anschliessend muss überprüft werden, ob die (evtl. justierte) Strasse auf eine Andere trifft und
eine Kreuzung gebildet werden muss. Dazu wurden L-Systeme um die Fähigkeit erweitert,
Intersektionen mit schon bestehenden Ästen zu erkennen. Es entstanden die selbstsensitiven
L-Systeme. Die selbstsensitive Überprüfung, die immer nach der Umgebungssensitiven stat-
tfindet, bestimmt die definitiven Parameter einer Strasse. Konnte die Strasse in die Umgebung
eingefügt werden, wird dies via Parameter state des Insertion Moduls dem L-System mitgeteilt.
4.3.1 Umgebungssensitivität
Nachdem von den Rules eine Strasse vorgeschlagen wurde, passt die umgebungssensitive Über-
prüfung die Strasse der lokalen Umgebung an. Bei einer einzufügenden Strasse liegt der Stras-
senbeginn immer auf Land. Liegt das Strassenende im Wasser, in einem Park oder einer anderen
illegalen Zone, wird versucht, die Strasse, bzw. deren Parameter, zu justieren:
• Die Länge der Strasse wird solange bis zu einem gewissen Faktor gekürzt, bis das Stras-
senende in einer legalen Zone liegt.

18. 4.3 LOCAL CONSTRAINTS 33
• Misslingt dies, wird versucht, den Winkel der Strasse (mit ihrer vorgeschlagenen Länge)
solange bis zu einem Maximalwinkel zu verändern, bis das Strassenende in einer legalen
Zone liegt.
Diese Überprüfungen werden für Streets und Highways gleichermassen durchgeführt. Schlagen
aber beide Versuche der Justierung fehl, werden die beiden Strassenarten unterschiedlich
behandelt: Streets werden verworfen, indem der Parameter state des Insertion Moduls auf
FAILED gesetzt wird, womit die localConstraints Überprüfung beendet ist. Highways ist es
hingegen erlaubt, Wasser zu überqueren und so Brücken zu bauen, indem durch Längen- und
Winkeländerungen das andere Ufer gesucht wird. Falls dies gelingt, wird der Highway mar-
kiert. Für Streets ist die umgebungssensitve Adjustierung nun abgeschlossen und die Strasse
muss nur noch im selbstsensitiven Teil auf Kreuzungen untersucht werden. Die ersten beiden
Spalten von Abbildung 4.9 illustrieren die Überprüfung
Da ein Highway oft einer Küste entlang verläuft [16], wird dieser, falls bisher keine Para-
meteränderungen stattgefunden haben, zusätzlich überprüft:
• Befindet sich vor dem Strassenende Wasser, wird der Winkel des Highways in Richtung
Küste geändert (obwohl sich der Highway auf legalem Gebiet befindet).
• War dies nicht der Fall und befindet sich neben dem Highway Wasser, wird der Winkel
leicht in Richtung Wasser geändert (obwohl sich der Highway auf legalem Gebiet befin-
det).
Die erste Überprüfung verhindert oft, dass Highways in Sackgassen enden. Jetzt können auch
die (evtl. justierten) Parameter eines Highways der selbstsensitiven Überprüfung übergeben
werden. Die beiden rechten Spalten von Abbildung 4.9 zeigen die Adjustierung der Highways.
Abbildung 4.9: Umgebungssensitives Einfügen von Strassen. Oberen Reihe: Von
den Rules vorgeschlagene Strassen. Untere Reihe: Nach der Adjus-
tierung.
4.3.2 Selbstsensitive L-Systeme
Da L-Systeme ursprünglich zur Generierung von Pflanzen entwickelt wurden, können mit den
bestehenden L-Systemen nur verzweigende Strukturen erzeugt werden. Transport- oder Kom-
munikationssysteme haben aber die Eigenschaft, dass sie zusammenwachsen und geschlossene
Zyklen bilden (in einem Verkehrssystem beispielsweise sind Sackgassen die Ausnahme [7]).
Deshalb wurden die selbstsensitiven L-Systeme entwickelt (ein ähnlicher Lösungsansatz wurde
für die prozedurale Generierung von Blutbahnen verwendet [19]): Eine neue Verzweigung kann
auf ein Segment des schon bestehenden L-Systems treffen, die Kollision erkennen, sich
“verbinden” und so einen Zyklus bilden. Dadurch ändert sich die Topologie von einer baum-
artigen zu einer netzwerkartigen Struktur. Weil der Erzeugung vom Strassennetzwerk kein