heruntergeladen werden - cpe - Universität Kaiserslautern

3D-City-Models in Time 

Erstellung und Nutzen von 3D-Stadtmodellen mit zusätzlichen 

Zeitdimensionen für die Planung am Beispiel des Stadtkerns 

von Kaiserslautern 

Tony Poesch

TU Kaiserslautern 

CPE – Computergestützte Planungs‐ und Entwurfsmethoden in Städtebau und 

Architektur 

Fachbereich Architektur / Raum‐ und Umweltplanung /Bauingenieurwesen 

Gebäude 1 

Pfaffenbergstraße 95 

67663 Kaiserslautern, Deutschland 

Tel. +49 0631‐205‐3951 

Internet: http.//cpe.arubi.uni‐kl.de 

Diplomarbeit: 

3D‐City‐Models in Time 

Erstellung und Nutzen von 3D‐Stadtmodellen mit zusätzlichen Zeitdimensionen 

für die Planung am Beispiel des Stadtkerns von Kaiserslautern 

Betreuung: 

Prof. Dr.‐Ing. Bernd Streich 

Dipl.‐Ing. Peter Zeile

Verfassererklärung 

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig verfasst und 

die Übernahme wörtlicher Zitate aus der Literatur sowie Verwendung der Ge‐ 

danken anderer Autoren an entsprechender Stelle innerhalb der Arbeit gewür‐ 

digt habe. Diese Arbeit ist bisher weder veröffentlicht, noch einer sonstigen 

Prüfungsbehörde vorgelegt worden. 

Ich bin mir bewusst, dass eine falsche Erklärung das Aberkennen der Prüfungs‐ 

leistung zur Folge haben kann. 

Tony Poesch 

Mehlbach, September 2009

Danksagung 

An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich in der ganzen Zeit 

meines Studiums unterstützt haben. Allen voran möchte ich meiner Familie und meiner 

Freundin Sabrina Wetz für ihre umfangreiche Hilfe und Unterstützung sowie ihren Beistand 

während meines Studiums danken. Ohne sie wäre Vieles überhaupt nicht möglich gewesen. 

Weiterhin möchte ich speziell meinem Bruder und seiner Frau Rebekka für ihre Unterstüt‐ 

zung danken. 

Ein besonderer Dank gilt Herrn Prof. Streich und Herrn Peter Zeile für ihre Betreuung und 

fachliche Beratung während meiner Diplomarbeit, aber auch für die Jahre davor, als ich noch 

als Hilfswissenschaftlicher Mitarbeiter im Lehrgebiet CPE angestellt war. Erst durch diese 

Zeit, in der ich viel gelernt habe, war es mir möglich diese Diplomarbeit zu schreiben. Wei‐ 

terhin möchte ich Herrn Ralph Schildwächter danken, der mir vieles beigebracht hat und 

meine Kenntnisse in der computergestützten Planung förderte. 

Abschließend möchte ich allen Freunden und Bekannten danken, für jede Form der Hilfe die 

ich durch sie in den Jahren meines Studiums erfahren durfte. Danke an alle.

Inhaltsverzeichnis 

1. Einleitung 2 

1.1 Einordnung des Themas 2 

1.2 Anlass und Motivation 2 

1.3 Ziele der Arbeit 4 

1.4 Methodik und Aufbau der Arbeit 5 

2. Grundlagen der 3D‐Stadtmodelle 7 

2.1 Entwicklung der 3D‐Stadtmodelle 7 

2.2 Visualisierungstechniken 14 

2.2.1 Halbinteraktive Viewer 14 

2.2.2 Virtuelle Globen 16 

2.2.3 3D‐Stadtmodelle in VRML 19 

2.2.4 Digitale Stadtmodelle aus der Unterhaltungsindustrie 20 

2.2.5 Engine‐basierte 3D‐Stadtmodelle 25 

2.2.6 Interaktive 3D‐Stadtmodelle in der Planung 27 

2.3 Zwischenfazit 30 

3. Historische Stadtmodelle 31 

3.1 Analoge Stadtmodelle 31 

3.2 Bestehende historische 3D‐Stadtmodelle 35 

3.3 Bedeutung für die Planung 41 

3.4 Zwischenfazit 43 

4. 3D‐Stadtmodell Kaiserslautern 44 

4.1 Reeller Anlass 44 

4.2 Arbeitsablauf 45 

4.3 Geschichte der Stadt 46 

4.4 Datengrundlagen allgemein 60 

4.5 Datengrundlagen Kaiserslautern 61 

4.6 Zwischenfazit und Festlegung des LOD 70 

4.7 Erstellung des 3D‐Stadtmodells 72 

4.8 Inhalte und technische Möglichkeiten 95 

4.9 Einsatzfelder und Weiterbearbeitung 96 

5. Fazit und Ausblick 99 

5.1 Probleme und Hindernisse 99 

5.2 Entwicklung und offene Fragen 106 

5.3 Zusammenfassung 111 

6. Anhang 114 

6.1 Glossar 114 

6.2 Abbildungsverzeichnis 117 

6.3 Literaturverzeichnis 120

3D‐City‐Models in Time 

Erstellung und Nutzen von 3D‐Stadtmodellen mit zusätzlichen Zeitdimensio‐ 

nen für die Planung am Beispiel des Stadtkerns von Kaiserslautern

2 1. Einleitung 

1. Einleitung 

1.1 Einordnung des Themas 

3D‐Stadtmodelle haben in den letzten Jahren eine Entwicklung vom belächelten Prototypen 

zum funktionalen Instrument der Planung vollzogen. Ihr Einsatzfeld ist gewachsen, und die 

technischen Möglichkeiten vergrößern ihr Potential immer mehr. In den verschiedensten 

Bereichen werden mit Hilfe des Computers unterschiedlichste Modelle erstellt, die es dem 

Nutzer ermöglichen, eine virtuelle Realität zu erleben und für den Menschen unzugängliche 

Blickwinkel und Sichtweisen einzunehmen. Weiterhin sind 3D‐Stadtmodelle durch ihr digita‐ 

les Wesen ein praktikables Instrument, um Daten mit einer hohen Diversität zusammenzu‐ 

führen und übersichtlich, mit einem Mehrwert darzustellen. Das bedeutet, dass komplexe 

Daten durch fortschrittliche Visualisierung besser erfasst, verarbeitet und zu Informationen 

umgewandelt werden können. Im Bezug auf die Planung bedeutet dies, dass verschiedene 

Aspekte wie gestalterische Belange, technische Probleme oder Öffentlichkeitsbeteiligung in 

einem interaktiven und erlebbaren Modell werden zu einer projektunterstützenden Anwen‐ 

dung zusammengeführt. 

Konkret stellen 3D‐Stadtmodelle bis jetzt vor allem im Bereich der Planungsvisualisierung, 

der Öffentlichkeitsbeteiligung in der Planung und der Vermarktung von Planungen ein neues 

Instrument dar. Dieses erfährt eine wachsende Verbreitung und Bedeutung. Das heißt, 3D‐ 

Stadtmodelle haben elementare Bereiche der Planung erschlossen und stellen eine Alterna‐ 

tive zu haptischen Modellen oder zweidimensionalen analogen Plänen dar. Die Einsatzfelder 

und der Mehrwert eines solchen Modells sind aber nicht auf die Planung beschränkt, son‐ 

dern erschließen auch neue Formen der Präsentation für Kommunen. Im Sinne von Stadt‐ 

marketing und Imagebildung von Städten können diese Modelle auch im touristischen Be‐ 

reich einen wertvollen Beitrag leisten. Städte können sich digital aus den verschiedensten 

Blickwinkeln präsentieren und dem Adressaten Informationen vermitteln, die der Stadt und 

dem Adressaten nutzen.

1.2 Anlass und Motivation 


Die Entwicklung der Computertechnologie seit den 1990er‐Jahren hat zu einer „Computeri‐ 

sierung der Planung“ geführt. Vor allem die Bereiche Planvisualisierung und Öffentlichkeits‐ 

arbeit waren seit Mitte der 1990er‐Jahre zunehmend betroffen. Erst in der Forschung, dann 

mit der Computerrevolution auch in der Praxis [vgl. ZEILE, 2004]. Ein Ergebnis sind 3D‐ 

Stadtmodelle. Sie sind der Versuch von Planern und Entscheidungsträgern von Planungen, 

einen Raum realitätsnah oder auch gewollt abstrahiert digital abzubilden und im Sinne einer 

Analyse oder als Ergebnis darzustellen und erfahrbar zu machen. Die Methoden, Techniken 

und Wege, die dabei verwendet wurden, waren zahlreich und mehr oder weniger von Erfolg 

gekrönt. Verschiedene Dinge sind aber weitgehend gleich geblieben: die Absicht, die Model‐ 

le in einem immer höheren Detailgrad zu fertigen und sie in der Gegenwart oder in der Zu‐ 

kunft, also einer Planung, anzusiedeln. Das heißt, man hat versucht, die momentane oder 

eine zukünftige Realität zu modellieren. Die zukünftige Realität in einem Modell wird von 

Parametern bestimmt, die der Planer prognostiziert oder festgelegt. Kurz: Es werden Dinge 

visualisiert, die nicht oder nur teilweise vorhanden sind. Das macht das Potenzial von 3D‐ 

Stadtmodellen besteht darin, nicht existente Dinge in der Gegenwart zu visualisieren und 

erlebbar zu machen. Doch das Potential ist weit größer, denn nur wenige Beispiele haben 

dieses Instrument 3D‐Stadtmodelle in die Vergangenheit gerichtet, haben in 3D‐ 

Stadtmodellen historische Daten visualisiert. Die technischen Möglichkeiten befähigen heute 

zu einer Rekonstruktion der Vergangenheit einer Stadt, eines Stadtteils und damit zur Visua‐ 

lisierung von bedeutsamem Kulturgut, was erstens gesetzlich abwägungsrelevant ist und 

zweitens für die Öffentlichkeit von großem Interesse ist. 

Die Stadt Kaiserslautern befindet sich zum Zeitpunkt der Diplomarbeit im politischen und 

planerischen Diskurs über eine planerische Neugestaltung des stark historisch geprägten 

Stadtkerns und eine Aufwertung der historischen Bausubstanz. Weiterhin soll durch eine 

solche Aufwertung das touristische Potential des Stadtkerns verbessert werden. Die Stadt 

Kaiserslautern verfügt bereits über 3D‐Daten des zu beplanenden Areals sowie über ein 3D‐ 

Stadtmodell. Das sich daraus ergebende Potential eines digitalen historischen Stadtmodells 

ist sehr groß, bringt jedoch auch große technische, methodische und projektbedingte 

Schwierigkeiten mit sich.


1.3 Ziele der Arbeit 

Ausgehend vom konkreten Beispiel der Stadt Kaiserslautern soll aufbauend auf den theoreti‐ 

schen Grundlagen der 3D‐Stadtmodelle ein detailiertes 3D‐Stadtmodell des Stadtkerns von 

Kaiserslautern erstellt werden. Dieses Modell soll zudem mehrere Zeitdimensionen haben, 

d.h. das Areal des Stadtkerns soll zu verschiedenen Zeitpunkten der Geschichte visualisiert 

werden, die entweder aus historischer oder planerischer Sicht bedeutsam sind. Um einen 

Rahmen für den Arbeitsaufwand zu schaffen, wird die Anzahl der Visualisierungszeitpunkte 

im Vorfeld auf drei begrenzt. Weiterhin soll das Modell einen hohen Detaillierungsgrad be‐ 

sitzen, der den momentanen Stand der Technik auf diesem Gebiet widerspiegelt. Zudem soll 

das Modell eine Basis für mögliche Erweiterungen darstellen und Metadaten mit Informatio‐ 

nen beinhalten. Letztere sollen als Beispiel für ein mögliches Touristeninformationssystem 

dienen. 

Die Arbeit befasst sich mit den bestehenden und neuen Techniken zur Erstellung dreidimen‐ 

sionaler Stadtmodelle sowie den gängigen Datengrundlagen. Neben diesem Themenfeld 

sollen mögliche Softwarelösungen, welche für die Erstellung in Frage kommen, untersucht 

werden. Es soll die Machbarkeit solcher Modelle eruiert werden sowie ihr Nutzen für die 

Planung. Dabei stellt sich die Frage der Effizienz im Rahmen einer Einbindung in die Pla‐ 

nungsprozesse: Kann ein solches Modell den Planungsprozess unterstützen, und welches 

Aufwand‐/Nutzen‐Verhältnis stellt sich dabei ein? Welchen Nutzen kann ein solches Modell 

in einer möglichen Öffentlichkeitsbeteiligung haben? Welche Akzeptanz hat ein solches Mo‐ 

dell bei Planern, Entscheidungsträgern und der Öffentlichkeit? 

Diese Fragen sollen bei der Erstellung des Modells beantwortet werden und den Fertigungs‐ 

prozess begleiten. 

Bei der Erstellung sollen möglichst aktuelle Technologien und Techniken eingesetzt werden, 

welche den momentanen Stand der Technik widerspiegeln und gleichzeitig einen nachvoll‐ 

ziehbaren und effizienten Workflow garantieren. Daneben soll das Modell daraufhin abzie‐ 

len, im Hinblick auf multiple Einsatzfelder Anwendungsmöglichkeiten einen möglichst hohen 

Mehrwert [vgl. ZEILE, 2004] zu bieten. Neben der Erstellung des Modells bildet die finale 

Visualisierung, also die Zusammenführung der Modelle in eine interaktive Anwendung, einen 

wichtigen Bestandteil der Arbeit. Dabei liegt das Hauptaugenmerk darauf, das Modell einem 

breiten Publikum mit einer hohen Darstellungsqualität in Bezug auf die Darstellungsperfor‐ 

mance verfügbar zu machen, ohne die Editierbarkeit einzuschränken. 

Ein weiterer Teil der Arbeit soll die Darstellung der technischen und thematischen Probleme 

bei der Erstellung eines historischen Stadtmodells sein, um zukünftige Projekte im Sinne der 

Forschung zu unterstützen und einen nachvollziehbaren Workflow aufzuzeigen. Daneben 

werden neue Technologien und Trends beleuchtet, die bestehende Probleme lösen oder 

auch verschlimmern.

1.4 Methodik und Aufbau der Arbeit 

Nachfolgend sollen die Methodik und der Aufbau der Arbeit beschrieben werden. 


Aus der Zielsetzung ergibt sich die Unterteilung der Arbeit in einen theoretischen und einen 

praktischen Teil. Der theoretische Teil beschäftigt sich in der Einleitung mit Zielsetzung und 

Methodik. Es folgt eine analytische Bestandsaufnahme der Entwicklung der 3D‐ 

Stadtmodelle. Anschließend wird auf verschiedene Visualisierungstechniken eingegangen, 

um einen Überblick zu geben über die technischen Möglichkeiten sowie deren Stärken und 

Schwächen. 

Nach diesem Grundlagenteil der Technik folgt ein Kapitel, welches sich mit dem Bezug histo‐ 

rischer Stadtmodelle zur Planung beschäftigt. Dabei wird auf die Bedeutung der Historie ei‐ 

nes Ortes, die Notwendigkeit von historischen Modellen und auf bestehende digitale histori‐ 

sche Modelle eingegangen. Dieses Kapitel wird versuchen, die Verbindung zwischen Stadt‐ 

baugeschichte, Planung und dem Einsatz von digitalen Stadtmodellen herzustellen. 

Man kann die drei ersten Teile der Theorie zu einem analytischen Theorieteil zusammenfas‐ 

sen. Methodisch wird dabei auf Literatur‐ und Internetrecherche sowie die persönliche Er‐ 

fahrung des Autors zurückgegriffen. 

Kapitel 4 nimmt direkten Bezug auf den praktischen Teil der Arbeit, also die Erstellung des 

interaktiven Stadtmodells mit historischen Inhalten. Er stellt die vorbereitenden Arbeits‐ 

schritte und den eigentlichen Fertigungsablauf des Modells dar. Die vorbereitenden Arbeits‐ 

schritte untersuchen den Status Quo des abzubildenden Ortes, dem Stadtkern von Kaisers‐ 

lautern und dessen historische Entwicklung. Zunächst erfolgt eine genauere Schilderung der 

tatsächlichen Planungssituation des Stadtkerns, welche schon im Kapitel 1.2 erwähnt wurde. 

Im nachfolgenden Teil wird zusätzlich auf die Geschichte der Stadt eingegangen, da diese 

von großer Bedeutung für das Verständnis der Stadtentwicklung und der Bemessung der 

Bedeutung des Stadtkerns ist. 

Anschließend werden die vorhandenen Daten im Sinne einer bewertenden Datengrundla‐ 

generfassung untersucht. Dieser Teil behandelt die Ausstattung der Stadt mit bestehenden 

analogen und digitalen Daten, welche für die Erstellung eines Stadtmodells in Frage kom‐ 

men. 

Im folgenden Hauptteil wird dann die Erstellung des Stadtmodells dokumentiert und gleich‐ 

zeitig auf Anforderungen desselben eingegangen. Danach werden die Inhalte des Modells 

und weitere technische Möglichkeiten in direktem Bezug auf das Modell untersucht. 

Den vierten Teil abschließend werden die möglichen Anwendungsfelder und die mögliche 

Entwicklung und Weiterbearbeitung des Stadtmodells diskutiert. 

Nach der Dokumentation des Erstellungsprozesses wird dieser im Sinne einer Evaluation 

kritisch hinterfragt und auf Probleme und Hindernisse eingegangen. Weiterhin sollen zukünf‐ 

tige Entwicklungen und technische Innovationen sowie deren Auswirkung im thematischen 

Kontext der digitalen historischen Stadtmodelle diskutiert werden.


Die folgende Abbildung visualisiert den Aufbau der Arbeit noch einmal um ein besseres Ver‐ 

ständnis zu fördern: 

Einleitung 

Diagramm 1: Aufbau der Arbeit (eigene Darstellung) 

•Einordnung des Themas 

•Anlass und Motivation 

•Ziele der Arbeit 

•Methodik 

Grundlagen Teil 1 

3D‐Stadtmodelle allgemein 

•Entwicklung 

•Techniken 

•Beispiele 

Grundlagen Teil 2 

Historische Stadtmodelle 

•analoge Modelle 

•digitale historische Modelle 

•Bedeutung 

Modellerstellung 

•Anlass 

•Grundlagen 

•Erstellungsprozess 

•Einsatzfelder 

Fazit und Ausblick 

•Probleme 

•Entwicklung 

•Zusammenfassung

2. Grundlagen der 3D‐Stadtmodelle 

2.1 Entwicklung der 3D‐Stadtmodelle 


Der Begriff 3D‐Stadtmodelle setzt sich aus drei Teilen zusammen: erstens dem Kürzel 3D, 

welches die Eigenschaft der dreidimensionalen Geometrie eines solchen Modells verdeut‐ 

licht, zweitens dem Teil „Stadt“, welcher Bezug nimmt auf den geografischen und themati‐ 

schen Umriss des abzubildenden Objekts und drittens dem Teil „Modell“, welcher die Eigen‐ 

schaft der Modellhaftigkeit des Objekts, welches abgebildet werden soll, hervorhebt. 3D‐ 

Stadtmodelle stellen also eine dreidimensionale, modellhafte Abbildung des realen Raums 

einer Stadt dar. Das bedeutet, dass eigentlich auch haptische, handgefertigte Modelle aus 

Holz, Pappe etc. 3D‐Stadtmodelle gemäß dieser Definition wären. In der Regel meinen Ex‐ 

perten heute damit aber ein digitales, also ein computergestützt erstelltes, 3D‐Modell der 

Realität, mit der geografischen und thematischen Abgrenzung zum Kontext einer Stadt, ei‐ 

nes Stadtteils oder des Teils eines Quartiers hin. Wann die ersten digitalen 3D‐Stadtmodelle 

genau entstanden sind, ist unklar und bedarf einer eigenen Untersuchung, die hier nicht vor‐ 

genommen werden soll. Genauer datierbar ist aber, wann die ersten interaktiven Echt‐ 

zeit/Realtime‐Stadtmodelle aufkamen. 

Definition: Echtzeit‐/Realtimemodell (eigene Definition) 

Ein Echtzeitmodell ist ein interaktives Modell, in welchem der Benutzer aus der Ich‐ 

Perspektive oder einer andern Perspektive eine dreidimensionale, virtuelles Abbild der Welt 

erleben kann, wobei der Computer die darzustellenden Daten des 3D‐Modells sowie die Be‐ 

wegungen des Nutzers permanent in Echtzeit neu berechnet. Es werden also keine vorgefer‐ 

tigten Bildsequenzen verwendet [vgl. www.techterms.com]. 

Defintion: Rendern/Animationsfilm (eigene Definition) 

Die Produktion von vorgefertigten Bildsequenzen zu einem Animationsfilm nennt sich Ren‐ 

dern. Dazu werden mit Hilfe von Computern und einer entsprechenden Software 3D‐ 

Modelle zu Bildern umgerechnet. Durch aneinanderreihen der Einzelbilder entsteht eine 

Animation [vgl. www.itwissen.info]. 

Während die wissenschaftliche Nutzung erst um den Jahrtausendwende begann, gab es in 

der Unterhaltungsindustrie schon wesentlich früher Modelle von Städten, die interaktiv er‐ 

lebbar waren und Gebäudegeometrien mit Texturen darstellten Als Beispiele seien an dieser 

Stelle die Spiele „Need for Speed 2“ (Electronic Arts, 1997) und „Halflife“ (Valve, 1998) ge‐ 

nannt, welche schon damals detaillierte Gebäudemodelle mit Texturen darstellen konnten. 

2002 wurde dann in einem Forschungsprojekt die Erstellung eines 3D‐Modells der histori‐ 

schen Innenstadt von Bamberg angestoßen [vgl. POESCH, SCHILDWÄCHTER, ZEILE 2004]. Das 

Ergebnis war eines der ersten wissenschaftlichen 3D‐Stadtmodelle. Seither hat die Verbrei‐ 

tung solcher Modelle stark zugenommen, und auch die Entwicklung der Technik hat die Mo‐ 

delle dahin gehend verändert, dass sie immer detaillierter und realitätsnaher wirken [vgl. 

www.wapedia.mobi].

8 2. Grundlagen der 3D‐Stadtmodelle 

Abbildung 1: 3D‐Stadtmodell Bamberg in der Anwendung Quest3D (Schildwächter Ingenieure, 2005) 

Auch die Planung profitiert zunehmend von den 3D‐Stadtmodellen. Durch die dreidimensio‐ 

nale Visualisierung von Planungen können Planer ihre Ideen Entscheidungsträgern und Be‐ 

teiligten aus der Öffentlichkeit wesentlich besser kommunizieren. In solchen Modellen kön‐ 

nen Gestaltungsvorschläge von Planungen besser vermittelt werden, da der Nutzer unge‐ 

wöhnliche Perspektiven einnehmen kann sowie Planungsvarianten dynamisch miteinander 

vergleichen kann [STREICH, 1996 in ZEILE, 2004]. Weiterhin sind dadurch eine bessere Ver‐ 

breitung und damit die Beteiligung eines wesentlich größeren Personenkreises im Rahmen 

der Planung möglich. Die Entwicklung von 3D‐Stadtmodellen geht mit dem Trend einer zu‐ 

nehmenden Öffentlichkeitsbeteiligung in unterstützender Weise einher. 

3D‐Stadtmodelle können auf viele Weisen und aus unterschiedlichen Daten erstellt werden, 

wobei das Ergebnis folglich immer unterschiedliche Qualitäten bezüglich Detaillierung und 

Inhalt aufweist. Um eine qualitative Unterscheidung zu ermöglichen, ist es in der Praxis üb‐ 

lich, verschiedene Detaillierungsstufen zu definieren, sog. Level of Detail (kurz LOD). Die LOD 

beginnen meist bei LOD 0 oder LOD1 mit einem sehr geringen Detaillierungsgrad und wer‐ 

den dann bis LOD 4 oder LOD 5 immer komplexer. Diese Einteilung hat verschiedene Urs‐ 

prünge und Gründe, welche ZEILE [2004] dezidiert untersucht hat. Zum einen hat die LOD‐ 

Diskussion ihre Anfänge in der digitalen Visualisierung, wird aber auch von der 3D‐


Stadtmodell‐Thematik völlig losgelöst verwendet, z.B. bei der Erstellung digitaler dreidimen‐ 

sionaler Modelle im Bereich der Medizin (MRT, 3D‐Modellbildung aus Bildfolgen). 

Abbildung 2: 3D‐Modell eines Mäuseherzen, erstellt aus MRT‐Bildern (eigene Darstellung) 

Die Unterteilung in LOD hat einen sehr pragmatischen Hintergrund: die Reduzierung der Da‐ 

tenmenge. Dies passiert meist aus zwei Gründen, erstens die absichtliche Abstraktion durch 

Reduzierung der Daten, um eine Analyse zu erleichtern, oder die Reduzierung der Daten um 

die technischen Kapazitäten des Computers nicht überzustrapazieren. Die Einteilung der LOD 

ist stark diskutiert und variiert deshalb oft. Verschiedene Institutionen, welche an Standards 

für die Fertigung von 3D‐Stadtmodellen arbeiten, legen diese LOD oft fest (z.B. die SIG 3D). 

Vor dem Hintergrund der genannten Diskussion soll an dieser Stelle die LOD‐Unterteilung 

von ZEILE [2004] in angepasster Weise übernommen werden, da sie sich in der Fachwelt 

häufig, aber nur leicht abgewandelt wiederfindet. 

Auflistung LOD: 

LOD‐0: Ein LOD‐0 Modell besitzt meist nur ein Geländemodell (DGM) und einige wenige, 

stark vereinfachte Geometriekörper von sog. Landmarks (Landmarken wie z.B. Kirchen, Bur‐ 

gen oder andere wichtige Bauten). Ein anderer häufig verwendeter Ausdruck für solche Bau‐ 

ten ist der der „Points of Interest“. Die Punktgenauigkeit in Lage und Höhe liegt über 5m. 

ZEILE [2004] spricht von einem Regionalmodell.


Abbildung 3: LOD‐0‐Modell am Beispiel des DGM Kaiserslautern (eigene Darstellung) 

LOD‐1: LOD‐1 meint ein 3D‐Modell, welches ein detailliertes oder auch abstrahiertes Gelän‐ 

demodell (DGM) besitzt, das durch stark vereinfachte Gebäudekörper (Kubaturen), meist nur 

2,5 D Geometrien (also in die Höhe extrudierte Flächen), ergänzt wird. Auch die Genauigkeit 

steht hierbei im Hintergrund und variiert um den Wert 5m in Lage und Höhe. Trotzdem be‐ 

sitzt ein solches Modell einen analytischen Mehrwert, z.B. für Planer, um Räume abzugren‐ 

zen oder die Höhenstaffelung eines Raumes zu untersuchen. Man könnte auch von einem 

„digitalen 3D‐Schwarzplan der Gebäudestruktur“ sprechen. ZEILE [2004] spricht von einem 

Stadt/Standortmodell. 

Abbildung 4: Beispiel für ein LOD‐1‐Modell (eigene Darstellung)


LOD‐2: Ein LOD 2‐Modell ist nach ZEILE [2004] ein Stadt/Regionalmodell mit Gebäudegeo‐ 

metrien inklusive Dachformen und optionaler Texturierung. Die Gebäudegeometrien sind oft 

generalisiert, und die Punktgenauigkeit liegt über 1‐2 m. Ein solcher LOD eignet sich gut, um 

ein großflächiges Stadtmodell herzustellen, das in seinem Umfang eine ganze Stadt abbilden 

kann. Solche Modelle mit einfacher Geometrie und Texturierung kommen oft in sog. Virtual 

Globes zum Einsatz, wo die Detaillierung gering gehalten werden muss. 

Abbildung 5: LOD‐2‐Modell der Universität Kaiserslautern in Google Earth (eigene Darstellung)


LOD‐3: Das LOD‐3‐Modell unterscheidet sich vom LOD‐2‐Modell insofern, als die Gebäude‐ 

und DGM‐Geometrien noch detailreicher sind. Die Punktgenauigkeit liegt bei max. 0,5 m und 

sollte jeglicher Generalisierung entbehren. Zu DGM und Gebäuden kommen häufig auch 

schon Vegetationselemente und Raummöbel (wie Sitzbänke, Laternen etc.) hinzu. ZEILE 

[2004] spricht von ausdifferenzierten Architekturmodellen. 

Abbildung 6: LOD‐3‐Modell der Stadt Bamberg in Google Earth (eigene Darstellung)


LOD‐4: Unter LOD‐4 versteht man im Allgemeinen ein hochdetailliertes Architekturmodell 

für die Visualisierung von Innenräumen. Die Punktgenauigkeit liegt dabei bei max. 0,2m. Neu 

in diesem Detaillierungsgrad ist die geometrische Ausformung von, über die normale Ge‐ 

bäudegeometrie auskragenden Elementen wie Gauben, Gesims, Ornamenten etc. sowie 

Gebäudeöffnungen (Fenster und Türen). Dieser LOD kommt meist bei Architekturvisualisie‐ 

rungen und 3D‐Modellen für den Animationsprozess (zur Erstellung von Animationsfilmen) 

zum Einsatz. 

Die starke Zunahme der Leistung der heutigen Computer und leistungsfähige Schnittstellen 

haben es aber mittlerweile ermöglicht, diesen LOD in 3D‐Stadtmodellen umzusetzen, ohne 

Leistungseinbußen zu produzieren (siehe Kap. 2.2.4). 

Abbildung 7: LOD‐4‐Modell der Stadt Kaiserslautern (eigene Darstellung) 

Ein weiteres Unterscheidungsmerkmal bei 3D‐Stadtmodellen ist die Präsentationsform als 

gerenderter Animationsfilm oder als interaktives Echtzeit‐/Realtime‐Modell. Zusätzlich un‐ 

terschiedet man webbasierte (im Internet lauffähige) oder „Stand Alone“ (Einzelplatzcompu‐ 

ter) 3D‐Stadtmodelle. Auf Unterschiede wie LOD und Präsentationsmethoden soll im folgen‐ 

den Kapitel 2.2 genauer eingegangen werden.


2.2 Visualisierungstechniken 

Im folgenden Kapitel werden die bestehenden Visualisierungs‐ und Präsentationstechniken 

für 3D‐Stadtmodelle untersucht und gegeneinander abgegrenzt. Weiterhin werden ihr Nut‐ 

zen für die Planung und ihr Stand in der Praxis im Kontext von 3D‐Stadtmodellen hinterfragt. 

2.2.1 Halbinteraktive Viewer 

Halbinteraktive Viewer sind im Gegensatz zu vollinteraktiven Echtzeitmodellen Modelle, die 

zwar die Realität, im Sinne eines 3D‐Stadtmodells abzubilden vermögen, aber keine 3D‐ 

Daten darstellen und nur bedingte Interaktivität bieten. Ein frühes Beispiel hierfür sind die 

sog. „Quicktime VR“‐Anwendungen. Dabei werden mehrere Panoramabilder (Fotografien) zu 

einem „Rundumbild“ (360 Grad) zusammengerechnet (Fachwort: „gestitcht“) und sind dann 

interaktiv navigierbar und erlebbar. Die Technologie wurde bis heute stark verbessert und 

ermöglicht mittlerweile kleine interaktive Welten, in denen der Nutzer mehrere hinterei‐ 

nandergeschaltete Räume durchqueren kann und dabei in die 360 Grad‐Bilder hinein zoo‐ 

men kann oder über sog. Metatags (kleine Infopunkte, die bei Aktivierung vorher gespei‐ 

cherte Infos darstellen) in den Szenen Infos abfragen kann. Die Darstellungsqualität kann, 

abhängig von Bild‐ und „Stitchqualität“, sehr hoch sein und bildet die Realität absolut detail‐ 

getreu ab. Dennoch hat sich diese Darstellungsform nicht in der Planung, im Kontext der 3D‐ 

Stadtmodelle, durchgesetzt, da vor allem keine eigenen 3D‐Daten integriert und nur vorge‐ 

fertigte Perspektiven eingenommen werden können. Allerdings stellt diese Technik ein prak‐ 

tisches Instrument im Sinne einer Bestandsaufnahme dar, z.B. wenn über große Entfernun‐ 

gen hinweg geplant wird oder als Kommunikationswerkzeug, bei dem über die Metatags in 

den Szenen von verschiedenen Bearbeitern Anmerkungen gemacht werden. 

Eine Abwandlung dieser Technik stellt gerenderte (also vorgefertigte) Animationssequenzen 

aus 3D‐Daten in sehr hoher Qualität zu halbinteraktiven Räumen zusammen. Der Unter‐ 

schied liegt aber hauptsächlich in der Erhebung der Bilddaten. 

Abbildung 8: Beispiel für ein Quicktime VR (Virtualdenmark, 2009)


Eine sehr interessante und zukunftsträchtige Entwicklung stellen die Innovationen der Mic‐ 

rosoft Live Labs dar. Das Projekt „Photosynth“ ist in der Lage große Mengen an Bildern zu 

einer dreidimensionalen Szene zusammenzustellen. Die Anwendung referenziert (Fachwort: 

„verortet“) die einzelnen Bilder über einen komplizierten Algorithmus über die Perspektive, 

in der sie aufgenommen wurden, und ordnet ihnen eine Position im Raum zu. Das Ergebnis 

ist eine dreidimensionale „Bildwolke“, in der man interaktiv navigieren kann und sich auf 

einzelne Objekte hinzubewegen kann. 

Abbildung 9: Screenshot der Anwendung Photosynth (Kawatan, 2009) 

Ein weiteres Novum ist die Ankündigung, dass die Anwendung mit seiner Weiterentwicklung 

in der Lage sein soll, aus diesen „Bildwolken“ Geometriedaten zu erzeugen 

[www.microsoft.com]. Hypothetisch würde das für die Erstellung von 3D‐Stadtmodellen be‐ 

deuten, dass keine komplexen Verfahren wie Stereoskopie (Erklärung siehe Glossar) oder 

Laserscanning (Erklärung siehe Glossar) mehr notwendig wären, um genaue Gebäudegeo‐ 

metrien zu erstellen. Stattdessen würde es genügen, eine Menge an Bildern von dem abzu‐ 

bildenden Raum zu machen. Im Vergleich zu bisherigen Verfahren würden die Kosten und 

der Aufwand für die Erstellung von solchen Modellen drastisch sinken. 

Bisher ist allerdings nur die Anwendung zur Erstellung von erlebbaren Bildwolken verfügbar.


2.2.2 Virtuelle Globen 

Das Jahr 2004 brachte mit den Anwendungen „Google Earth“ und „NASA World Wind“ die 

ersten virtuellen Globen auf den Markt. Aufgrund der ernormen Menge an Satellitenbildern 

und sonstigen Geodaten, über welche das kommerzielle Unternehmen Google und die staat‐ 

lich geförderte Institution NASA verfügen konnten [vgl. Höffken, 2007], war es fortan mög‐ 

lich, über die beiden Anwendungen nahezu jeden Punkt auf der Erde aus der Vogelperspek‐ 

tive zu betrachten. Damit wurde ein Hype in der Internetgemeinschaft ausgelöst, der bis 

heute anhält. Später wurde auch vom bekannten Softwarehersteller Microsoft mit „Virtual 

Earth“ ein äquivalentes Produkt veröffentlicht. 

Abbildung 10: Screenshot der Anwendung Google Earth (Newsnetz‐blog, 2009) 

Ein virtueller Globus ist nach EXNER [2009] ein „interaktiver Globus, der seinen Datenbesatz 

über das Internet aktualisieren kann … und stellt eine Weiterentwicklung der Web‐Map‐ 

Services (Erklärung siehe Glossar) dar.“ Er besteht aus Geo‐Datensätzen wie einem flächen‐ 

deckenden Geländemodell, hochauflösenden Luft‐ und Satellitenbildern sowie einer großen 

Menge an Metadaten (wie Informationen zu Lokalitäten). Diese Daten werden mit einer 

interaktiven Steuerung kombiniert und ermöglichen so eine Navigation rund um den Globus.

Abbildung 11: Screenshot der Anwendung NASA World Wind (Tinypic, 2009) 


Auch die „Planerwelt“ wurde von diesem Hype erfasst, denn bis dato waren hochauflösende 

Luftbilder nur einem kleinen Kreis verfügbar und sehr teuer im Erwerb. Zusätzlich bestand 

die Möglichkeit über eine Modellierungssoftware, namens „@Last Sketchup“, 3D‐ 

Gebäudekörper nach Google Earth zu exportieren. Zunächst noch ohne Texturen, aber dafür 

in großen Mengen. Das bedeutet, es war möglich, mit sehr geringem Aufwand einer großen 

Personenzahl ein 3D‐Stadtmodell zu präsentieren. Eine weitere Funktion, welche für die Pla‐ 

ner sehr nützlich war [vgl. Höffken, 2007], war die sog. Overlay‐Funtkion, mit deren Hilfe 

man Bilder über das Satellitenbild, im Sinne einer zusätzlichen Ebene, legen konnte. Damit 

konnte man z.B. Flächennutzungspläne, Bebauungspläne, historische Karten und sonstiges 

Kartenmaterial in Google Earth einbauen und veröffentlichen. Dadurch wurde dem Planer 

von kommerzieller Seite, beabsichtigt oder unbeabsichtigt, ein kostenloses Werkzeug an die 

Hand gegeben, das ihm erstens die Bestandsaufnahme erleichterte, und eine kostengünstige 

Plattform zur Präsentation seiner Planung war. 

Mit der Version 4 von Google Earth war es fortan möglich, auch texturierte Modelle über das 

mittlerweile von Google aufgekaufte [www.tuaw.com] und kostenlose Programm Sketchup 

nach Google Earth zu exportieren. Google Earth wurde zur ersten kostenlosen Plattform für 

3D‐Stadtmodelle und hatte zudem noch GIS‐Funktionen (meint die Funktionen eines Geo‐ 

grafischen Informationssystems, siehe Glossar). Die Möglichkeiten über den Nutzen von 

Google Earth und virtuellen Globen für die Planung werden von EXNER [2009] ausführlich 

beschrieben. Zudem zeigt er dessen Qualitäten in der Öffentlichkeitsbeteiligung bei Planun‐ 

gen auf und geht auf die Unterschiede zwischen den verfügbaren virtuellen Globen ein.


Abbildung 12: Screenshot der Anwendung Microsoft Virtual Earth (Spatiallyadjusted, 2009) 

Für die Thematik der 3D‐Stadtmodelle stellen die virtuellen Globen, allen voran Google 

Earth, eine kostengünstige Plattform dar, um Echtzeitmodelle von Städten zu visualisieren. 

Viele deutsche Städte wie Hamburg, Berlin, München oder Bamberg besitzen detaillierte 3D‐ 

Modelle ihrer Städte mit ergänzenden Gimmicks wie Suchfunktionen oder der Überblendung 

historischer Karten. In Bamberg wurde sogar ein Marathonlauf per GPS nach Google Earth 

übertragen und konnte dadurch live im 3D‐Stadtmodell im Internet verfolgt werden. Dies 

zeigt den großen Nutzen von 3D‐Stadtmodellen und virtuellen Globen außerhalb der Pla‐ 

nungswelt sowie deren Mehrwert durch Akzeptanzsteigerung [vgl. EXNER, 2009] auf. 

Problematisch bei der Nutzung von virtuellen Globen für 3D‐Stadtmodelle ist aber weiterhin 

die Bandbreite des Internets, die Menge an zu visualisierenden Daten und die Stringenz, mit 

der Google die Bilddaten seiner Anwendung Google Earth schützt [www.netzwelt.de]. Auch 

nicht mehr aktuelle Luftbilder und wenig detaillierte Geländemodelle sind, für die intensive‐ 

re Nutzung von virtuellen Globen für 3D‐Stadtmodelle ein Problem. Trotzdem ist es möglich, 

mit ihnen 3D‐Stadtmodelle mit relativ hoher Qualität zu realisieren.

2.2.3 3D‐Stadtmodelle in VRML 


Das Kürzel VRML (Virtual Reality Markup Language) steht für einen erstmals 1994 veröffent‐ 

lichten Standard für die Visualisierung von 3D‐Daten in Webbrowsern. Damit konnten 3D‐ 

Daten interaktiv in Browsern dargestellt werden. VRML stellt also neben den Visualisierun‐ 

gen von Städten in Anwendungen der Unterhaltungsindustrie einen Meilenstein bei der Vi‐ 

sualisierung von interaktiven 3D‐Stadtmodellen dar. VRML war sehr erfolgreich, und die 

zweite Version von VRML (VRML97) schaffte es sogar zum ISO‐Standard [www.citygml.org]. 

VRML kann 3D‐Daten aus vielen 3D‐Modellierungsanwendungen über ein eigenes Daten‐ 

format exportieren und ist dann mit Hilfe eines Browser‐Plug‐ins auf fast jedem Rechner 

darstellbar. Die Tatsache, dass VRML im Textformat gespeichert wird, macht es vor allem für 

die gemeinsame Nutzung mit GIS‐Programmen kompatibel. Ein weiterer Vorteil des Text‐ 

formats ist die Möglichkeit, die Daten sehr stark zu komprimieren. Die Darstellungsqualität 

war für damalige Verhältnisse sehr hoch, und die Interaktivität, die in VRML‐Welten möglich 

war, machte es für den Nutzen mit kleinräumigen Stadtmodellen zur praktikablen Lösung. 

Solche Modelle konnten sogar halbautomatisch aus GIS‐Daten erstellt werden und verringer‐ 

ten so den Erstellungsaufwand erheblich [vgl. www.supportgis.de]. Dieser Workflow zur Fer‐ 

tigung von 3D‐Stadtmodellen ist bis heute verbreitet. VRML hingegen konnte sich nicht als 

3D‐Standard im Internet durchsetzen, und auch seine weitere Standardisierung wurde aus 

wirtschaftlichen Gründen nicht weitergeführt. Auch das Nachfolgerformat X3D erreichte die 

gewünschte Standardisierung nicht. 

Abbildung 13: VRML‐Modell der Stadt Philadelphia (Geosim, 2009)


Für die Planung stellt VRML bis heute eine kostengünstige Methode zur Präsentation drei‐ 

dimensionaler Daten dar. Die Gründe dafür liegen in seiner guten Kompatibilität mit vielen 

CAD‐Programmen und seiner einfachen Bedienung. Allerdings wird die Nutzerfreundlichkeit 

bis heute diskutiert. Ein größeres Problem im Hinblick auf die Visualisierung ganzer Städte 

sind seine Eigenschaft als Browser‐Plug‐in und die immer noch nicht ausreichende Bandbrei‐ 

te des Internets. Die Probleme ähneln denen der Virtual Globes. Die Darstellung eines komp‐ 

lett über das Internet gestreamten (Streaming (engl.) = das kontinuierliche Übertragen eines 

Datenstroms im Internet), volltexturierten 3D‐Stadtmodells (LOD 3) einer ganzen Stadt 

scheitert oft noch an Bandbreitenproblemen. Bei VRML kam ein weiteres Problem im Per‐ 

formancebereich hinzu. Da die Beschreibungssprache VRML nur noch bedingt weiterentwi‐ 

ckelt wurde, kann ihre Leistungsfähigkeit in den Punkten Darstellungsqualität und Ge‐ 

schwindigkeit mit gängigen Techniken wie Virtual Globes oder sog. 3D‐Engine‐basierten 

Viewern (Erklärung siehe Kap. 2.2.5) nicht mithalten[vgl. www.htmlopen.de]. 

2.2.4 Digitale Stadtmodelle aus der Unterhaltungsindustrie 

Die Erwähnung von fiktiven dreidimensionalen Stadtmodellen aus Computerspielen mag im 

Zusammenhang einer wissenschaftlichen Arbeit verwundern, stellt aber eine ernst zuneh‐ 

mende Perspektive dar [vgl. POESCH, SCHILDWÄCHTER, ZEILE, 2004], die nicht ausgeschlos‐ 

sen werden sollte. Die Unterhaltungsindustrie hat seit Bestehen der Computerindustrien 

viele Standards geschaffen und Methoden zur Darstellung von 3D‐Inhalten vorgegeben. 

Während die Planungswissenschaften nach Visualisierungslösungen suchten, ignorierten sie 

die bereits bestehenden Techniken aus der Unterhaltungsindustrie. Diese hatte bereits An‐ 

fang der 1990er‐Jahre einen enormen Know‐how‐Vorsprung aufzuweisen und hat diesen im 

Bereich der Visualisierung von 3D‐Inhalten bis heute nicht verloren. Es wäre also vermessen, 

bestehende Kompetenz auf Grund von Vorurteilen zu ignorieren. 

Die Unterhaltungsindustrie, vertreten durch diverse Hersteller von Computerspielen, setzten 

schon Mitte der 1990er‐Jahre Meilensteine der Darstellungsqualität und Darstellungsper‐ 

formance (Performance = „Flüssigkeit“ der Darstellung gemessen in Bildern pro Sekunde, 

siehe FPS). Dadurch dass die Unterhaltungsindustrie und die Industrie der Hardwareprodu‐ 

zenten für Computer sich gegenseitig bedingten und kooperierten, wurden auf die Hardware 

zugeschnittene Anwendungen entwickelt. Auch die Hersteller von 3D‐Modellierungs‐ 

Software richteten sich nach den Wünschen und Vorgaben der Unterhaltungsindustrie aus. 

Die Gründe dafür lagen schlichtweg im finanziellen Volumen des Endverbrauchermarktes der 

Unterhaltungsindustrie[ vgl. www.cbc.ca]. 

Bereits Ende des letzten Jahrtausends konnten in Computerspielen sehr große Areale von 

stadtähnlichen Strukturen in sehr hoher Qualität (etwa LOD 3) dargestellt werden. Beispiele 

hierfür sind die schon erwähnten Spiele „Need for Speed 2“ und „Halflife“. Der Trend setzte


sich fort. Immer wieder wurden Computerspieletitel veröffentlicht, welche neue Maßstäbe 

für die Darstellungsqualität und das Volumen der dargestellten Inhalte setzten. 

Der 2001 veröffentlichte Titel „GTA 3“ des Herstellers Rockstar Games stellte mit der Hard‐ 

wareausstattung einer einfachen Spielekonsole eine ganze Stadt am heimischen Fernseh‐ 

bildschirm dar. Auch die Qualität der Gebäudegeometrien, Texturen und die Geschwindig‐ 

keit stellten alle vergleichbaren Versuche der Planungs‐ und Geowissenschaften in den 

Schatten. Eine ganze Stadt war problemlos interaktiv erlebbar. 

Abbildung 14: Szene aus dem Computerspiel GTA 3 (Rockstar Games, 2002) 

Heute 2009 ist der Fotorealismus in Computerspielen schon weitgehend erreicht. Für den 

2008 publizierten Titel „GTA 4“ des oben erwähnten Herstellers wurde von den Entwicklern 

der Innenstadtbereich der Metropole New York detailliert nachgebaut [www.gtavision.com]. 

Der äquivalente LOD in der Planerwelt wäre etwa LOD 5, da sogar Innenräume, Seitenstra‐ 

ßen und kleinste Straßenmöbel visualisiert wurden. Diese Qualität und die Performance ha‐ 

ben ihren Preis und sind für die Erstellung durch und für planende Kommunen durchweg 

indiskutabel. Während die Erstellung von „GTA 3“ noch 1 Million Dollar kostete, stellte der 

Hersteller mit den Entwicklungskosten für „GTA 4“, in Höhe von 100 Millionen Dollar einen 

ungebrochenen Rekord auf [www.play3.de].


Abbildung 15: Szene aus dem Computerspiel GTA 4 (eigene Darstellung) 

Im Kontext der Erstellung von 3D‐Stadtmodellen können aus den Beobachtungen und Erfah‐ 

rungen mit solchen Computerspielen aber mehrere wichtige Schlussfolgerungen gezogen 

werden: 

1. Die von den Computerspielen verwendete Methode zur Erstellung und Darstellung 

von 3D‐Geometrien ist auf Grund ihrer Ausrichtung des Erstellungsworkflows auf die 

Hardware wesentlich effektiver im Hinblick auf Qualität und Performance. 

2. Ein hoher LOD verbessert die Modellakzeptanz und den Wiedererkennungsfaktor 

3. Der LOD der Computerspiele ist mit den Mitteln einer Kommune oder eines Pla‐ 

nungsbüros in der Fläche einer ganzen Stadt nicht erreichbar. 

4. Die Technik und das Know‐how zur Erstellung und Darstellung äquivalenter Modelle 

sind weit verbreitet und öffentlich verfügbar. 

Im Sinne einer Optimierungsaufgabe, lag es also nahe, die vorhandenen Methoden zur Ers‐ 

tellung von 3D‐Stadtmodellen zu überdenken und die Workflows und Techniken der Spiele‐ 

hersteller schrittweise zu adaptieren [vgl. ZEILE, 2004]. 

Mit der Zielsetzung, ein 3D‐Stadtmodells für die komplette historische Innenstadt der Stadt 

Bamberg zu erstellen, wurde 2003 vom Lehrgebiet Computergestützte Planungs‐ und Ent‐ 

wurfsmethoden (CPE) zusammen mit der Kommune Bamberg ein Kooperationsprojekt ini‐ 

tiiert, welches sich im Nachhinein als Best Practice erwies. ZEILE [2004] dokumentiert dieses 

Projekt ausführlich. Nach einer detaillierten Bestandsaufnahme wurden zahlreiche Software‐ 

lösungen untersucht, mit dem Ergebnis, dass sog. Game‐Engines die beste Lösung zur Dar‐ 

stellung eines Datensatzes mit den Ausmaßen einer Stadt und einem hohen LOD (damals 

LOD 3) sind.

Abbildung 16: Screenshot des Editors der Unreal‐2‐Engine (eigene Darstellung) 


Definition: Game Engines 

Game‐Engines sind der programmiertechnische Kern eines Computerspiels und koordinieren 

den Datenaustausch zwischen Anwendung und Grafikhardware. Sie entscheiden über Dar‐ 

stellungsqualität und Performance eines 3D‐Modells in einer Anwendung 

[www.wapedia.mobi]. Zusammen mit den Schnittstellen (z.B. DirectX oder OpenGL) steuern 

sie das Verhalten der Grafikkarte eines Computers. 

Im Projekt Bamberg 3D setzte man zunächst auf eine kommerzielle Game‐Engine (Unreal 2 

Engine, Hersteller Epic Games, 2003), welche man aber aufgrund der enormen Kosten von 

etwa 800.000 Dollar wieder verwarf. Anschließend setzte man das 3D‐Stadtmodell mit einer 

Open‐Source‐Engine (Irrlicht Engine, 2004) um. Das Ergebnis war in Qualität und Performan‐ 

ce richtungsweisend und eröffnete eine Diskussion über die Entwicklung von 3D‐ 

Stadtmodellen in der Planung. Bis heute wurden zahlreiche 3D‐Stadtmodelle mit dieser 

Technik umgesetzt.


Abbildung 17: Screenshot des 3D‐Stadtmodells Bamberg in der Irrlicht‐Engine (eigene Darstellung) 

Die Adaption von Know‐how aus der Unterhaltungsindustrie hat sich also als Meilenstein für 

die Entwicklung der 3D‐Stadtmodelle erwiesen und prägt diese bis heute. Das beste Beispiel 

für diese Vorgehensweise war die Tatsache, dass die Darstellungs‐Engine und das Datenfor‐ 

mat des Virtual Globes Google Earth dieselben sind wie die der neuesten Generation der 

Sony Playstation Spielekonsole (PS3) [vgl. www.kronos.org und www.google.com]. 

So groß die Vorteile der Verwendung von Game‐Engines für 3D‐Stadtmodelle auch sind, so 

stehen ihrer problemlosen Weiterentwicklung zum Standard mehrere Nachteile entgegen. 

Der Workflow zu einem 3D‐Stadtmodell unter Verwendung von Game‐Engines ist zwar in 

sich konsistent und effizient, benötigt aber viel Spezialwissen, welches eigentlich das Stu‐ 

dium mehrerer Berufe erfordert: das des Geoinformatikers oder Programmierers, das des 

CG‐Artists oder 3D‐Modellierers und das des Raumplaners. Dieses Spezialwissen kann vom 

normalen Raumplaner, der mit einem kleinen Mitarbeiterstab ein interaktives 3D‐ 

Stadtmodell einer Stadt erstellen soll, nicht erbracht oder verlangt werden. In der Folge 

entwickelten sich zahlreiche Planungsbüros, welche sich auf die Erstellung solcher Modelle 

spezialisiert haben und einen neuen Markt erschlossen haben, da die Kommunen die Erstel‐ 

lung oft auslagern. Zusätzlich benötigt es eine Vielzahl an teurer Spezial‐Software, teilweise 

mehrere tausend Euro in der Anschaffung, und leistungsfähiger Hardware. Letzteres Argu‐ 

ment ist in den letzten Jahren durch die Entwicklung des Hardwaremarktes abgeschwächt 

worden.

2.2.5 Engine‐basierte 3D‐Stadtmodelle 


Neben der Unterhaltungsindustrie verfolgten auch kommerzielle Anbieter von CAD und GIS‐ 

Software den Weg, 3D‐Stadtmodelle mit Hilfe von sog. Engines zu visualisieren. Da die zu‐ 

grunde liegende Technik dieser Engines, eine Programmierung über Sprachen wie C++, kein 

Geheimnis war, wurden eigene Engines programmiert. Nach dem Prinzip „der Bessere ge‐ 

winnt“ gab es etwa seit dem Jahr 2000 eine Hand voll Anbieter, die in der Lage waren, über 

eigene Engines 3D‐Modelle darzustellen. Diese kamen hauptsächlich aus dem Bereich der 

Geoinformatik. Beispiele hierfür waren der „Cybercity Modeller“ der Firma Cybercity Sys‐ 

tems oder „Terrain View“ der Firma Viewtec. Ein weiteres aktuelles Produkt stellt der 

„Landxplorer“ der Firma Autodesk dar. 

Abbildung 18: 3D‐Stadtmodell im Cybercity‐Modeller (Earsel, 2009) 

Alle Produkte basieren mehr oder weniger auf einer 3D‐Engine und können 3D‐Stadtmodelle 

inklusive Texturen darstellen. Die Produkte waren auf den Endverbraucher, oft Kommunen 

und Stadtplanungsämter, zugeschnitten, meist aber enorm teuer. Allein die Anwendung zum 

„anschauen“ (Fachwort: Viewer) der 3D‐Modelle, der sog. Viewer, kostete bis zu 10000 Euro 

pro Computer. Die Verbreitung war deshalb nicht sehr groß. Die Qualität und Performance 

der Anwendungen war hingegen relativ hoch. Die Größe der 3D‐Stadtmodelle, welche dar‐ 

stellbar waren, war enorm hoch und konnte sogar mit „Stadtmodellen“ aus der Unterhal‐ 

tungsindustrie mithalten. Auch die Funktionsvielfalt war durch starke Spezialisierung der 

Softwarepakete groß. Neben integrierten GIS‐Funktionen und Mess‐Werkzeugen war vor 

allem die Kompatibilität mit branchenspezifischen Datenformaten wie CityGML etc. von gro‐ 

ßer Bedeutung für den Endanwender. Zudem konnten bestimmte Arbeitsschritte wie die 

Erstellung oder Texturierung von Gebäuden teilweise sogar halb automatisch durchgeführt 

werden.


Abbildung 19: 3D‐Stadtmodell in der Anwendung Terrain View (Viewtec Inc., 2009) 

Viele dieser Anwendungen kombinierten Funktionen zur Erstellung und Darstellung in einem 

Programm und sind auf großflächige 3D‐Stadtmodelle im LOD 2‐3 ausgerichtet. 

Trotz des hohen Funktionsumfangs blieb vor allem die Generierung von Stadtmodellen im 

LOD 3, also mit Texturen, in weiten Teilen Handarbeit und somit zeit‐ und kostenintensiv. Ein 

weiterer Nachteil dieser Anwendungen zur Visualisierung von 3D‐Stadtmodellen war, dass 

sie oft nur Daten importieren konnten und ihr Workflow eine „Einbahnstraße“ darstellte. Für 

die dynamische Aktualisierung eines Stadtmodells ist ein wiederholbarer und richtungs‐ 

unabhängiger Workflow unentbehrlich [vgl. ZEILE, 2004]. Diese Anforderung können viele 

3D‐Engine‐basierte Anwendungen nicht erfüllen. 

Zusammenfassend stellen Engine‐basierte Anwendungen eine Mehrheit auf dem Markt der 

3D‐Stadtmodelle dar und sind wegen ihres Funktionsumfangs und ihrer Qualität ein für den 

Planer praktikables aber teures Werkzeug zur Planungsvisualisierung und Öffentlichkeitsbe‐ 

teiligung.

2.2.6 interaktive 3D‐Stadtmodelle in der Planung 


Der momentane Stand der Technik und der Forschung hat 3D‐Stadtmodelle aus dem Ver‐ 

suchsstadium in den Planungsalltag verschoben. Es gibt zahlreiche Beispiele, bei denen 3D‐ 

Stadtmodelle in der eigentlichen Planung, im Abwägungsprozess oder in der Öffentlichkeits‐ 

beteiligung eingesetzt wurden. Mit Hilfe mehrerer Beispiele soll im Folgenden ihr Nutzen für 

die Planung verdeutlicht werden. 

Beispiel 1: Der Bau eines modernen Hotels im historischen Stadtkern von Bamberg (Bayern) 

2006 war der Planungsalltag des Stadtplanungsamtes der Stadt Bamberg von einem Projekt 

geprägt, das in der Öffentlichkeit und in der Politik heftig diskutiert wurde. Es ging um den 

Neubau eines Hotels im Stadtkern von Bamberg. Problematisch dabei war, dass ein Großteil 

der Stadt Bamberg den Status eines Weltkulturerbes inne hat. Die Beeinträchtigung des his‐ 

torischen Stadtbilds und die „Einfügeproblematik“ (Vgl. §34 Abs. 1 Satz 1 BauGB) des neuen 

Baukörpers in die bestehende Bebauung waren in diesem Fall erhebliche Abwägungspunkte. 

Während ein herkömmliches haptisches Modell der verschiedenen Entwürfe nur einen klei‐ 

nen Personenkreis in die Lage einer objektiven Beurteilung versetzt hätte, konnte der Einsatz 

eines 3D‐Stadtmodells eine breitere öffentliche Beteiligung ermöglichen. Auch die Kommu‐ 

nikation der planungsrelevanten Informationen konnte damit unter den Entscheidungsträ‐ 

ger, welche ebenfalls keine planenden Experten sind, verbessert werden. Ein ähnlicher Ein‐ 

satz eines 3D‐Stadtmodells erfolgte bei der Planung einer neuen Brücke im selben Planungs‐ 

gebiet. 

Abbildung 20: Screenshot des 3D‐Stadtmodells Bamberg mit der Planungsvariante des neuen Baukörpers 

(Schildwächteringenieure, 2009)


Beispiel 2: Die Neugestaltung des Marktplatzes in Sindelfingen (Baden‐Württemberg) 

2009 wurde in der Stadt Sindelfingen die Neugestaltung des örtlichen Marktplatzes angest‐ 

rebt. Problematisch in diesem Fall war die Platzgestaltung unter Berücksichtigung der nicht 

fest verortbaren Marktstände. Es ging um die Raumwirkung der Planung zu Markttagen und 

Tagen ohne Marktstände sowie den Platzbedarf der angrenzenden Gastronomie. Auch hier 

konnte ein 3D‐Stadtmodell mit mehreren Varianten des Planungsraumes unterstützend in 

den Planungsprozess integriert werden. 

Abbildung 21: interaktives 3D‐Stadtmodell der Stadt Sindelfingen (Schildwächter Ingenieure, 2009)


Beispiel 3: Bau eines großen Einzelhandelszentrums und Wohnparks in Westport (Irland) 

In diesem Beispiel ging es um die öffentlichkeitswirksame Präsentation der Planung eines 

Einzelhandelsgroßprojekts mit angrenzendem Wohnquartier zur Akquirierung von Investo‐ 

ren. 

Abbildung 22: Visualisierung des Einzelhandelsgroßprojekts in der Anwendung Quest3d (Schildwächter Ingenieure, 2008) 

Die genannten Beispiele zeigen mögliche Einsatzfelder von 3D‐Stadtmodellen in der Pla‐ 

nungsrealität und ihre Vorteile wie Variantendarstellung, dynamische Untersuchung von 

Perspektiven oder moderne und öffentlichkeitswirksame Präsentation von Planungen. 

Trotzdem geht der flächendeckende Einsatz von 3D‐Stadtmodellen in Deutschland nur 

schleppend voran. Grund dafür ist die Vielzahl an unterschiedlichen Technologien und Ar‐ 

beitsabläufen sowie an verfügbaren Softwarelösungen. Weiterhin ist die Informationssitua‐ 

tion in Bezug auf 3D‐Stadtmodelle nicht optimal, und der Beigeschmack der exotischen 

Softwarelösung ist in vielen Stadtplanungsämtern immer noch gegeben.


2.3 Zwischenfazit 

Nach dieser Übersicht der momentan verfügbaren Visualisierungstechniken für 3D‐ 

Stadtmodelle ist festzustellen, dass es keinen standardisierten Arbeitsablauf zur Erstellung 

oder zur Visualisierung gibt. Auf Grund der Vielzahl von Anwendungen, Datenformaten und 

Visualisierungstechnologien war dies vorhersehbar. Weiterhin kann es dafür auch keinen 

Standard geben, da es sich meist um Einzellösungen handelt, die individuell auf die Kommu‐ 

nen zugeschnitten sind. Diese variieren in Größe, Anwendungszweck und Qualität. Zusätzlich 

spielt der Verbreitungsgrad (die Größe des adressierten Personenkreises) und der Bildungs‐ 

grad der Adressaten (Experte, Laie, etc.) eine erhebliche Rolle. 

Nachdem nun eine Basis bezüglich der möglichen Darstellungstechniken gelegt wurde, soll 

im folgenden Kapitel der Fokus auf digitalen und analogen historischen Stadtmodellen lie‐ 

gen. Bis jetzt wurden nur 3D‐Stadtmodelle mit einer Ausrichtung auf die Gegenwart oder die 

Zukunft betrachtet. Neben der Visualisierung von aktuellen Zuständen und zukünftigen Pla‐ 

nungen spielt auch der Umgang mit historischer Bausubstanz eine in der Planung abwä‐ 

gungsrelevante Rolle.

3. Historische Stadtmodelle 

3.1 analoge Stadtmodelle 


Unter analogen Stadtmodellen versteht man eine verkleinerte Rekonstruktion einer Stadt 

aus Holz, Gips, Pappe oder anderen Materialien in einem festgelegten Maßstab. Sie visuali‐ 

sieren und dokumentieren die Gestalt einer Stadt und dienen als Grundlage für die Präsenta‐ 

tion bei städtebaulichen Wettbewerben. Dabei werden die Entwürfe der Wettbewerbsteil‐ 

nehmer (z. B. das plastische Modell eines Gebäudes) in das Gesamtmodell eingesetzt. An‐ 

schließend können sich Planer und Entscheidungsträger ein Bild von dessen Raumwirkung, 

Schattenwurf oder Integration in die bestehende Bebauung machen. Hier zeigt sich der ana‐ 

lytische Nutzen von Stadtmodellen. Ähnlich wie das Architekturmodell stellt das städtebauli‐ 

che Modell neben der zeichnerischen Darstellung (in Form eines Plans) einen integrierten 

Bestandteil des Entwurfsprozesses dar. Die maßstäbliche plastische Wiedergabe der Planung 

erhöht die Anschaulichkeit einer Planung bei Auftraggebern, Entscheidungsträgern und an‐ 

deren Beteiligten. 

Abbildung 23: Beispiel für ein Architekurmodell (Wagnis, 2009) 

Analoge Modelle stellen den Vorgänger von digitalen Modellen dar und werden bis heute für 

die Visualisierung von Planungen eingesetzt. Der Modellbau ist bis heute wesentlicher Be‐ 

standteil des Architekturstudiums. Die Erstellung ist eine eigene Kunst und im professionel‐ 

len Bereich sehr teuer, da das gesamte Modell maßstäblich ist und handgefertigt wird. Der 

Preis für ein Modell von der Größe eines einzigen Katasterblattes im Maßstab 1:500 liegt für 

das Stadtmodell Regensburg bei etwa 90.000€ (erfragter Wert, [www.maxani.de]). Auch

32 3. Historische Stadtmodelle 

dauert die Erstellung dieser Modelle teilweise mehrere Jahre. Viele Städte stellen aufgrund 

der Kosten und der günstigeren digitalen Alternativen den Bau solcher Modelle ein. 

Abbildung 24: Beispiel für ein Stadtmodell (Wikipedia, 2009) 

Neben den Stadtmodellen, welche die Gegenwart bzw. jüngere Vergangenheit dokumentie‐ 

ren, gibt es zahlreiche Modelle, die die Rekonstruktion historischer Bauten versuchen. Diese 

sind vor allem aus Museen und Ausstellungen bekannt und ermöglichen es dem Publikum, 

einen Eindruck von der historischen Situation eines Objektes zu gewinnen. 

Ein gutes Beispiel ist die analoge Rekonstruktion der Kaiserpfalz Ingelheim. Nach Jahren auf‐ 

wendiger archäologischer Ausgrabungen wurden nach und nach verschiedene Modelle aus 

Gips angefertigt. Das Ergebnis ist eine Idealrekonstruktion der Kaiserpfalz. 

Die Datengrundlage für die Rekonstruktionen waren Rekonstruktionszeichnungen verschie‐ 

dener Autoren und Zeiten. Heute wird in einer permanenten Ausstellung ein Modell aus 

Kunststoff ausgestellt, das kontinuierlich, entsprechend den Fortschritten bei der Ausgra‐ 

bung, aktualisiert wird. Die Ausgrabungen und der Modellbau stellen einen fortwährenden 

Prozess dar, der bis heute andauert [www.kaiserpfalz‐ingelheim.de].

Abbildung 25: Modell der Kaiserpfalz Ingelheim (Google Inc., 2009) 


Ein Beispiel für eine historische Rekonstruktion mit Bezug zur Stadt Kaiserslautern, ist das 

Modell des Casimirschlosses im Theodor‐Zink‐Museum in Kaiserslautern. Dort ist ebenfalls 

ein Stadtmodell von Kaiserslautern ausgestellt, welches die gesamte Stadt im Jahr 1623 dar‐ 

stellt. 

Abbildung 26: Modell des Casimirschlosses im Theodor‐Zink‐Museum in Kaiserslauern (eigene Darstellung mit Genehmi‐ 

gung des Theodor Zink Museum Kaiserslautern, 2009)


Abbildung 27: Modell der Stadt Kaiserslautern um 1623 (eigene Darstellung mit Genehmigung des Theodor Zink Museum 

Kaiserslautern, 2009) 

Ein Nachteil solcher historischen Modelle ist, dass die Dimension vom Betrachter trotz be‐ 

kanntem Maßstab schlecht einzuschätzen ist. Der abstrakte Maßstab in Form von Zahlen ist 

für Laien oft hinderlich, um sich ein anschauliches Bild von der Situation zu machen. Auch die 

gewählte Perspektive ist vorgegeben, und Aussagen über die Wirkung von Sichtlinien im 

Modell von verschiedenen Standpunkten aus sind schwer zu treffen. 

Im folgenden Kapitel sollen die digitalen Nachfolger der analogen historischen Modelle be‐ 

handelt werden und anschließend ihre Bedeutung für die Planung hinterfragt werden.

3.2 bestehende digitale historische 3D‐Modelle 


Um einen Bezug zum vorhergehenden Kapitel zu schaffen, soll zunächst das digitale 3D‐ 

Modell der Kaiserpfalz Ingelheim vorgestellt werden. Anschließend werden noch andere 

Beispiele gebracht, bei denen es ebenfalls um historische Rekonstruktionen ging. Aufgrund 

der enormen Menge an vorhandenen Beispielen soll nachfolgend nur eine Auswahl aufge‐ 

führt werden. 

Beispiel: Kaiserpfalz Ingelheim 

Von 2001 bis 2003 wurde in einer Projektkooperation zwischen dem Grabungsbüro der Kai‐ 

serpfalz Ingelheim und der Archimedix GbR. (einem Büro für 3D‐Visualisierungen) die virtuel‐ 

le Rekonstruktion der sog. „Aula regia“ (einem bedeutenden Teilbau der Kaiserpfalz) erarbei‐ 

tet. Dies war wegen der hohen Datendichte, die durch zahlreiche Ausgrabungen und Unter‐ 

suchungen gegeben war, ohne Probleme möglich. Das Ergebnis ist ein texturiertes 3D‐ 

Modell, welches sich die Besucher der lokalen Ausstellung in Ingelheim entweder als Anima‐ 

tionsfilm oder über ein Touristeninformationssystem anschauen können. Letzteres bietet zu 

verschiedenen Bereichen der 3D‐Rekonstruktion Informationen und zeigt sogar verschiede‐ 

ne Rekonstruktionsvarianten an. Bei der Visualisierung der Rekonstruktionsdaten handelt es 

sich aber nur um einen gerenderten Animationsfilm und eine Vielzahl an gerenderten Bil‐ 

dern. Eine Navigation im Modell ist daher nicht möglich. Trotzdem können die Besucher dar‐ 

über zahlreiche Informationen über die Kaiserpfalz erhalten [www.kaiserpfalz‐ingelheim.de]. 

Abbildung 28: gerendertes Bild der Rekonstruktion der „Aula regia“ in Ingelheim (Archimedix GbR, 2009)


Beispiel: Kaiserpfalz Kaiserslautern 

Als Nächstes soll die Rekonstruktion der Kaiserpfalz in Kaiserslautern vorgestellt werden. 

2006 initiierte der Förderkreis zur Erhaltung der Kaiserpfalz Kaiserslautern e.V. die Erstellung 

einer DVD, auf der ein Informationsfilm für Touristen enthalten ist. Dieser Film zeigt eine 

sehr detaillierte Rekonstruktion der Kaiserpfalz und der städtebaulichen Situation, wie sie 

mit hoher Wahrscheinlichkeit 1160 n.Chr. aussah. Zusätzlich wurden Realfilmelemente in‐ 

tegriert, in denen Schausteller eines Mittelaltervereins (die Legende e.V.) Szenen aus der 

damaligen Zeit am Hofe Kaiser Barbarossas nachstellen. Dadurch bekommt der Betrachter 

einen Einblick in den Alltag am Hof der Kaiserpfalz und eine ungefähre Vorstellung davon, 

wie dieser ausgesehen hat. 

Für die Erstellung wurde auf die Datenbestände der Stadt zurückgegriffen. In Zusammenar‐ 

beit mit weiteren Experten wurde ein Rekonstruktionsversuch in ein 3D‐Modell umgesetzt. 

Es handelt sich um einen Rekonstruktionsversuch, da es sehr wenige historische Beweise 

gibt, die die Rekonstruktion bestätigen. Das Modell wurde dann in der Software 3D Studio 

Max texturiert, gerendert und in einen Animationsfilm integriert. Da es sich ebenfalls um 

einen Animationsfilm handelt, hat der Betrachter keine Möglichkeit, den vorgegebenen Pfad 

der Betrachterperspektive zu verlassen. Die dabei entstandenen Daten, insbesondere das 

3D‐Modell der Kaiserpfalz, wurden in dieser Arbeit für das 3D‐Stadtmodell Kaiserslautern 

verwendet. Die Quelle für diese Informationen waren Telefonate mit dem Ersteller der 3D‐ 

Daten, der Firma ReUnion‐Media. 

Abbildung 29: DVD‐Cover und Filmszene (Förderkreis zur Erhaltung der Kaiserpfalz Kaiserslautern e.V., 2006)

Beispiel: „Rome Reborn“ (Rom, Italien) 


Das Projekt „Rome Reborn“ ist die Rekonstruktion und Visualisierung der Stadt Rom zum 

Zeitpunkt 320 n.Chr.. Seit dem Jahr 1997 haben mehrere Universitäten und Institute aus den 

USA, Frankreich, Spanien, Kanada und Italien an einer Rekonstruktion des kompletten Stadt‐ 

körpers der antiken Stadt Rom gearbeitet [www.romereborn.virginia.edu]. Das Ergebnis der 

Kooperation ist ein historisches 3D‐Stadtmodell mit riesigen Ausmaßen. Dieses kann im Vir‐ 

tual Globe Google Earth nach Belieben erkundet werden. Die Geometrien und Texturen sind 

sehr detailliert und entsprechen einem LOD 3 im Kontext der 3D‐Stadtmodelle. Durch die 

Möglichkeiten von Google Earth können zusätzlich Metainformationen zu bestimmten Ge‐ 

bäuden angefordert werden, die den Informationsgehalt für den Betrachter weiter erhöhen. 

Dieses Projekt wird auch heute noch weiter aktualisiert und verbessert. Es verkörpert nach 

dem Wissensstand des Autors die bislang größte digitale historische Rekonstruktion einer 

Stadt. 

Abbildung 30: Anwendung Google Earth mit Inhalten von „Rome Reborn“ (Futura‐Sciences, 2009)


Beispiel: Inuyama Castle (Inuyama, Japan) 

Das Projekt „Inuyama Castle“ stellt eine sehr detaillierte Rekonstruktion in einer 3D‐Engine‐ 

basierten Anwendung dar. Der Umfang der integrierten Inhalte ist extrem groß. Dabei wird 

zum einen die Burg Inuyama inklusive der gleichnamigen Stadt und ihrer Umgebung visuali‐ 

siert, zum anderen werden zahlreiche Informationen über die Konstruktion der Gebäude 

sowie deren Bedeutung angezeigt. Die 1537 erbaute Burg gilt als eines der wichtigsten Na‐ 

tionaldenkmäler Japans [www.wikipedia.de]. Die Darstellungsqualität liegt in der Echtzeitvi‐ 

sualisierung bei einem LOD zwischen 3 und 4. Neben der manuellen Einstellung der Tageszeit 

und der Beleuchtung gibt es zahlreiche Menüs und Unterpunkte mit additiven Informationen 

und Überblendungsfunktionen. Der Hersteller des Modells ist Cadcenter Corporation. Eine 

genaue Recherche über den Erstellungsprozess oder Erstellungsaufwand war aufgrund der 

Sprachbarriere, nicht möglich, da sowohl die Anwendung als auch der Internetauftritt des 

Herstellers nur in Japanisch dargestellt werden. 

Abbildung 31: 3D‐Visualisierung der Burg Inuyama (Cadcenter Corporation, 2007)

Beispiel: Machu Picchu 


Das Modell von Machu Picchu, welches die gut erhaltene Bergstadt der Inka im heutigen 

Peru zeigt, stammt von Pavel Kornev. Auch hier war eine Recherche bezüglich Erstellungs‐ 

technik und Aufwand des Projektes aufgrund der Sprachbarriere nicht möglich. 

Das Modell wird ebenfalls mithilfe der Anwendung Quest 3D dargestellt und besitzt einen 

LOD 3 bis 4. 

Abbildung 32: 3D‐Visualisierung der Inkastadt Machu Picchu (Pavel Kornev, 2007) 

Die gezeigten Beispiele für bestehende digitale 3D‐Modelle zeigen teilweise eindrucksvoll, 

mit welcher Qualität und welchem Umfang historische Daten visualisiert werden können. 

Daneben ist fast immer eine Ausrichtung auf Dokumentation und Information festzustellen. 

Es bleibt festzustellen, dass digitale Rekonstruktionsmethoden und deren Visualisierung kei‐ 

ne exotischen Einzelfälle sind, sondern sehr zahlreich vorkommen. Die historischen 3D‐ 

Modelle haben sowohl einen wissenschaftlichen wie auch einen informativen Hintergrund. 

Wichtig zu erwähnen ist in diesem Kontext aber auch, dass die Erstellung solcher Modelle 

einen enormen finanziellen als auch personellen Aufwand bedeutet. Das Beispiel von „Rome 

Reborn“ zeigt dies sehr deutlich. Auf der Internetseite des Projekts sind allein 64 direkte Mi‐ 

tarbeiter des Projekts aufgelistet. Insgesamt sind ein halbes Dutzend Universitäten und ein 

Dutzend Institute aus Forschung und Wirtschaft beteiligt gewesen. Das Projekt begann 1997, 

und 2007 wurde veröffentlicht [www.romereborn.virginia.edu]. Durch diese Informationen 

ist eine ungefähre Vorstellung bezüglich der Kosten dieses Modells möglich. Dem enormen 

Aufwand zum Trotz sind der wissenschaftliche Wert und der Nutzen für die Allgemeinheit 

ebenfalls sehr hoch. Letzterer lässt sich aber nur schwer quantifizieren. 

Die Bedeutung solcher Projekte und deren Inhalte, nämlich die digitale Visualisierung von 

historischen Daten, soll im folgenden Kapitel behandelt werden. Besondere Aufmerksamkeit 

soll dabei der Bedeutung für die Planung zukommen.


3.3 Bedeutung für die Planung 

Im folgenden Kapitel soll die Bedeutung von digitalen historischen Stadtmodellen für die 

Planung diskutiert werden. Die Bedeutung von 3D‐Stadtmodellen im Allgemeinen ist zum 

Beispiel von ZEILE [2004] und KIRMSE [2006] ausführlich beschrieben worden und zeigt vor 

allem den Nutzen zur reinen Planungsvisualisierung, zur Öffentlichkeitsbeteiligung sowie für 

eine Bandbreite an Analyseanwendungen (z. B. Hochwassersimulation) auf. Die Diskussion 

über den Nutzen von historischen 3D‐Stadtmodellen für die Planung erfordert eine Ausei‐ 

nandersetzung mit der Abwägungsrelevanz von Stadtbaugeschichte, Stadtgestalt, histori‐ 

schen Kulturgütern sowie den Belangen der Denkmalpflege in der Planung. 

Ein Auszug aus dem BauGB gibt dazu Aufschluss: 

1. „Sie sollen dazu beitragen, …, die städtebauliche Gestalt und das Orts‐ und Land‐ 

schaftsbild baukulturell zu erhalten und zu entwickeln.“ [§1 Abs. 5 BauGB] 

2. „Zu berücksichtigen sind … die Erhaltung, Erneuerung, Fortentwicklung, Anpassung 

und der Umbau vorhandener Ortsteile.“ [§1 Abs. 6 Nr.4 BauGB] 

3. „Zu berücksichtigen sind … die Belange der Baukultur, des Denkmalschutzes und der 

Denkmalpflege, die erhaltenswerten Ortsteile, Straßen und Plätze von geschichtli‐ 

cher, künstlerischer oder städtebaulicher Bedeutung und die Gestaltung des Orts‐ 

und Landschaftsbildes.“ [§ 1 Abs. 6 Nr.5 BauGB] 

Daraus ergibt sich für die Planung: Bei der Entwicklung, Erhaltung oder dem Rückbau von 

Flächen, die die obigen Paragrafen berühren, sind deren Belange im Planungsprozess abwä‐ 

gungsrelevant. Ein Einsatz von historischen Modellen kann dabei die gesamte Bandbreite 

von möglichen Fällen unterstützen: die Erhaltung, die Entwicklung und die Anpassung von 

umgebender Bebauung. 

Bei der Erhaltung von historischer Substanz kann ein solches Modell zum einen die Akzep‐ 

tanz in der Bevölkerung durch die Schaffung eines kollektiven Bewusstseins dafür [TRIEB, 

1988] steigern. Zum anderen können über das Modell erhaltende Maßnahmen anschaulich 

kommuniziert werden. 

Bei der Entwicklung von historischer Substanz kann das Modell, das beispielsweise den Ur‐ 

zustand eines Ortes anzeigt, diesen in einer Planung den Beteiligten kommunizieren und 

möglichen Fehlentwicklungen vorbeugen. Insgesamt würde die Entwicklungsplanung eines 

Ortes durch die genaue Kenntnis seiner Vergangenheit optimiert. 

Bei der Anpassung von neuer Bebauung an historische Bausubstanz kann, wie im Kap. 2.2.5 

Beispiel 1 (Modernes Hotel in Bamberg) beschrieben, das historische Modell als zusätzlicher 

Maßstab eingesetzt werden. Mit einem Variantenmodell kann eine Diskussion über Pro und


Kontra einer Planung sinnvoll unterstützt werden. Auch in diesem Fall wäre eine Optimie‐ 

rung des Planungsergebnisses die Folge. 

Einbindung der Bevölkerung 

Die Einbindung der Bevölkerung in den Umgang mit historischer Bausubstanz stellt aufgrund 

von starken Disparitäten bezüglich des Informationsstandes ein Problem dar. Allerdings darf 

nicht vergessen werden, dass eben diese Bevölkerung das kollektive historische Bewusstsein 

einer Stadt verkörpert [KRAUSE, 1982]. In diesem Zusammenhang spielen folgende Fragen 

eine bedeutende Rolle: „Woher komme ich? Wo befinde ich mich? Wozu gehöre ich?“ 

KRAUSE [1982] postuliert weiter: „Eine Stadt ohne Erinnerungswert ist eine tote Stadt, so 

tot, wie ein Mensch sein kann, der sein Erinnerungsvermögen verloren hat.“ [KRAUSE, 1982] 

Aus dieser Überlegung heraus bekommt die Erhaltung des sog. Geschichtswertes eines Ortes 

eine völlig neue Bedeutung. Neben dem Geschichtswert eines Ortes gibt es nach KRAUSE 

[1982] noch den Gestaltwert und den Gebrauchswert eines Ortes. Wichtig ist aber, dass der 

Geschichtswert eines Ortes gesichert werden kann, indem historische Qualitäten eines Ortes 

für die Bevölkerung ablesbar gemacht werden. 

Das heißt z. B. für das Beispiel des Stadtkerns von Kaiserslautern, dass die Bedeutung der 

Überreste der Kaiserpfalz und des Casimirschlosses für die Bevölkerung sichtbar gemacht 

wird. Die Stadt und der Verein zur Erhaltung der Kaiserpfalz e.V. haben dazu verschiedene 

Ansätze verwirklicht: z. B. die farbliche Aufpflasterung der Mauerlinien der alten Kaiserpfalz 

oder das Aufstellen von Bronzemodellen. In diesem Zusammenhang ist ein digitales histori‐ 

sches 3D‐Stadtmodell eine neue Qualität dieser „Sichtbarmachung“ von gemeinsamer Ge‐ 

schichte. 

Entscheidungsträger 

Der Entscheidungsträger in diesem Gedankengang ist der gewählte Vertreter der Stadtbe‐ 

völkerung, ein Mitglied des Stadtrats. In der Regel ist dieser kein Experte in Belangen der 

Stadtgestaltplanung, der Denkmalpflege oder der Stadtbaugeschichte. Deshalb stellt insbe‐ 

sondere für die Entscheidungsträger der Einsatz solcher Modelle eine Verbesserung des Wis‐ 

sensstands dar. Zum Beispiel bei der Stadtgetaltplanung oder, wie in Kap. 1.2 beschrieben, 

bei der Neuplanung des historischen Areals im Stadtkern ist dieses „Mehrwissen“ ein plane‐ 

rischer Vorteil. „Nur ein ausreichender Wissensstand von Geschichte kann die Stadtgestalt 

begreiflich und verständlich machen.“[TRIEB, 1988] 

Bei der Gestaltung des Stadtbildes werden die Entscheidungsträger immer wieder vor eine 

Doppelfrage gestellt: „Wie kann man das Ortsbild in seinen unersetzlichen historischen Tei‐ 

len erhalten? Und Wie kann man das Ortsbild in seinen ersetzbaren Teilen neu gestalten?“ 

[TRIEB, 1988] 

Die Verwendung eines digitalen historischen 3D‐Stadtmodells stellt für die Entscheidungs‐ 

träger, wie schon erwähnt, einen Wissensvorsprung dar, der letztendlich der Bevölkerung 

zugutekommt.


Bisher war ein Urteil darüber, ob eine Veränderung oder ein Zustand der lokalen Historie 

angemessen oder zuwider erscheint, den Denkmalschützern aus den entsprechenden Äm‐ 

tern sowie Experten vorbehalten. Durch genannte historische Modelle sind Laien zwar im‐ 

mer noch nicht in der Lage zu entscheiden, wie mit historischer Substanz umzugehen ist, 

aber sie können die Entscheidungen besser verstehen und nachvollziehen. Hinzu kommt, 

dass die Einbindung der Öffentlichkeit in diese Prozesse dadurch leichter und Entscheidun‐ 

gen besser kommunizierbar werden [vgl. ZEILE, 2004]. 

Zusammenfassend lässt sich feststellen, dass die Erstellung und der Einsatz von digitalen 

historischen Modellen in der Planung alles andere als nutzlos sind. Sie stellen eine wertvolle 

Bereicherung der Wissensbasis aller Beteiligten dar. Da sie den Planungsprozess optimieren, 

werden auch die Kosten zu ihrer Erstellung relativiert. Abschließend soll ein Verweis auf die 

Verantwortung der Planung gegenüber der Allgemeinheit in Bezug auf die kulturellen, histo‐ 

rischen Güter einer Stadt gegeben werden [Vgl. §1 Abs. 5 BauGB]

3.4 Zwischenfazit 


Im abgeschlossenen Kapitel wurde die Herangehensweise an das Hauptthema, die Erstellung 

von digitalen historischen 3D‐Stadtmodellen, geschildert. Dabei wurden auf analoge Modelle 

und die Bedeutung von Geschichte für die Planung eingegangen. Es sollen zwei Fakten fest‐ 

gehalten werden. Zum einen ist eine Erstellung von digitalen historischen Modellen möglich, 

und zum anderen ist diese aus der Sicht der Planung sinnvoll und hilfreich. 

Nach der Erarbeitung der Grundlagen der Visualisierung von 3D‐Stadtmodellen im Allgemei‐ 

nen sowie der Grundlagen über historischen Modelle und ihrem Nutzen soll im nachfolgen‐ 

den Hauptkapitel nun der praktische Teil, die Erstellung des digitalen historischen 3D‐ 

Stadtmodells Kaiserslautern, erfolgen.

44 4. 3D‐Stadtmodell Kaiserslautern 

4. 3D Stadtmodell Kaiserslautern 

4.1 Reeller Anlass 

Nach der Diskussion über die Bedeutung von digitalen historischen Modellen im Allgemeinen 

soll im folgenden Hauptteil zu Beginn der reelle Anlass zur Erstellung eines 3D‐Stadtmodells 

dargelegt werden. 

Die Stadt Kaiserslautern verfügt über einen Stadtkern, der starke historische und städtebau‐ 

liche Bedeutung für die Stadt und seine Umgebung hat. Wie im Kapitel 1.2 schon erwähnt, 

plant die Stadt, den Bereich um das heutige Rathaus, speziell den Rathausvorplatz, die Um‐ 

gebung der bestehenden Ruinen sowie den Bereich um den Casimirsaal, neu zu gestalten. 

Seine historische Bedeutung soll stärker hervorgehoben und seine Einbindung in das beste‐ 

hende Tourismuskonzept soll durch die Neuplanung verbessert werden. 

Die Überlegungen gehen dabei von einem Nachbau des Casimirschlosses über die Restaura‐ 

tion bestehender Denkmäler bis zur völligen Neugestaltung der stark durch Autoverkehr 

geprägten Verkehrssituation. Forciert wird die Idee vom amtierenden Oberbürgermeister Dr. 

Klaus Weichel und dem Förderkreis zur Erhaltung der Kaiserpfalz e. V.. Die Zustimmung 

durch den Stadtrat ist vorhanden, und erste Planungen sind bereits durch ein Architekturbü‐ 

ro durchgeführt worden. Letzteres hatte schon eine touristische Erschließung eines unterir‐ 

dischen Gangsystems, welches sich unter dem Casimirsaal erstreckt, geplant und umgesetzt 

[Rheinpfalz, 2009]. 

Abbildung 33: Zeitungsartikel aus der Rheinpfalz (Medien Union GmbH, 2009)

4.2 Arbeeitsablauf 

In dieseen 

Planungssprozess 

solll 

nun exemmplarisch 

ein n detaillierttes 

Stadtmoodell 

integri iert wer‐ 

den, welches 

ersttens 

den aaktuellen 

PPlanungspro 

ozess unterrstützen 

kaann, 

zweite ens eine 

Grundlaage 

für ein ggesamtstäddtisches 

3D‐ ‐Stadtmode ell sein soll und drittenns 

eine Basis 

für ein 

touristissches 

Informmationssysttem 

rund umm 

die historische 

Bedeeutung 

des SStadtkerns 

bietet. 

Das nacchfolgende 

Organigrammm 

zeigt annschaulich 

den Arbeitssablauf 

(Woorkflow) 

zu ur Erstel‐ 

lung dess 

3D‐Stadtmmodells 

Kaisserslautern: 

Bewert tung aktueller DDaten 

Geommetrieerstellunng 

TTexturerstellungg 

Organisation 

der Geeometrie 

Vegetatio on 

Datenoptimie erung 

aktuelle a Daten 

Diagrammm 

2: Arbeitsablaauf 

(eigene Darrstellung) 

Bestanndsaufnahmme 

Teil 1 

Geeschichte 

der Sttadt 

Bestanndsaufnahmme 

Teil 2 

Bewwertung 

der DDaten 

Fesstlegung 

des LOD 

Erstellung des 


Teil 1 



Teil 2 

Lightmapping g 



Teil 3 

AAnwendungslog 

gik 

Publizieerung 

als Anwwendung 

4. 3D‐Stadtmodeell 

Kaiserslautern 

historische Daaten 

Beweertung 

historiscche 

Daten 

Texturierung 

DDatenexport 

Integration 

der Metadaaten 

45


4.3 Geschichte der Stadt 

Kaiserslautern kann als Stadt mit umliegendem Kreis auf eine sehr lange Historie als Sied‐ 

lungsgebiet zurückblicken. Sie wurde mehrfach zerstört und wieder aufgebaut. Daher wurde 

das Stadtbild des Öfteren völlig neu gestaltet. Teilweise sind aber noch Strukturen im Stadt‐ 

bild zu erkennen, die die Stadt in frühester Zeit geprägt haben. 

Der Stadtkern, der im Praxisteil der Arbeit umgesetzt wurde, hat eine einzigartige Geschichte 

und hat im Laufe der Zeit zahlreiche Wandlungen durchlaufen. Um diese zu verstehen und 

um die verschiedenen Zeitpunkte der Teilmodelle zu begreifen, soll im Folgenden ein kurzer 

Abriss der Stadtgeschichte vorgenommen werden. Die Bedeutung, die eine ausführliche 

Analyse der Geschichte hat, wurde bereits im Kapitel 3.3 von TRIEB [1988] geschildert. Die 

nachfolgende Chronologie erhebt trotzdem keinen Anspruch auf Vollständigkeit und wurde 

entlang der beiden Bücher zur Stadtgeschichte von Kaiserslautern von FRIEDEL [1995] entwi‐ 

ckelt. 

Abbildung 34: Zeichnung mit Wohnspeicherhäusern (Friedel, 1995) 

Erste Siedlungen bis 830 n.Chr. 

Der heutige Stadtkern liegt in einer geologischen Senke, dem „Kaiserslauterer Becken“, auf 

236m über NN. In diese Senke läuft der Bach Lauter aus dem südöstlich angrenzenden Pfäl‐ 

zer Wald kommend. Der Bach fließt von Osten nach Westen durch die Senke hindurch. Das 

Stadtgebiet war damals geprägt von Sumpflandschaft und sich dazwischen erhebenden In‐ 

seln aus Sandstein. Die Vegetation bestand wahrscheinlich aus Laubwald und Feuchtwiesen, 

dies lässt sich zumindest aus den vorhandenen Bodenverhältnissen schließen. Durch Funde 

im nördlichen Bereich des Kaiserslauterer Raumes bei Eulenbis wurde belegt, dass schon der 

Neanderthaler diese Gegend bewohnt hat. Weitere Funde im heutigen Ortsteil Kaiserslau‐ 

tern Dansenberg bestätigen Kaiserslautern als Siedlungsgebiet bis ins Jahr 30000 v.Chr. Die 

nächste nachgewiesene Kultur, die Bandkeramiker, siedelten im Bereich des heutigen Ra‐ 

thauses bis zum Rittersberg. Weiterhin ist bekannt, dass entlang der West‐Ost‐Achse der 

Stadt ähnlich der heutigen Autobahn eine sehr alte Völkerstraße verlief. Belege dafür sind 

z.B. die im Stadtgebiet und der Umgebung gefundenen „Menhire“, keltische Hinkelsteine. 

Bis ins fünfte Jahrhundert v. Chr. sind durch zahlreiche weitere Funde Siedlungsaktivitäten 

nachgewiesen. Die Zeit zwischen 500 v.Chr. und etwa 300 n. Chr. ist hingegen nur durch un‐ 

genaue Überlieferungen und Sagen belegt. Allerdings wurden bei Ausgrabungen im Bereich 

der Stiftskirche römische Münzen gefunden, die eine spätrömische Ansiedlung in Kaiserslau‐


tern bestätigen. Ähnliches berichtet eine spätmittelalterliche Chronik. Es soll sich um ein 

römisches Kastell gehandelt haben, das bei der Völkerwanderung um 440 n. Chr. von den 

Hunnen zerstört wurde. In der Zeit der Merowinger und des aufkommenden Reisekönigstum 

wurde um etwa das 6. Jh. n.Chr. der Königshof, also eine Pfalz, neu gegründet. Dabei gab es 

zwei Bereiche, die durch Gräberfunde die fränkische Siedlung verortbar machen: Zum einen 

gab es eine erste Burganlage im Bereich des heutigen Rathauses, welche die Wehrmöglich‐ 

keiten der felsigen Umgebung und der direkten Nachbarschaft der Lauter nutzte, und eine 

weitere Siedlung im Bereich der Stiftskirche. Demnach kann man von mehreren „Entwick‐ 

lungskernen“ sprechen, bevor die Stadt einen zusammenhängenden Stadtkörper bildete. 

Abbildung 35: Handzeichnung von Franz Joseph Kisling aus dem Jahr 1764 (Friedel, 1995) 

830 n. Chr. bis 1565 n. Chr. 

830 n. Chr. wurde die Stadt im Lorscher Reichsurbar, einem frühmittelalterlichem Liegen‐ 

schaftsverzeichnis, erstmals als „villa Luthra“ erwähnt. In mehreren weiteren Urkunden aus 

dem 9. Jh. ist zu entnehmen, dass Kaiserslautern als karolingischer Königshof von überregio‐ 

naler Bedeutung bekannt war. 915 ging der Hof von der karolingischen an die salische Linie 

über. Auch im Jahr 1151 wird der Ort noch als „curtis“ (lat. Hof) geführt. Im südöstlichen 

Bereich der Burganlage wurde eine 1,4m starke erste Wehrmauer aus spätsalischer Zeit 

nachgewiesen. Diese gehörte vermutlich zu einer burgähnlichen Ansiedlung, welche nieder‐ 

adlige Ministeriale beherbergte. Noch heute ist dieser Bereich unter dem Namen Rittersberg 

bekannt. Um das Jahr 1152 n. Chr. kam es dann unter Kaiser Friedrich I. (genannt „Rotbart“ 

oder „Barbarossa“) zum Bau eines Palastes samt Befestigung. Dabei wurde eine bestehende 

Burganlage von Kaisers Friedrichs Vater Herzog Friedrich fast komplett überbaut. Die Anlage 

war von 1152 bis 1158 n. Chr. „domum regalem“, also das Heim des Königs. 1162 ernannte 

Kaiser Friedrich Gotfried von Luthra, der als der Stammvater der Ritter von Hohenecken gilt, 

zum Burgverwalter. Diese Anlage wurde von Barbarossas Sohn Heinrich VI. um 1195 n. Chr. 

noch ausgebaut und erweitert. Friedrichs Enkel Friedrich II. nahm 1215 Änderungen an der 

Burg vor und hält in Kaiserslautern 1234 einen Hoftag ab. Ab 1215 n. Chr. wird die Stadt in 

Urkunden auch nicht mehr unter der Bezeichnung „villa“ geführt, sondern steigt zur „bur‐ 

gus“ auf. Die Übersetzung der beiden Begriffe ist schwierig: So kann das Wort „villa“ jede


mögliche Siedlungsform von Gut über Dorf bis zur Stadt alles bedeuten. In der damaligen 

Verwendung handelte es sich aber um die Bezeichnung für einen Weiler oder ein Dorf. Das 

Wort „burgus“ gibt es im Lateinischen nicht, meint aber die Siedlung samt zugehöriger Burg. 

Aus den folgenden Jahren gibt es verschiedene Bezeichnungen wie „luthra imperialis“ (kai‐ 

serliches Lautern, 1237) oder „civitas regia“ (des Königs eigene Stadt, 1260), was den Auf‐ 

stieg Kaiserslauterns zur Stadt widerspiegelt. Eine weitere Ehre wird der Stadt 1269 zuteil, 

als in der Burgkappelle der englische König Richard seine Frau Beatrix von Falkenburg ehe‐ 

lichte. Spätestens 1276 n.Chr. werden Kaiserslautern durch Rudolf von Habsburg die Stadt‐ 

rechte verliehen, und die Stadt wird somit zur Reichsstadt. Sie ist damit anderen großen 

Städten wie z. B. Speyer rechtlich gleichgestellt. In den Jahren 1256 und 1288 kam es zu zwei 

schweren Bränden, wobei große Teile der damals eng bebauten Stadt zerstört wurden. Un‐ 

ter König Albrecht bekommt die Stadt 1303 ein großes Stück Reichswald geschenkt. Im Laufe 

des 14. Jh. wird die Reichsstadt Kaiserslautern mehrmals verpfändet und wird durch Kurfürst 

und Pfalzgraf Ruprecht I. ausgelöst und somit kurpfälzische Stadt. Sie hat nun den Rang einer 

Oberamtsstadt. Verwaltungstechnisch entwickelt sich die Stadt seit der Stadtrechtsverlei‐ 

hung und bekommt einen Stadtrat, der sich aus zwei Teilen zusammensetz: einem Rat der 

Zwölf und einer Vertretung der in der Stadt verbreiteten Zünfte mit 22 Mitgliedern. In den 

Jahren 1440 und 1510 werden die ersten Stadtordnungen erlassen und 1516 wird das erste 

Rathaus von Kaiserslautern gebaut. Das mittelalterliche Wesen der Stadt ist typisch für ihre 

Zeit. Die Stadt profitiert von den Privilegien, eigene Märkte zu unterhalten. Um 1565 n. Chr. 

entsteht am heutigen Stiftplatz ein Marktplatz. Die Verteidigung wird üblicherweise von den 

Zünften übernommen. Jeder Zunft unterstand im Verteidigungsfall ein Stadtmauerabschnitt 

mit Wehrturm. Die Türme waren nach der jeweiligen Zunft benannt (z. B. Metzgerturm). 

1565 bis 1815 

Unter Kurfürst Johann Casimir entsteht von 1575 bis 1581 n. Chr. neben der Burganlage ein 

Renaissanceschloss. In den Jahren kurz vor dem Dreißigjährigen Krieg wurden unter dem 

Festungsbaumeister Stapf die Wehranlagen erweitert. Während Kaiserslautern die ersten 

Kriegsjahre relativ unbeschadet überstand, kam es 1635 n. Chr. zum so genannten „Kroa‐ 

tensturm“ unter der Führung von Graf Melchior von Hatzfeld. Dieser belagerte die Stadt erst 

mit Kanonen, welche schwere Schäden an den Verteidigungsanlagen verursachten, und gab 

dann die Stadt zu Plünderung frei. Dabei kam es zu einem Blutbad unter der Zivilbevölke‐ 

rung. Auch die Burg und das Schloss nahmen Schaden, wurden aber später, nach dem Krieg, 

auf Anweisung wieder instand gesetzt. Bis zum Kriegsende 1648 n. Chr. wurde die Stadt von 

vielen verschiedenen Kriegsparteien besetzt und geplündert. 1679 n. Chr. wurden am 

Schloss neue Bollwerke errichtet, und die schwerbeschädigte Wehranlage, bestehend aus 

Mauer und Türmen, wurde renoviert. In der Folge kam es 1688 zum „Pfälzischen Erbfolge‐ 

krieg“ in dem Kaiserslautern von den Franzosen besetzt wurde. Die Stadt wurde wieder be‐ 

lagert und mit Kanonen beschossen. Es gab allerdings keine erheblichen Zerstörungen. Das 

Schloss wurde leicht beschädigt. Es wurde aber in der kurzen Friedenszeit zwischen 1697 n. 

Chr. und 1701 n. Chr. wiederhergestellt und auch wieder bewohnt.

Abbildung 36: Kupferstich der Kaiserslautern im Jahr 1620 zeigt (Merianstich), (Friedel, 1995) 


Im folgenden „Spanischen Erbfolgekrieg“ kam es erneut zur Belagerung und Besetzung durch 

die Franzosen. Die Stadtbevölkerung wurde gezwungen einen Großteil der Verteidigungsan‐ 

lagen zu schleifen, also zu beseitigen. Dabei wurden fast die gesamte Stadtmauer, die Wehr‐ 

gänge und die Verteidigungstürme der Zünfte zerstört. Weiterhin wurden die Befestigungen 

des Schlosses und dessen Türme gesprengt. Kurz darauf wurden wieder Befestigungsanlagen 

gebaut, allerdings keine Stadtmauer, sondern Bastionen, Schanzen und Gräben. Diese wur‐ 

den vor allem um den Schlossbereich errichtet. Einen guten Eindruck davon gibt eine Litho‐ 

grafie des Malers Neumann von 1706. Ein Belagerungsversuch im Jahre 1713 n. Chr. durch 

die Franzosen scheiterte mangels der Verfügbarkeit von Kanonen. 

Abbildung 37: Schloß und Kaiserpfalz um 1706 (Friedel, 1995)


Abbildung 38: Grundrissplan der Burg mit Schloss von 1713 (Friedel, 1995) 

Der Siebenjährige Krieg und andere europäische Auseinandersetzungen brachten immer 

wieder Truppendurchmärsche, welche die Stadt belasteten. Dann folgte eine Periode des 

Friedens, die der Stadt wirtschaftlichen Aufschwung brachte. Auch die industrielle Revoluti‐ 

on war schon spürbar. In der Stadt wurden zahlreiche Unternehmen gegründet, wie z. B. die 

Siamosemanufaktur (Siamose = spezieller Baumwollstoff) „Karcher & Co“, welche mit 2000 

Angestellten das größte Unternehmen der Kurpfalz war. Auch wissenschaftlich war Kaisers‐ 

lautern ein Vorreiter in der Kurpfalz und darüber hinaus. 1774 ging aus der „Kurpfälzischen 

physikalisch‐ökonomischen Gesellschaft“ die „Kameral Hohe Schule“ hervor, ein Institut der 

Kameralwissenschaft. Diese forschte auf den Bereichen Wirtschafts‐ und Verwaltungswesen 

und in der Land‐ und Forstwirtschaft. Die Schule kann als Vorläufer der Universität in Kaisers‐ 

lautern gelten. Allerdings wurde sie 1784 wegen Streitigkeiten mit der Bürgerschaft und der 

lokalen Wirtschaft nach Heidelberg verlagert. 

Dann kam die Französische Revolution, welche mit ihren Kriegen und der anschließenden 

Expansion unter Napoleon für Kaiserslautern große Entbehrungen bedeutete. Nach der 

Schlacht bei Morlautern 1793 wurde Kaiserslautern 1794 schwer gebrandschatzt. Aufgrund 

des fehlenden Brandschutzes wurden das Schloss und die Burg Opfer der Flammen. Es wur‐ 

de seitdem nicht wieder aufgebaut. Kaiserslautern stand nun unter französischer Besatzung 

und bekam 1797 auch Frankreichs Verwaltungsstruktur diktiert. 1802 wurden der Stadtver‐ 

waltung die angrenzenden Orte Dansenberg, Erlenbach, Hohenecken und Morlautern angeg‐


liedert. Die Verwaltung selbst wurde in das Gervinus’sche Haus am heutigen Martinsplatz 

verlegt. Weiterhin wurden die letzten Reste der Stadtmauer versteigert und der Marktpfor‐ 

tenturm wurde abgerissen. Auch das Fackeltor wurde beseitigt, es stand dort, wo später das 

Fackelrondell entstand. Durch die Besatzung erlebte Kaiserslautern eine überregionale Auf‐ 

wertung, denn die Franzosen legten eine ihrer Heerstraßen durch die Stadt. Die Kaiserstraße 

Paris – Mainz existiert bis heute, allerdings unter anderem Namen: Heute heißt sie Parisers‐ 

traße. Auch die Wirtschaft wurde durch die Franzosen belebt, und es entstanden neue Fab‐ 

riken. Die Besatzung endete 1814. Aufgrund ihrer Funktion als Truppenstützpunkt hatte die 

Stadt um diese Zeit schwere Befestigungen bestehend aus Schanzen und Verhauen, vor al‐ 

lem im westlichen Bereich. 

Abbildung 39: Centralgefängnis auf einer Darstellung von 1830 (Friedel, 1995) 

1815 bis 1945 

Nach dem Wiener Kongress 1815 wurde dem 1806 entstandenen Königreich Bayern die 

komplette linksrheinische Pfalz zugesprochen. Diese hieß erst „Bayrischer Rheinkreis“ und ab 

1838 dann Pfalz. 

1825 wurde das „Centralgefängnis“ im Auftrag der bayrischen Regierung gebaut, mit dem 

Ziel Arbeitsplätze zu schaffen. Es wurde auf den Überresten des Schlosses und der Burg er‐ 

baut. Auf dem Rittersberg entstand ein Lehrerseminar. Die in der Franzosenzeit angeglieder‐ 

ten Orte wurden nun wieder selbstständig. 1821 entstand auf dem „Kottenfeld“ ein Kran‐ 

kenhaus und 1930 wurde hier die erste Stadterweiterung der Neuzeit umgesetzt. Auch im 

Vorfeld des alten Fackeltors entstand ein neues Wohngebiet, die so genannte „Pariser Vor‐ 

stadt“. Die Stadt entwickelte sich in westliche Richtung. Als Achsen sind zu nennen: die heu‐ 

tige Pariserstraße, entlang welcher schon in der Franzosenzeit gebaut wurde, und die heuti‐ 

ge Mühlstraße, welche damals zusammen mit der Fackelstraße eine zentrale Verkehrsachse 

bildete. 1833 wurde die Kreisgewerbeschule am damaligen Maxplatz gebaut, ein Vorläufer 

der heutigen Berufsschule mit überregionaler Bedeutung. 1836 entstand am Stiftsplatz die 

erste Sparkasse von Kaiserslautern. Die Stadt wuchs und der in der heutigen Albrechtsstraße


gelegene Friedhof wurde um einen neuen an der heutigen Mannheimer Straße erweitert, 

der bis heute der städtische Hauptfriedhof ist. Um 1843 entstand auch ein heutiges Wahr‐ 

zeichen von Kaiserslautern, die Fruchthalle. Kaiserslautern hatte, bedingt durch die gute La‐ 

ge an der überregionalen Handelsader der Kaiserstraße, seit etwa 1771 einen bedeutenden 

Fruchtmarkt. Um diesen auch bei Regenwetter abhalten zu können, entschloss man sich zum 

Bau der Halle nach dem Vorbild eines florentinischen Palastes. Zur Grundsteinlegung kam 

unter anderen König Ludwig I. von Bayern. 

Einen weiteren Schritt in Richtung Wachstum machte die Stadt 1845, als man beschloss, Kai‐ 

serslautern an das Eisenbahnnetz, welches in ganz Deutschland in der Entstehung war, anzu‐ 

schließen. Die Linie Neustadt – Kaiserslautern – Bexbach erschloss als „Pfälzische Ludwigs‐ 

bahn“ die Bergbauregionen im Saarland für die östlichen Absatzmärkte. Die Einführung der 

Eisenbahn brachte die Geschäfte der Fuhrbetriebe zwar zum Erliegen, bedeutete für Kaisers‐ 

lautern insgesamt einen großen Segen wirtschaftlicher Natur, da man nun mit den Rheinhä‐ 

fen verbunden war. 

Es folgten die deutschen Revolutionsjahre, in welchen Kaiserslautern eine nicht unerhebliche 

Rolle spielte. 1849 kam es zur Loslösung der Pfalz von Bayern. Dabei tagte die provisorische 

Revolutionsregierung in der Fruchthalle von Kaiserslautern, da die Stadt die Hauptstadt der 

geplanten Republik sein sollte. Mitte des Jahres 1849 wurde der „Spuk“ durch den Ein‐ 

marsch der preußischen und der bayrischen Armee beendet. Nach einer Zeit der Strafbesat‐ 

zung ging Lauterns Aufstieg zur Industriestadt weiter. Begünstigt durch die Eisenbahnlinie 

folgten in den Jahrzehnten bis zur Reichsgründung und darüber hinaus zahlreiche Unter‐ 

nehmensgründungen. 1857 wurde die Kammgarnspinnerei gegründet, 1862 begann der be‐ 

reits ortsansässige Unternehmer Georg Pfaff, Nähmaschinen in seinem Werk zu produzieren, 

und auch der heute noch stadtbekannte Industrielle Jakob Pfeiffer gründete 1864 mit seiner 

ersten Dampfmaschine die Gebr. Pfeiffer Barbarossawerke. Letztgenannte stellten das erste 

Industriegebiet der Stadt dar. Bedingt durch das wachsende Arbeitsplatzangebot stieg nun 

auch die Bevölkerungszahl stärker an. Während es 1834 noch 7.375 Einwohner waren, war‐ 

en es 1861 schon 11.996 und zur Reichsgründung 1871 18.040. Schon 1860 hatte Kaiserslau‐ 

tern Speyer in puncto Einwohnerzahl überholt und wurde zur einwohnerstärksten Stadt der 

Pfalz. Diesen Rang lief ihr erst 1898 die Stadt Ludwigshafen ab. 1873/74 werden auf dem 

Kotten weitere Wohnungen gebaut, um die Landflucht aufzufangen. Die Zustände und die 

Lebensqualität unter der arbeitenden Bevölkerung waren, ähnlich wie in anderen Städten in 

dieser Zeit, teilweise katastrophal. Es kam zur Bildung von Arbeiterräten und Gewerkschaf‐ 

ten. Trotz dieser Missstände erlebte Kaiserslautern einen wirtschaftlichen Aufschwung, der 

sich auch am Stadtbild ablesen ließ. Es entstanden zahlreiche prächtige Bauten, wie die bei‐ 

den Hotels „Schwan“ (1870) und „Karlsberg“ (1873). Auch die Infrastruktur der Stadt wurde 

ausgebaut. Der Bahnhof wurde 1879 durch einen Neubau ersetzt, und der heutige Stadtpark 

entstand 1876. Die Zeit bis zu Jahrhundertwende ist gekennzeichnet durch den Bau vieler 

neuer Gebäude, die das Stadtbild bis heute prägen. Die 1870er und 1880er Jahre waren die 

Entstehungszeit vieler Lauterer Schulen, wie dem heutigen Franziskaner‐Gymnasium oder 

dem Albert‐Schweizer‐Gymnasium.

Abbildung 40: Darstellung der Fruchthalle um 1875 (Friedel, 1995) 


1880 wurde ein Gewerbemuseum gebaut, 1886 die Synagoge der jüdischen Gemeinde. Für 

das Stadtbild besonders prägend war auch das Kanalisierungsprojekt, welches die Stadtobe‐ 

ren nach einigen Typhusfällen unter der Bevölkerung 1882 initiierten. Dabei wurde ein Groß‐ 

teil der Stadt, in der es seit jeher Wasser gab und die früher von großen Weihern umgeben 

war, trockengelegt. Das populärste „Opfer“ dieser Aktion war die Lauter, welche unter die 

Erde verlegt wurde. Eine weitere Entwicklung wurde mit dem Stadterweiterungsplan des 

damaligen Stadtplaners Eugen Bindewald beschlossen. Dieser sah eine weiträumige Planung 

über die damaligen Grenzen der Bebauung hinaus vor. Ein besonderes Merkmal war die die 

Stadt umschließende große Ringstraße. 

Abbildung 41: Ausschnitt des Bindewaldplans von 1889 (Stadt Kaiserslautern, 2008)


In den 1890er‐Jahren und um die Jahrhundertwende schloss man die letzten infrastrukturel‐ 

len Lücken. Kaiserslautern bekam mit der Marienkirche (1892) und der Apostelkirche (1901) 

zwei große Gotteshäuser. 1890 entstand ein neues Postamt und 1893 an der Stelle des heu‐ 

tigen Klinikums ein Krankenhaus. 1894 kam das erste E‐Werk und 1897 das Finanzamt. Der 

zu dieser Zeit aufkommende Gebrauch des Fahrrads spiegelte sich auch in Kaiserslautern in 

der Gründung eines Vereins und dem Bau einer Rennbahn wieder. Diese lag auf dem Gebiet 

rechts der Donnersbergerstraße. Freizeit war für das Gros der arbeitenden Bevölkerung noch 

relativ neu, jedoch möglich gemacht durch die Sozialreformen Bismarks. Das Freizeitangebot 

wurde mit dem Waschmühlbad (1906) und dem Humbergturm (1900) verbessert. Letzterer 

gilt bis heute als ein Wahrzeichen der Stadt. Um 1900 zählte die Stadt 48.310 Einwohner. 

Die Industrie florierte, und die bereits ansässige Firma Pfaff siedelte ihre Produktionsstätten 

von der Mozartstraße in die Königsstraße um, wo sie noch heute in Betrieb ist. 1912 löste 

Hermann Hussong Eugen Bindewald als Stadtplaner der Stadt ab. Zu seinen ersten Maßnah‐ 

men gehörte die Erweiterung des, 1874 an der Donnersbergerstraße angelegten Zentral‐ 

friedhofs. Dieser wurde zum damals größten Waldfriedhof Deutschlands. Im Konkurrenz‐ 

denken der Städte untereinander forderte die Bürgerschaft von Kaiserslautern schon zu Be‐ 

ginn des neuen Jahrhunderts von der Stadtobrigkeit eine Straßenbahn. Diese wurde im 1. 

Weltkrieg 1916 in Betrieb genommen. Militärisch war Kaiserslautern zuvor 1912 mit einer 

neuen Kaserne, der Panzerkaserne in der Mannheimerstraße, zur Garnisonsstadt geworden. 

Kurz vor Kriegsausbruch hatte Kaiserslautern 57.826 Einwohner. Bis auf einen Luftangriff im 

Jahre 1918, bei dem es aber keine bedeutenden Schäden gab, überstand die Stadt den Welt‐ 

krieg relativ unbeschadet. Zu Kriegsende gab es in der Stadt wie in vielen anderen Städten 

Unruhen, welche von einem Arbeiter‐ und Soldatenrat angeführt wurden. Dann wurde die 

Stadt von den französischen Streitkräften besetzt. Die Besatzungszeit endete erst 1930. 

Durch einen Regierungsbeschluss wird Kaiserslautern 1920 mit mehreren anderen Städten 

zur kreisfreien Stadt. Im selben Jahr wurde der „Fußballplatz“ Betzenberg eröffnet, welcher 

in der späteren Geschichte noch größere Bedeutung für die Stadt erlangen sollte. Ebenfalls 

1920 wird das sogenannte Technikum gegründet, welches später 1922 in eine staatliche 

Lehranstalt mit Hochschulrang umgewandelt wurde. In der Stadt herrschte Wohnungsnot 

und mit der Gründung der BAU‐AG wurde diesem Problem 1921 Rechnung getragen. In den 

Jahren 1923 und 1924 wurde Kaiserslautern nicht nur von der Inflation und deren Auswir‐ 

kungen getroffen, sondern auch von revolutionären Umsturzplänen. Die linksrheinische, von 

den Franzosen besetzte Zone welche separatistische Bewegungen unterstütze, scheiterte 

aber am Widerstand der Bevölkerung und der Ablehnung der Alliierten Frankreichs. In der 

Zeit der Weimarer Republik wuchs Kaiserslautern weiter, und unter Leitung von Hussong 

entstanden von 1920 bis 1928 an der Königsstraße, der Fischerstraße, der Bismarkstraße und 

der Altenwoogstraße Wohnanlagen. Besonders der Rundbau in der Königsstraße und der 

Wohnblock an der Altenwoogstraße waren städtebauliche Akzente. 1923 kam der Stadt 

durch eine Einzelspende eines betuchten Stadtsohnes ein kleines Vermögen zu, welches in 

einem Ausstellungsgelände an der Donnersbergerstraße im Bereich des heutigen Volksparks 

liegt, verbaut wurde. Das im Stil des Bauhauses errichtete Gebäude der heutigen Hauptpost 

entstand 1929, dem Jahr der Weltwirtschaftskrise. Diese traf auch Kaiserslautern. Einige tra‐


ditionsreiche Betriebe gingen zu dieser Zeit Konkurs, z. B. die „Pfälzische Nähmaschinen und 

Fahrradfabrik“, die früher Gbr. Kayser hieß. Die Zahl der Arbeitslosen und der Unterstüt‐ 

zungsempfänger stieg stark an und begünstigte den Weg zur Machtergreifung der National‐ 

sozialisten 1933. Am Anfang des Dritten Reiches 1933/34 wurden im Rahmen von Notver‐ 

ordnungen neue Siedlungen in Kaiserslautern errichtet: Z. B. in der Saarbrücker Straße (Bel‐ 

zappel), Lothringer Dell, Grübentälchen, Lämmchesberg und an der Pariser Straße. Die meis‐ 

ten Siedlungsgebiete wurden im Heimatstil bebaut. Ein weiteres Großprojekt wurde 1934 

von den Nazis initiiert. Am Nordrand der Stadt wurde mit dem Bau der Autobahn A6 begon‐ 

nen. Im Zuge dessen entstanden auch die beiden stadtbildprägenden Brücken, die Wasch‐ 

mühltalbrücke und die größere Lautertalbrücke. Die Pläne Hitlers, eine überregionale Ver‐ 

bindung zu schaffen, um Truppen schnell nach Frankreich zu bringen, brachte für Kaiserslau‐ 

tern Unheil und Segen gleichermaßen. So nutzten die alliierten Bomber die Autobahn, um 

sich im Feindesland zu orientieren und ihre Bombenlast über den deutschen Städten abzu‐ 

werfen. Heute stellt die Autobahn eine bedeutende europäische Ost‐Westverbindung dar, 

von der die Stadt profitiert. 

In den Jahren 1932 bis 1936 kam es zu wissenschaftlichen Grabungen auf dem alten Burgge‐ 

lände, und große Teile des Pfalzgrafensaales wurden freigelegt und restauriert. Weiterhin 

legte man 1935 den Kreuzgang des Barfüßerklosters frei. Man besann sich auf die Größe, 

welche Kaiserslautern in der Historie als Kaiserpfalz hatte und nutzte die Grabungen auch 

ideologisch. Die Ideologie der Nazis brachte auch deren gigantomanische Stadtplanung in die 

Stadt. Die Regierung sah vor, dass Kaiserslautern die Hauptstadt des Gaues „Saarpfalz“ wer‐ 

den sollte. In diesem Zuge plante man, den Stadtkern großflächig abzureißen und mit einem 

riesigen „Gauhaus“ samt Verwaltungsblock in „neuheidnischer Sakralarchitektur“ zu verse‐ 

hen. Es sollte große Parade‐ und Aufmarschstraßen geben, die radial auf das neue Zentrum 

zuliefen. Dieser Planung wären große Teile der Innenstadt zum Opfer gefallen, z. B. die 

Fruchthalle. Das alte bayrische Zentralgefängniss wurde zu diesem Zweck 1938 abgerissen. 

Abbildung 42: Luftbild von einem Luftschiff aus aufgenommen (um 1914) (Friedel, 1998)


Abbildung 43: Front des Casimirsaal um 1937 (Friedel, 1998) 

Im selben Jahr wurde offiziell auch die prächtige Synagoge gesprengt. Wenig später, zur 

Reichskristallnacht, brannten im ganzen Land die Synagogen. Städtebaulich erwähnenswert 

ist noch die Umfunktionierung des Fackelrondells zu einem Verkehrsplatz 1939. Im Zuge der 

massiven Aufrüstung im ganzen Land und der Mobilmachung des Deutschen Reiches wurde 

auch Kaiserslautern 1936 wieder Truppenstandort, und die Industriebetriebe stellten ihre 

Produktion auf Kriegsgerät um. 1939 begann dann der Krieg. Am Anfang wurde Kaiserslau‐ 

tern noch überflogen und stattdessen die Industriestädte am Rhein ins Visier genommen. 

1940 jedoch kam es zum ersten Luftangriff. Der Hauptbahnhof wurde dabei beschädigt, und 

es gab erste Opfer. Gegen Ende des Krieges 1944 legten drei schwere Bombardements die 

Stadt fast komplett in Schutt und Asche. Vor allem die Innenstadt und der Norden der Stadt 

waren danach ein riesiges Trümmerfeld, und nur wenige Häuser blieben stehen. Am stärk‐ 

sten war u.a. der Kotten betroffen. Kurz vor dem Zusammenbruch des Dritten Reiches am 

19. März 1945 wurde die Lautertalbrücke gesprengt, um den Vormarsch der Alliierten doch 

noch aufzuhalten. Einen Tag später standen die Voraustrupps der US‐Armee in Otterbach. 

Günstigen Umständen ist es zu verdanken, dass die verbliebenen Streitkräfte der Wehr‐ 

macht keinen Widerstand leisteten und sich ergaben. Die Stadt wurde friedlich besetzt, und 

der Krieg war für Kaiserslautern vorbei. 

1945 bis heute 

Die Schäden waren beträchtlich, und die Stadt sah einer schwierigen Zeit des Wiederaufbaus 

entgegen. Nicht nur die Amerikaner besetzten die Stadt, sondern auch die Franzosen nah‐ 

men abermals ihre Rolle als Besatzungsmacht in der Stadt ein. Das Leben in der französi‐ 

schen Zone war wie im Rest von Deutschland bestimmt durch Lebensmittelknappheit, Teue‐ 

rung, Schleichhandel und Hunger. Überall wurden aus den Überesten der Fabriken Großge‐ 

rät und Maschinen geborgen und nach Frankreich abtransportiert, da Deutschland Repara‐ 

tionen abzuleisten hatte. 1946 wurde per Verordnung der Militärregierung das Land Rhein‐ 

land‐Pfalz geschaffen, und Kaiserslautern gehörte dazu. 1947 wurde per Volksabstimmung 

entschieden, dass das neu geschaffene Land weiterhin zu Deutschland gehören soll und 

nicht von Frankreich annektiert werden solle.

Abbildung 44: Denkmal an der Fruchthalle kurz nach dem Kriegsende 1945 (Friedel, 1998) 


Die Spitze der Verwaltung der Stadt übernahm 1945 der stadtbekannte Bürgermeister Alex 

Müller und diente der Stadt in den Jahren des Wiederaufbaus bis 1956. Die Aufräumarbeiten 

in der Stadt waren mühsam, schritten aber voran. Allerdings wurde zu dieser Zeit kein Wert 

mehr auf die alten gewachsenen Strukturen gelegt, sondern durch Zerstörung geschaffenen 

Baulücken wurden als Verbindung wahrgenommen, und ein neues Straßennetz entstand. 

Das alte Netz des 19. Jh. erschien nicht erhaltenswert. 

Die Stadt erlebte in den folgenden Jahren einen Bauboom, da sehr viel zerstört war und der 

Bedarf an Wohnungen und Infrastruktur pressierte. 

1949 gehörte Kaiserslautern dann wieder zu einem Staat, der neugegründeten Bundesre‐ 

publik Deutschland. Es kam in den Jahren bis 1962 zu starken Wanderungsbewegungen in‐ 

nerhalb Deutschlands und aus den ehemaligen von Deutschen bewohnten Gebieten. Vor 

allem aus Schlesien, dem Sudetenland und Ostpreußen strömten monatlich bis zu 3000 

Menschen nach Rheinland‐Pfalz, etwa 165 (monatlich) nach Kaiserslautern. Es wurden drin‐ 

gend Wohnungen benötigt. In den Jahren 1950 bis 1953 wurde die Siedlung am Kotten wie‐ 

deraufgebaut, und die Siedlungsgebiete des Pfaffenberges des Fischerrücks und des Bännjer‐ 

rücks entstanden. Ebenfalls in diese Zeit fällt der Bau der größten Siedlung für US‐Bürger 

außerhalb der Vereinigten Staaten von Amerika. 1951 wurde für die 40000 auf der Airbase 

Ramstein und Kaiserslautern stationierten Soldaten die Siedlung Vogelweh im Westen der 

Stadt gebaut. 1954 und 1955 schritt der Sozialwohnungsbau weiter voran, und Wohneinhei‐ 

ten entstanden in der Daniel‐Haberle‐Straße, der Ebertstraße, der König‐Straße, dem Benzi‐ 

noring und dem Gersweilerweg. 1954 wurde der Bau der Sparkasse beendet. Es herrschte 

Aufbruchsstimmung, und das deutsche Wirtschaftswunder wirkte. Gekrönt wurde die Zeit 

durch die gewonnene Fußballweltmeisterschaft 1954. Letztere hat für die Stadt größere Be‐ 

deutung, da fünf Spieler der Siegerelf Lauterer waren. Kaiserslautern war kurzzeitig deutsch‐ 

landweit bekannt.


1956 folgte Alex Müller zum Ende seiner Amtszeit der ebenfalls stadtbekannte Dr. Walter 

Sommer als Bürgermeister. In seine Amtszeit fielen der Neubau des Hauptbahnhofs 1958, 

der 1954 nur mit einer nüchternen Empfangshalle versehen worden war, und der des Amts‐ 

gerichts. Die Ver ‐ und Entsorgung der Stadt wurde 1959 mit dem Neubau einer Kläranlage 

vorangetrieben. Dr. Sommer initiierte die Großsiedlungsprojekte auf dem Bännjerrück 

(1957‐1970) und dem Betzenberg (1966‐1973). Auch der Bau des mittlerweile abgerissenen 

Hallenbad von 1964 und das Gebäude des Klinikums gehen auf ihn zurück. Einen wirtschaft‐ 

lichen Aufschwung erlebte Kaiserslautern auch 1966 als die Adam‐Opel AG sich im frisch 

ausgewiesenen Gewerbegebiet im Westen der Stadt niederließ. 2200 Arbeiter fanden einen 

Arbeitsplatz. Als städtebaulichen Höhepunkt kann der Rathausneubau des Architekten Ro‐ 

land Ostertag von 1968 gelten, der bis heute das Zentrum und das Stadtbild von Kaiserslau‐ 

tern dominiert. 1967 überstieg die Bevölkerung der Stadt erstmals die Grenze von 100000 

Einwohnern durch die Eingemeindung der Orte Erfenbach, Siegelbach, Mölschbach, Erlen‐ 

bach, Morlautern und Hohenecken. Als Ergebnis einer Verwaltungsvereinfachung stieg die 

Einwohnerzahl von vorher 85422 auf 103012. Dies hatte für die Stadt den nicht unerhebli‐ 

chen Nebeneffekt, dass sie anschließend als Oberzentrum in der „Konzeption der Zentralen 

Orte“ des Raumordnungsgesetzes galt. 

Einen weiteren Meilenstein bei der Entwicklung der Infrastruktur waren die Gründungen der 

Fachhochschule 1971 und der Hochschule 1970. Im Folgenden kam es in den 1970er‐Jahren 

zum Bau des Uni‐Wohngebietes im Süden der Stadt. Mit Platz für 8500 neue Einwohner war 

dies die letzte große Stadterweiterung bis heute. Danach konzentrierte man sich auf Sanie‐ 

rungen und Instandhaltung. Auch die Bevölkerung stagnierte und lag 1994 bei 102384. 1992 

nach der Wiedervereinigung Deutschlands kam es zum Abzug der Franzosen, welche in der 

Holtzendorff‐Kaserne an der Mainzer‐Straße stationiert waren. 1997 erwarb eine Projekt‐ 

entwicklungsgesellschaft im Sinne eines PPP (puplic‐private‐partnership) das ehemalige Mili‐ 

tärgelände und siedelte nach einer grundlegenden Sanierung und Neuerschließung zahlrei‐ 

che Unternehmen an. 

1995 wurde das alte Pfalztheater am Fackelrondell abgerissen und durch einen großen Neu‐ 

bau neben dem Rathaus ersetzt. Ein weiterer kultureller Höhepunkt war die Ausrichtung der 

Landesgartenschau im Jahr 2000, bei dem es im Bereich der Kammgarn, des alten Schlacht‐ 

hofs und des angrenzenden Steinbruchgeländes zu einer grundlegenden Umstrukturierung 

kam. Das Gartenschaugelände wird bis heute als städtischer Freiraum gut von der Bevölke‐ 

rung angenommen. 

2006 schaffte es Kaiserslautern trotz starker Konkurrenz, sich als Austragungsort der Fuß‐ 

ballweltmeisterschaft zu etablieren. Die Stadt stand für kurze Zeit im Blickpunkt der Weltöf‐ 

fentlichkeit.

Abbildung 45: Luftbild des Stadtkerns von Kaiserslauten 2008 (Stadt Kaiserslauten,2008) 


Nach der ausführlichen Chronologie ist die Bedeutung und die heute vorhandene städtebau‐ 

liche Struktur wesentlich besser zu erfassen und zeitlich einzuordnen. Um jedoch einen opti‐ 

schen Eindruck von der städtebaulichen Situation zu bekommen, wurde ein 3D‐Stadtmodell 

erstellt, welches dreidimensionale Momentaufnahmen des Stadtkerns zu drei relevanten 

Zeitpunkten beinhaltet und objektorientierte Zusatzinformationen bietet. Die Zeiten, die 

gewählt wurden, sind erstens die Kaiserpfalz von 1160, zweitens die städtebauliche Situation 

nach der Gründerzeit und zum Zeitpunkt der Erstellung des sog. Bindewaldplans 1889, und 

drittens, der Status quo des Stadtkerns im Jahr 2009. Der Grund für diese Auswahl liegt dar‐ 

in, das die Kaiserpfalz den Grundstein für die Entwicklung der Stadt gelegt hat, das der Bin‐ 

dewaldplan die heutige Stadtstruktur immer noch prägt und das ein Gegenwartsmodell 

unabdingbar ist, da Vergleiche mit der heutigen städtebaulichen Situation sonst nicht an‐ 

schaulich möglich wären. Allerdings ist die Rolle der ausgewählten Zeiten für diese Arbeit 

nicht elementar, da diese Arbeit den Erstellungsprozess von digitalen historischen 3D‐ 

Stadtmodellen nur beispielhaft untersucht. 

Während die Daten zu Stadtgeschichte von den Geschichtswissenschaftlern teilweise sehr 

gut dokumentiert sind, ist die Geschichte der städtebaulichen Struktur der Stadt sehr lü‐ 

ckenhaft. Lediglich einige Stiche und Zeichnungen, sowie schriftliche Beschreibungen geben 

Aufschluss über Lage und Aussehen der historischen Baukörper. 

Nachfolgend soll die Ausgangslage bezüglich der Datengrundlage zur Erstellung des Stadt‐ 

modells beleuchtet werden. Eine besondere Schwierigkeit kommt durch die Erhebung von 

historischen Daten hinzu.


4.4 Datengrundlagen allgemein 

Für die Erstellung von 3D‐Stadtmodellen der Gegenwart werden überwiegend Daten aus der 

Stadtvermessung sowie der Stadtplanungsämter als Grundlage herangezogen. Bevorzugt 

werden dabei digitale Daten verwendet, da eine Digitalisierung analoger Daten erstens zeit‐ 

lich nicht rentabel ist, und zweitens birgt eine Digitalisierung von analogen Vermessungsda‐ 

ten außerhalb der Vermessungswissenschaft und seiner Standards die Gefahr von Digitalisie‐ 

rungsfehlern. ZEILE [2004] beschreibt ausführlich die vorhandenen Datenquellen zur Erstel‐ 

lung von 3D‐Stadtmodellen. Vor allem die digitalen Nachfolger der Katasterkarte stellen eine 

wichtige Grundlage zur Erstellung von Gebäudegeometrien dar. In einigen Fällen besitzen die 

digitalen Katasterdaten auch eine Höhen‐Koordinate (Z‐Wert). Oft sind aber nur Daten be‐ 

züglich der Lage vorhanden. Weiterhin sind Straßenvermessungspunkte, bestehende DGM 

(Digitale Geländemodelle) und Luftbilder elementare Basisdaten. Letztere sind allerdings vor 

allem bei kleineren Kommunen nicht in Besitz der lokalen Verwaltung, sondern wurden von 

den zuständigen Landesämtern erstellt und stehen dort zum Verkauf. Die Preise für Luftbild‐ 

daten sind in der Regel sehr hoch und vergrößern das finanzielle Volumen eines Projekts 

beträchtlich. Falls Luftbildaufnahmen in der Fläche aufgenommen worden sind, besteht auch 

die Möglichkeit, durch eine stereoskopische Auswertung von überlappenden Luftbildern sog. 

Dachlandschaften einer Stadt zu erstellen [vgl. ZEILE 2004]. Daraus können dann Dachfor‐ 

men sowie First‐ und Traufhöhen abgeleitet werden. Parallel steht der manuelle Weg zur 

Messung von Gebäudehöhen zur Wahl. Dabei kommt entweder die traditionelle Messung 

per Theodolit oder einfach die Aufnahme der Traufhöhen per Laserentfernungsmesser in 

Frage. 

Die momentan genaueste aber auch teuerste Aufnahme der Gebäude einer Stadt ist die Ers‐ 

tellung der Geometrien per Laserscan. Dabei unterscheidet man zwischen terrestrischen 

(bodengebundenen) und „airborne“ (luftgestützten) Laserscans per Flugzeug. Der Einsatz 

von Laserscans ist in der Fachwelt nicht unumstritten, zum einen aufgrund des hohen Prei‐ 

ses, zum andern wegen der unnötigen Masse an Daten, die dabei produziert wird [vgl. ZEILE, 

2004]. 

Zur Erstellung der Gebäudegeometrien sind in der Regel für ein LOD‐3‐Modell nur die First‐ 

und die Traufhöhe, welche meist über 6 Punkte (2mal First und 4mal Traufe) beschrieben 

werden können, und die Bodenpunkte aus dem Kataster notwendig. Ein durchschnittlicher 

terrestrischer Laserscanner mit einer Auflösung von etwa 5cm produziert etwa für ein Ge‐ 

bäude von 10 mal 10 Metern ohne Weiteres eine Punktwolke mit über 1 Million Einzelpunk‐ 

ten. Die dabei produzierte Datenmenge ist enorm und erfordert einen langwierigen Nach‐ 

bearbeitungsprozess (Fachwort: „Post Processing“) und teure Software. 

Der Einsatz von Laserscans zur Erstellung von 3D‐Stadtmodellen ist also wohl zu überlegen 

[vgl. ZEILE, 2004]. Ein Einsatz bei Modellen im Kontext der Denkmalpflege oder kleinräumi‐ 

gen Rekonstruktionen von historischer Bausubstanz, wo die Detaillierung des 3D‐Modells 

von Bedeutung ist, ist durchaus sinnvoll. Trotzdem sollte bei der anschließenden Visualisie‐ 

rung über den Einsatz dynamischer LOD nachgedacht werden, da selbst die moderne Hard‐ 

ware Grenzen der Masse der dargestellten Inhalte kennt.

4.5 Datengrundlagen Kaiserslautern 


Nachfolgend soll die Situation der Datengrundlage für das 3D‐Stadtmodell des Stadtkerns 

von Kaiserslautern beschrieben werden. Zunächst soll aber erst der Untersuchungsraum 

abgegrenzt werden. 

Abgrenzung des Untersuchungsraums 

Die ersten Schritte vor der Analyse der vorhandenen Datengrundlagen war die Abgrenzung 

des Untersuchungsraums. Dazu war es erforderlich, die Stadtgeschichte sowie Kartenmate‐ 

rial aus verschiedenen Zeiten zu studieren. Bei einer Abgrenzung nach aktuellen Karten wäre 

ein Ausschluss von wichtigen lokalen Objekten nicht auszuschließen. 

Abbildung 46: Ausschnitt Bindewaldplan von 1889 (Stadt Kaiserslautern, 2008, und eigene Retusche) 

Der Untersuchungsraum wurde auf folgendes Gebiet festgelegt: Im Norden wurde die Lud‐ 

wigstraße mit angrenzender Bebauung gewählt, im Westen die Maxstraße und Teile der 

Burgstraße, im Süden wurde der Schillerplatz sowie die Fruchthallstraße und im Osten die 

Martin‐Lutherstraße als Begrenzung bestimmt. Das abzubildende Gebiet umfasst eine Fläche 

von etwa 18 ha und 77 Gebäuden (Gegenwartswert). 

Nach der Festlegung des Untersuchungsraums wurde mit der Bestandaufnahme der vorhan‐ 

denen Daten begonnen. Nach umfassender Literatur‐ und Internetrecherche sowie persönli‐ 

chen Gesprächen mit Mitarbeitern des Vermessungsamtes, des Stadtplanungsamtes, des 

Stadtarchivs und Vermessungslehrstühlen der lokalen Universität konnten die nachfolgend 

aufgelisteten Datengrundlagen festgestellt werden.


Abbildung 47: Untersuchungsraum für die Bestandsaufnahme (Stadt Kaiserslautern, 2008, und eigene Retusche)

Ergebnisse der Bestandsaufnahme für das Gegenwartsmodell: 


1. ein digitales Kataster 

Inhalte sind die Lage der Gebäude, Lage der Straßen, Lage der Gehwege, Grünflächen, ein‐ 

zelne Vegetationselemente. Diese sind nur in der Lage festgehalten. Die vermessenen Gulli‐ 

deckel, Straßenkanten sind neben anderen Einzelobjekten in Lage und Höhe gespeichert. 

Abbildung 48: Screenshot des digitalen Katasters von Kaiserslautern in AutoCAD (eigene Darstellung) 

2. ein Geographisches Informationssystem (GIS) 

Die Stadt Kaiserslautern verfügt über ein modernes Geografisches Informationssystem mit 

3D‐Gebäudedaten für den Planungsbereich. Nach der Kontaktaufnahme mit der Vermes‐ 

sungsabteilung der Stadt wurden die entsprechenden Daten aus dem GIS‐System exportiert. 

Die erhaltenen Daten wurden zur näheren Untersuchung anschließend in das Programm 3D‐ 

Studio Max importiert. Die vorhandenen 3D‐Kubaturen der Gebäude waren in der Lage und 

Höhe sehr genau, hatten aber ein LOD von etwa 1 und waren stark abstrahiert. 

Abbildung 49: GIS‐Daten in 3D Studio Max (eigene Darstellung)


3. ein vorhandenes 3D‐Stadtmodell des Planungsgebiets 

2005 waren von der Stadt Anstrengungen gemacht worden, ein eigenes 3D‐Stadtmodell in 

Eigenarbeit zu erstellen. Dabei griff man auf ein externes Ingenieur‐Büro zurück, welches der 

Stadt mit Schulungen das notwendige Know‐how verschaffte. Das entstandene Modell lag 

bezüglich des Detaillierungsgrades bei LOD 3 (also mit Texturen) und hatte ein texturiertes 

DGM. Die Detaillierung der Gebäudekubaturen war relativ hoch. Die Auflösung und die Qua‐ 

lität der Gebäude‐ und Geländetexturen hingegen waren sehr schlecht. Zudem waren nicht 

alle Gebäude texturiert. Das DGM hatte ein Raster von 25m. 

Abbildung 50: altes 3D‐Stadtmodell von Kaiserslautern in 3D Studio Max (eigene Darstellung) 

4. ein digitales DGM 

Die Stadt Kaiserslautern verfügt seit 2008 über ein digitales Geländemodell sowie ein digita‐ 

les Oberflächenmodell (kurz DOM). Beide wurden per Laserscanüberfliegung für das ganze 

Stadtgebiet erstellt. Die Auflösung des DGM und des DOM liegt bei 1m. 

Abbildung 51: Screenshot des DGM in 3D Studio Max (eigene Darstellung)


5. Luftbilddaten 

Im Zuge der Laserscanüberfliegung wurden auch hochauflösende Luftbilder des gesamten 

Stadtgebiets erstellt. Die Auflösung liegt auch hier bei 1m/Pixel. Diese ersetzten bestehende 

Luftbilddaten mit einer Auflösung von etwa 5m. 

Abbildung 52: aktuelles Luftbild der Stadt Kaiserslautern (Stadt Kaiserslautern, 2008, und eigene Retusche)


Ergebnisse der Bestandsaufnahme für die historischen Modelle: 

1. analoge Pläne aus den Jahren 1950, 1921, 1890, 1889, 1823 

Die Pläne liegen in analoger und teilweise in digitaler Form vor. Die digitalen Versionen wur‐ 

den eingescannt und besitzen eine Auflösung von etwa 2‐4 Metern/Pixel (errechneter Wert). 

Die Pläne sind allerdings selten Vermessungspläne sondern Stadtpläne mit einem hohen 

Abstraktionsgrad. Das bedeutet, nur auf wenigen Plänen sind einzelne Gebäude erkennbar 

(z. B. Bindewaldplan 1889). 

Abbildung 53: Plan von Kaiserslautern aus dem Jahr 1823 (Etienneplan), (Stadt Kaiserslautern, 2008) 

2. digitalisierte Fotografien aus der Zeit ab etwa 1890 

Das Stadtarchiv verfügt über ein eigenes Informationssystem, mit dem alte Fotografien zu 

vielen Gebäuden, die in der Stadtgeschichte existierten, angezeigt werden können. Zusätz‐ 

lich befinden sich in diesem System eingescannte alte Ansichtskarten der Stadt. 

Abbildung 54: historisches Foto des Fackelrondells (1909), (Stadt Kaiserslautern, 2008)


3. historische Gebäudepläne 

Zu einigen Gebäuden gibt es analoge Gebäudepläne. Diese sind aber nur teilweise archiva‐ 

risch erfasst und sortiert. 

4. alte Zeichnungen, Skizzen und Stiche 

Das Stadtarchiv, das Amt für Denkmalschutz sowie verschiedene Museen verfügen über Ori‐ 

ginale und Kopien alter Zeichnungen, Skizzen und Stiche. Diese liegen in unterschiedlicher 

Qualität vor. Vor allem Stücke mit einer Datierung von vor 1800 sind oft ohne korrekte Pers‐ 

pektive. 

Abbildung 55: Ansicht des Casimirschlosses und der Kaiserpfalz von 1740 (Friedel, 1995) 

5. schriftliche Erzählungen und Berichte über die Stadt 

Schriftliche Überlieferungen, Erzählungen und Berichte sind teilweise bis ins Jahr 830 n.Chr. 

verfügbar. 

6. analoge Modelle des Casimirschlosses und Alt Kaiserslautern 

Wie schon im Kap. 3.1 erwähnt, gibt es im Theodor‐Zink‐Museum Kaiserslautern mehrere 

Modelle, die Rekonstruktionsversuche des Casimirschlosses und der Gesamtstadt darstellen. 

Bewertung der Daten der Gegenwart 

Die gefundenen Daten für das Jahr 2009 waren wie erwartet sehr zahlreich. Nach genauerer 

Sichtung stellten sich aber Probleme ein. Das Kataster war zwar genau aber verwaltungsbe‐ 

dingt mit einer Unmenge an verschiedenen Layern (Ebenen) im CAD‐System (Autocad) abge‐ 

legt. Weiterhin waren 2D‐Daten mit 3D‐Daten auf identischen Layern gemischt. Für eine 

Verwendung musste ein separierter, projektbezogen bereinigter Katasterplan erstellt wer‐ 

den. 

Die GIS‐Daten, welche von der Stadt zur Verfügung gestellt wurden, waren aus dem vorhan‐ 

denen GIS‐System heraus erstellt worden und sind lediglich zu Verortung und Höhenbe‐ 

stimmung eines eigenen Modells zu gebrauchen. Für die Erstellung eines 3D‐Stadtmodells im 

LOD 1 sind sie allerdings hervorragend. 

Das bestehende 3D‐Stadtmodell besitzt einen für LOD 3 ausreichenden Detaillierungsgrad in 

der Geometrie und einige gute Texturen. Insgesamt ist die Qualität aber sehr heterogen und


bedarf einer grundlegenden Überarbeitung sowie einer Neutexturierung. Da die vorhande‐ 

nen Texturen von schlechter Qualität sind, müsste flächendeckend neues Texturmaterial 

erhoben werden. Der Aufwand zur Generierung von hochwertigen Texturen macht einen 

Großteil des Arbeitsaufwandes bei der Erstellung eines detaillierten 3D‐Stadtmodells aus, ist 

aber maßgebend für die spätere Qualität. 

Die vorhandenen DGM‐ und Luftbilddaten hingegen sind von sehr guter Qualität. Sie eignen 

sich hervorragend für die Erstellung von 3D‐Stadtmodellen bis LOD 3. Weiterhin bieten sie 

eine gute Grundlage, um sich bei der Erstellung der Gebäudegeometrien einen Überblick 

über die lokale Situation zu verschaffen. Zusammenfassend sind die Daten gut geeignet für 

die Erstellung eines Stadtmodells im LOD 3. 

Bewertung der historischen Daten 

Das historische Kartenmaterial ist sehr heterogen in seiner Qualität und Genauigkeit. Die 

meisten Pläne reichen lediglich für ein LOD‐0 oder LOD‐1 Modell, welches einen mehr oder 

weniger genauen Überblick über die jeweilige Stadtstruktur gibt. Ausnahme bildet ein sehr 

hochauflösend eingescannter Plan von 1889 (der sog. Bindewaldplan), welcher auch Grund‐ 

lage für ein Modell mit LOD 2 oder LOD 3 sein könnte. Die letztendliche Genauigkeit eines 

solchen Modells wird aber von der im Plan vorhandenen Strichstärke bestimmt. 

Die Pläne stellen weiterhin eine potenzielle Basis für die Erstellung eines historischen DGM 

dar, sofern sie schon über Geländeinformationen wie etwa Höhenlinien verfügen. 

Die digitalisierten Fotografien und Stadtansichten sind eine gute Informationsquelle für die 

Herstellung von Gebäudegeometrien. Problematisch wird aber die Erhebung dieses Daten‐ 

typs für die flächendeckende Anfertigung von Einzelgebäuden. 

Die vorhandenen historischen Gebäudepläne stellen eine hervorragende Basis für die Erstel‐ 

lung von Gebäudegeometrien dar, sind aber wie die Fotografien nicht flächendeckend ver‐ 

fügbar. Weiterhin wäre eine Erstellung der Gebäudegeometrien über diesen Datentyp nicht 

zeitnah realisierbar, und der Arbeitsaufwand wäre ernorm sowie wirtschaftlich nicht durch‐ 

führbar. Vor allem die Personalkosten würden das Kosten‐/Nutzenverhältnis von histori‐ 

schen Modellen aus dem Gleichgewicht bringen. 

Noch schwieriger ist die Bewertung der alten Stiche und Zeichnungen. Ihre Datierung reicht 

weit in die Zeit bis zur Stadtgründung zurück. Durch die damals vorherrschenden künstleri‐ 

schen Fähigkeiten bedingt, ist die fehlende oder falsche Perspektive für die Nutzung als Da‐ 

tengrundlage ein erhebliches Hindernis. 

Ähnlich gestaltet sich die Bewertung der historischen Schriften und Texte. Durch die Vielzahl 

an nicht mehr existenten Sprachen und Schriften ist eine Verwendung als Datengrundlage 

für Laien nicht gegeben. Weiterhin sind die Schriften in ihrer Detaillierung sehr ungenau (z. 

B. die Verse des Biografen von Kaiser Barbarossa, Rahewin, über den Bau der Kaiserpfalz von 

1160). 

Zusammenfassend ist bezüglich der historischen Daten im Sinne einer Bewertung festzustel‐ 

len, dass die Verwendung der Daten alleine durch den Planer, der in diesem Fall ein Laie ist, 

nicht möglich ist. Lediglich die Pläne und Fotografien stellen eine kleine Datenbasis für die 

Erstellung von 3D‐Stadtmodellen mit niedrigem LOD dar. Für ein Modell mit höherem LOD


ist zwingend die Zusammenarbeit mit Experten der Denkmalpflege, der Archäologie, der 

anthropologischen Archäologie und anderen Geschichtswissenschaften notwendig. Der 

Grund dafür: die Eigenschaft der Daten, die nur eine Momentaufnahme der Geschichte sind 

und zu stark abstrahiert sind, um ihnen direkt Informationen entnehmen zu können. Für eine 

realistische Rekonstruktion der Geschichte sowie seiner städtebaulichen Ausformung ist es 

notwendig, möglichst alle Gegebenheiten eines kompletten Zeitraums in der Geschichte ein‐ 

gehend zu studieren. Daher kann eine einzelne Wissenschaft einen Zeitpunkt in der Ge‐ 

schichte nicht autark wissenschaftlich und historisch korrekt erfassen. Weiterhin ist festzus‐ 

tellen, dass mit zunehmendem zeitlichem Abstand zur Gegenwart die Datendichte exponen‐ 

tiell abnimmt und der Zeit und Arbeitsaufwand zur Erhebung parallel dazu exponentiell zu‐ 

nimmt. Für die Erstellung von 3D‐Stadtmodellen lässt sich also ableiten, dass der Aufwand 

für die Erstellung von historischen Modellen abhängig vom abzubildenden Zeitpunkt und der 

gewünschten oder notwendigen historischen Genauigkeit ist. Gleichzeitig ist schon für ein 

Mindestmaß an historischer Genauigkeit die Zusammenarbeit mit den historischen Fachrich‐ 

tungen erforderlich. 

An dieser Stelle wäre zudem die Einführung eines sog. historischen LOD sinnvoll, um eine 

wissenschaftlich korrekte Diskussion im Kontext der digitalen historischen Echtzeitmodelle 

zu gewährleisten. 

Definition: Historischer LOD (HLOD) 

Der historische LOD stellt die Genauigkeit in Bezug auf die historische Abstraktion eines digi‐ 

talen historischen Modells dar. Ein Modell mit niedrigem HLOD wäre ein Modell, das zwar 

vom LOD her sehr hoch sein kann, aber jeder historischen Korrektheit entbehrt. Ein Modell 

mit einem hohen HLOD besitzt fundierte historische Daten und stellt eine genaue und wahr‐ 

heitsgemäße Rekonstruktion des Originals aus der Vergangenheit dar. 

Abbildung 56: Graph HLOD (eigene Darstellung)


4.6 Zwischenfazit und Festlegung des LOD 

Nach der Analyse der vorhandenen Daten und deren Bewertung ist als Ergebnis festzuhal‐ 

ten, dass die Daten zwar für die Erstellung eines 3D‐Stadtmodells der Gegenwart ausreichen, 

ein historisches Modell aber nicht im Rahmen einer Diplomarbeit realisierbar ist oder nur in 

einem sehr kleinen räumlichen Umfang bzw. sehr geringer historischer Genauigkeit (HLOD). 

Um jedoch ein Beispiel für die Machbarkeit und die mögliche Qualität eines digitalen histori‐ 

schen Modells zu geben, wird der Modellerstellungsprozess nicht unterbrochen. Stattdessen 

kann im Fall des 3D‐Stadtmodells Kaiserslautern vom Autor auf bereits vorgefertigte histori‐ 

sche 3D‐Daten zurückgegriffen werden. 

Hintergrund der bestehenden historischen 3D‐Daten: 

Die Stadt Kaiserslautern beauftragte 2006 ein Unternehmen, das sich auf die Visualisierung 

historischer Bauten spezialisiert hat, mit der einer Rekonstruktion der Kaiserpfalz von 1160 

n.Chr. Der Auftrag war die Erstellung einer DVD mit einem Animationsfilm über das Ausse‐ 

hen der Kaiserpfalz, kombiniert mit Echtfilmszenen, in denen die Schausteller das Leben und 

das Aussehen der damaligen Bevölkerung nachahmten. Dieser „Dokumentarfilm“ über die 

Kaiserpfalz ist seit 2006 in der Tourist‐Information Kaiserslautern an Interessierte und Tou‐ 

risten verkauft worden. 

Bei der Bestandsaufnahme wurde der Autor auf dieses Video aufmerksam und stellte fest, 

dass es sich bei den Sequenzen mit Animationsfilm um 3D‐Daten handelt, die in einem 3D‐ 

Modellierungsprogramm erstellt wurden. Nach der Kontaktaufnahme mit dem Auftraggeber 

der DVD, dem Förderkreis zur Erhaltung Kaiserpfalz e.V. unter Leitung von Frau Ingeborg 

Schüler, Mitglied des Kaiserslauterer Stadtrats, konnte eine Genehmigung zur Nutzung der 

3D‐Daten vonseiten der Stadt erreicht werden. Da aber nur die Nutzungsrechte bezüglich 

der DVD und des Animationsfilms bei der Stadt lagen, mussten noch die 3D‐Daten selber und 

die Genehmigung für deren Nutzung beim Hersteller der DVD eingeholt werden. Nach meh‐ 

reren Telefonaten war auch dieses Problem gelöst, und die Firma ReUnion‐Media und Ge‐ 

schäftsführung von Herrn Menno Mennenga stellte die 3D‐Daten für das 3D‐Stadtmodell der 

Stadt Kaiserslautern zur Verfügung. 

Die 3D‐Daten waren für die Nutzung in einem Renderprozess, zur Erstellung eines Animati‐ 

onsfilms konzipiert und für die Verwendung in einem Echtzeitmodell extrem überdetailliert. 

Weiterhin gab es softwaretechnische Hürden, die überwunden werden mussten, um die 

Daten am PC überhaupt sichtbar zu machen.

Abbildung 57: Screenshot mit den Rohdaten der Kaiserpfalz in 3D Studio Max (eigene Darstellung) 


Abbildung 58: Screenshot mit einer Detailaufnahme der Rohdaten der Kaiserpfalz (eigene Darstellung)


Nach der Sicherstellung von historischen 3D‐Daten mit einem hohen HLOD und der Auswer‐ 

tung der anderen Datengrundlagen rückte die Festlegung eines angestrebten LOD für das 

3D‐Stadtmodell in den Mittelpunkt. Der angestrebte LOD soll sich für den Praxisteil dieser 

Arbeit zwischen LOD 3 und LOD 4 bewegen. Für die Jahre 1160 und 2009 reichen die vor‐ 

handenen Daten für ein solches Modell aus bzw. können in Eigenarbeit ohne hohen Auf‐ 

wand erhoben werden. 

Für das Jahr 1889 wurde ein 3D‐Stadtmodell im LOD 1 angestrebt, da eine Auswertung von 

historischen Fotografien den zeitlichen Rahmen der Arbeit sprengen würde. 

Der hohe LOD der beiden anderen Zeiten ergibt sich aus folgenden Gründen: 

1. Die Zielsetzung dreht sich um ein 3D‐Stadtmodell nach dem momentan möglichen Stand 

der Technik, in der Folge ein hochdetailliertes texturiertes Modell. 

2. Die Ausgangsdaten lassen ein solches Modell zu. 

3. Um eine Art ästhetische Einheit zwischen den Modellen 1160 und 2009 zu erzielen, ist ein 

Modell von 2009 im LOD 3+ notwendig; gleichzeitig ist ein ähnlicher LOD notwendig, um 

eventuelle Vergleiche anstellen zu können. 

4. Um eine Basis für zukünftige Bestrebungen der Stadt im Kontext 3D‐Stadtmodelle zu le‐ 

gen, ist ein hoher LOD richtungsweisend. 

5. Um ein Modell herzustellen, das auch als Touristeninformationssystem genutzt werden 

kann, benötigt es einen relativ hohen Wiedererkennungswert, der sich in der Folge in einem 

hohen LOD niederschlägt [vgl. ZEILE, 2004]. 

4.7 Erstellung des 3D‐Stadtmodells 

Im nachfolgenden Teil soll die Erstellung des 3D‐Stadtmodells in dokumentarischer Weise 

erfolgen. Dabei werden u.a. die Vorgehensweise, neue innovative Techniken und Anforde‐ 

rungen bei der Modellerstellung beschrieben. Die verwendeten Anwendungen und Soft‐ 

wareprodukte werden nicht detailliert in ihrer Funktionsweise beschrieben, sondern nur ihre 

allgemeine Aufgabe im Erstellungsprozess. 

Grundlegend lässt sich der Modellerstellungsprozess in 10 Teilschritte unterteilen: 

1. Erstellung der Geometrie 

2. Erstellung der Texturen 

3. Organisation der Geometrie 

4. Texturierung der Geometrie 

5. Erstellung der Vegetation 

6. Lightmapping 

7. Export und Organisation in Quest3D

8. Optimierung der Daten für ein Echtzeitmodell 

9. Erstellung der Anwendungslogik 

10. Integration der Metadaten 

11. Publizierung als Viewer 


Schritt 1: Die Erstellung der Geometrien 

Die Erstellung der Geometrien erfolgt auf Basis mehrerer Datengrundlagen und Techniken. 

In der Regel werden hierzu nur die Gebäudegrenzen aus der Katasterkarte als Fläche auf der 

Höhenachse extrudiert. Anschließend werden aus entsprechenden Daten, wie der stereos‐ 

kopischen Auswertung der Dachlandschaften die Dachformen erstellt. WETTELS [2004] ver‐ 

wendete dazu schon einen halb automatisierten Erstellungsprozess, bei dem DGM‐Daten, 

Gebäudegrenzen aus dem Kataster und Dachformen automatisiert miteinander verschnitten 

wurden. Die dabei generierten Gebäudekubaturen sind zwar sehr arm an Polygonen (Poly‐ 

gon = kleinste geometrische Einheit bei der Modellierung von 3D‐Geometrien, meist meint 

Polygon nur ein Dreieck), was eine spätere Effizienz bezüglich der Performance bringt, aber 

gleichzeitig auch arm an Details ist. Deren Ausformung ist aber, bedingt durch die Festlegung 

auf einen LOD 3+, notwendig. 

Abbildung 59: Anwendung Architectural Space von Pierre Wettels zur automatischen Erzeugung von Geometrien 

(Wettels, 2004) 

Für die Erstellung der Geometrien wurde ein kombiniertes Erstellungsverfahren aus Geoda‐ 

ten und Bilddaten verwendet. Das hierfür eingesetzte Programm war „Sketchup 7“ der be‐


kannten Firma Google. Die Gründe hierfür waren die benutzerfreundliche Bedienung, die 

anwendungsinterne Intelligenz bezüglich der Fangfunktionen (bekannt aus CAD‐ 

Programmen) und die Möglichkeit, Bilder als Quelle von Geometriedaten zu verwenden. Die 

Funktion „Photo Match“ ermöglicht es dem Anwender, Gebäude auf Bildern in ein Flucht‐ 

punktkoordinatensystem einzupassen und anschließend maßstäblich entlang der Gebäude‐ 

kanten auf dem Bild Geometrien zu erzeugen. 

Abbildung 60: Photomatch in Sketchup 7 (eigene Darstellung) 

Die Vorgehensweise war folgende: Zuerst wurden Fotos des zu modellierenden Gebäudes 

erstellt und einer Objektivkorrektur unterzogen. Wichtig bei der Aufnahme war die Perspek‐ 

tive, wobei immer Gebäudekanten fotografiert wurden. Dadurch waren immer mindestens 

zwei Gebäudeachsen sichtbar, die zur Referenzierung in „Photo Match“ verwendet werden 

konnten. Parallel wurden zur Erstellung die im Kataster festgelegten Gebäudemaße abgegrif‐ 

fen, um eine Verortung des Gebäudes im Stadtkontext zu gewährleisten. Einer weiterer 

Grund hierfür waren die Grenzen der Generierung von Geometrien aus Bilddaten. Da die 

Genauigkeit der erstellten Geometrien mit zunehmender Entfernung zum Bildvordergrund 

abnimmt, mussten die absoluten Gebäudemaße aus dem Kataster entnommen werden. Um 

die Genauigkeit dieses Prozesses zu erhöhen, wurden häufig zwei unterschiedliche Perspek‐ 

tiven für die Erstellung einer Gebäudefassade gewählt, um eine Art Korrektur von Bildfehlern 

zu minimieren.


Die Genauigkeit, welche dabei gegenüber der Realität (Ergebnis errechnet durch eigene 

Testmessungen) erreicht wurde, liegt im Bereich von 5‐10cm maximaler Abweichung in der 

Lage und 20cm maximaler Abweichung in der Höhe. Wichtig in diesem Zusammenhang ist, 

dass diese Abweichungen keineswegs nur das Ergebnis der bildgestützten Geometrieerstel‐ 

lung waren, sondern, dass es sich um Fehler im digitalen Kataster handelte. Gerade die Ers‐ 

tellung von Geometrien über das Bildverfahren (per „Photo Match“) brachte häufig die ge‐ 

naueren Ergebnisse, welche teilweise bei einer min. Abweichung von weniger als einem Zen‐ 

timeter lagen. Zu den Problemen in diesem Zusammenhang wird aber noch im Kapitel 5.1 

eingegangen. 

Eine weitere Neuerung bei der Erstellung der Gebäudegeometrien war die Ausrichtung der 

Geometrieerstellung auf eine teilgenerische Texturierung des Modells. Das heißt, die Geo‐ 

metrien wurden so gegeneinander abgegrenzt, wie später die Geometrien mit Texturen ver‐ 

sehen werden. Zum Beispiel wurden die Fenster geometrisch separiert konstruiert, um spä‐ 

ter eine Fenstertextur hinein zu texturieren (vgl. Abbildung 66). Die Vorteile dieser Vorge‐ 

hensweise werden aber noch unter dem Punkt Texturierung der Geometrien erörtert. 

Die Erstellung der Geländegeometrien war eine weitere große Hürde. Das vorhandene DGM 

besitzt zwar eine Auflösung von 1m, ist aber für den direkten Einsatz als Geländemodell für 

das 3D‐Stadtmodell Kaiserslautern zu ungenau. Der Grund dafür liegt hauptsächlich in dem 

schlechten Wiedererkennungswert bei einem Vergleich mit der Realität, zumal die Topogra‐ 

fie des Plangebiets von vielen großen Treppenanlagen geprägt ist. Diese sind auch in einem 

DGM mit 1m‐Raster nicht wiederzuerkennen. 

Abbildung 61: Vergleich zwischen Realität, DGM, und finalem Modell (eigene Darstellung) 

Aus diesem Grund wurde für das gesamte Plangebiet ein eigenes detailliertes DGM gefertigt, 

welches die Bordsteinkanten, Treppenstufen und sonstigen Topografieversprünge aufweist. 

Dazu wurde das bestehende DGM mit den Straßengrenzlinien aus dem Kataster in einer sog. 

Booleschen Operation verschnitten und anschließend generalisiert. Die Generalisierung er‐ 

folgte sehr akribisch, um ein Maximum an Realitätsnähe beizubehalten. Dabei wurden Flä‐ 

chen mit ähnlicher Steigung zu einer einzelnen coplanaren Fläche (siehe Glossar) generali‐ 

siert. Die maximale Abweichung des Modell‐DGM vom DGM der airborne Laserüberfliegung 

liegt bei etwa 80cm (eigene CAD‐Messung). Zusätzlich wurden Bereiche, mit sehr detaillier‐ 

ter Topografie handvermessen und separat konstruiert. In diesen Teilen liegt die Abwei‐ 

chung von der Realität bei unter 5cm.


Der Aufwand zur Erstellung der 3D‐Geometrien in Zahlen belief sich auf etwa 7 Wochen á 5‐ 

6 Arbeitstage á 6 Stunden Arbeit pro Tag: macht etwa 231 Stunden zur Erstellung der komp‐ 

letten Geometrie des Modells von 2009. Einen anderen Einblick geben die selbst geführten 

Statistiken bei der Bildschirmarbeit (durchgeführt mit dem Programm „Mousemeter“, wel‐ 

ches die Klicks und den realen Mausweg in Meter dokumentieren) in gerundeten Werten: 

510.000 Mausklicks und 61 km Mausweg. Das entspricht etwa 36 Mausklicks und 4,4 Meter 

Mausweg pro Minute. 

Abbildung 62: Anwendung Mousemeter zur Analyse der Mausaktivität (eigene Darstellung) 

Die Geometrien des Modells von 1160 (Kaiserpfalz) wurden wie schon erwähnt vom Herstel‐ 

ler ReUnion‐Media zur Verwendung in dieser Arbeit zur Verfügung gestellt. Da die Geomet‐ 

rien für eine Verwendung im Renderprozess erstellt wurden, besitzen sie überdurchschnittli‐ 

che viele Polygone. Das macht sie zum einen sehr detailliert, zum anderen aber auch schwer 

handhabbar in einer Echtzeitanwendung. In der Folge mussten alle Modelle auf eine Poly‐ 

gonreduzierung hin nochmals aufwendig überarbeitet werden. 

Die Geometrien des Modells von 1889 wurden durch eine Digitalisierung des Bindewaldplans 

von 1889 erzeugt. Dazu wurde die sehr hochauflösende (5900 mal 3300 Pixel) Karte in Goog‐ 

le Sketchup eingelesen und auf ihr die Gebäudegrenzen nachgezeichnet. Die Information 

über Gebäudehöhen wurde teilweise aus Fotografien und teilweise über noch erhaltene 

Gebäude (z. B. das Sozialamt oder die Fruchthalle) oder Interpretation des Plans (z. B. frei 

stehendes Einzelwohnhaus = 3 ½ Stockwerke á 3m Deckenhöhe) generiert. Dabei wurde 

aber nicht jedes Gebäude einzeln, sondern Baublöcke untersucht. Auch ein DGM ist in die‐ 

sem Modell nicht vorhanden, lediglich eine plane Bodenplatte wurde als DGM erstellt. 

Schritt 2: Erstellung der Texturen 

Für die Erstellung von Texturen wird bei 3D‐Stadtmodellen meist auf hochwertige DSLR (digi‐ 

tale Spiegelreflexkameras) mit speziellen Weitwinkelobjektiven zurückgegriffen. Der Grund 

dafür liegt in der Art und Weise der Texturierung. Dabei wird versucht, ein einziges Fassa‐ 

denfoto auf eine Gebäudefront in der 3D‐Geometrie zu legen. Um den Nachbearbeitungs‐ 

aufwand (Postprocessing) so gering wie möglich zu halten, ist es dabei sinnvoll, ein Weitwin‐ 

kelobjektiv zu wählen, das mit seiner Perspektive eine ganze Hausfassade auf einmal erfasst. 

Problematisch bei dieser Vorgehensweise war bisher immer, dass störende Bildelemente wie


Bäume, Fahrzeuge und Fußgänger aufwendig aus dem Bild herausretuschiert werden muss‐ 

ten. Diese Arbeit macht in der Regel den größten Zeitaufwand bei der Erstellung eines 3D‐ 

Stadtmodells aus. Der prozentuale Anteil liegt dabei zwischen 40 bis max. 80 Prozent (eige‐ 

ner Erfahrungswert). 

Abbildung 63: Bildentzerrung in Photoshop (eigene Darstellung) 

Das im vorliegenden Modell verwendete Verfahren basiert hingegen auf einer Mischung aus 

generischer Texturierung und objektorientierter Texturierung. 

Theorie des neuen Verfahrens: Die Fassade eines Gebäudes ist in der Regel von einer Sorte 

Fenstern und ein bis zwei verschiedenen Fassadenmaterialien bestimmt. Statt wie bisher nur 

ein Bild, mit einer Auflösung von 1024 mal 1024 Pixeln (meistens nur 512 mal 512) als Textur 

für die ganze Fläche einzusetzen, werden für die Fassade eine oder zwei generische Texturen 

mit einer Auflösung von 256 mal 256 Pixeln verwendet. Diese besitzen eine Größe von etwa 

0,1m bis 0,5m in der Realität. Die Texturen werden dann flächendeckend nebeneinander 

wiederholt (Fachwort: Kachelung). Die zweite Textur ist die Fenstertextur mit einer Auflö‐ 

sung von max. 512 mal 512 Pixeln. In der Summe macht das eine Gesamtauflösung der Bild‐ 

daten von etwa 1024 mal 1024 Pixeln. Also dieselbe Größe wie die herkömmliche Methode. 

Da die Fassadentextur auf etwa 10m Fassadenfront wiederholt angewendet (gekachelt) 

wird, macht das bei einer realen Texturgröße von 0,1m und 256 mal 256 Pixeln Auflösung


eine texturierte Auflösung von 25.600 Pixeln für eine Gebäudefassade. Ähnlich verhält es 

sich mit der Fenstertextur, die auch mehrfach verwendet wird. 

Abbildung 64: Methodenvergleich, links herkömmliche Methode, rechts im Erstellungsprozess verwendete Methode 

(eigene Darstellung) 

Die Vorteile dieses Verfahrens liegen auf der Hand: 

1. erhöht sich durch die stark vergrößerte Auflösung der Detaillierungsgrad erheblich 

2. können gewöhnliche Kameras verwendet werden, da kein Gesamtbild der Fassade 

mehr erstellt werden muss, sondern nur noch kleinformatige Materialproben der 

Fassade genommen werden 

3. eine aufwendige Retuschierung der Fassadenbilder, die den Großteil des Postproces‐ 

sings ausmacht, entfällt, da meist nur ein kleines Stück der Fassade fotografiert wer‐ 

den muss 

4. sich die Gesamttexturmenge verringert (gerechnet in MB Grafikkartenspeicher) 

5. die Geschwindigkeit erheblich erhöht wird, da eine Grafikkarte viele kleine Dateien 

schneller bearbeiten und darstellen kann als eine große Textur. Der Grund dafür ist 

die Speicherbandbreite der Grafikkarte 

6. Durch die eingesparte Menge an Grafikspeicher können entweder mehr Gebäude 

texturiert werden oder dieselbe Menge aufwendiger mit einer höheren Auflösung. 

(Beispielrechnung: 1 mal 1024 2 Pixel (herkömmliche Fassadentextur) verbraucht 3Mb 

Grafikspeicher; 2 mal 256 2 Pixel (Fassadentextur)plus 1 mal 512 2 Pixel (Fenstertextur) 

verbraucht zusammen 556Kb Grafikspeicher bei Anwendung der neuen Methode) 

Die Hauptvorteile liegen aber in der enormen Zeitersparnis durch die wegfallende Nach‐ 

bearbeitung der Fassadenbilder, die vergrößerte Menge an verfügbarem Grafikspeicher und 

die größere Performance im eigentlichen 3D‐Stadtmodell. 

Die Erstellung der verwendeten Texturen geschah durch Fotografie der Gebäude. Anschlie‐ 

ßend wurden die Bilder vollautomatisch einer Linsenkorrektur mit dem Programm „Adobe 

Photoshop CS4“ und dem Plug‐in PTLens unterzogen. Danach wurden die Bilder in Texturen


umgewandelt. Die Fassadentexturen wurden über geringe Bildretusche „kachelbar“ gemacht 

(siehe Bild unten). Die genaue Beschreibung dieses Vorgangs ist allgemein bekannt und wird 

von ZEILE [2004] umfassend dargestellt. 

Abbildung 65: Prinzip der Kachelung von Texturen (eigene Darstellung) 

Die Texturen für das Modell von 1160 (Kaiserpfalz) kamen zu einem sehr späten Zeitpunkt im 

Erstellungsprozess des 3D‐Stadtmodells dieser Arbeit. Zusätzlich stellte sich heraus, dass die 

Texturen für eine Verwendung in einem Echtzeitmodell aus mehreren Gründen ungeeignet 

waren. Alternativ hätte das komplette Modell von 1160 in Handarbeit mit selbst erstellten 

Texturen texturiert werden müssen. Um den Rahmen der Arbeit nicht zu sprengen und die 

Fertigstellung des restlichen Modells zu sichern, wurde vom Autor der Arbeit entschieden, 

das Modell von 1160 abstrahiert darzustellen. Dazu wurde es aus inhaltlichen und ästheti‐ 

schen Gründen nur mit einer Farbe und Lightmaps (siehe Schritt 6) texturiert. 

Schritt 3: Organisation der Geometrie 

Als dritten Schritt wurden die erstellten Geometrien über das Autodesk DGW‐Format in das 

3D‐Modellierungsprogramm 3D‐Studio‐Max 9 des Anbieters Autodesk migriert. Der Grund 

dafür liegt in der Möglichkeit die Daten gut zu strukturieren, den guten Exportfunktionen 

(mehr mögliche Exportformate), der Möglichkeit, von komplexeren Texturierungsfunktionen


und der Fähigkeit, sog. Lightmaps zu erzeugen. Die Anwendung gilt im Erstellungsprozess 

von texturierten 3D‐Geometrien und Computerspielen als Standard [www.autodesk.com]. 

Die Texturierung über die Anwendung Google Sketchup wäre zwar auch möglich gewesen, 

hätte aber zu schlechteren Ergebnissen bei Texturierung und Lightmapping geführt. Zudem 

waren nur unzureichende Exportfunktionen für einen konsistenten Workflow vorhanden. 

Schritt 4: Texturierung der Geometrie 

Mit den Texturierungsfunktionen des 3D‐Modellierungs‐Programms 3D‐Studio‐Max 9 wur‐ 

den die Geometrien mit Texturen belegt und mit sog. Texturkoordinaten versehen. 

Letztere legen fest, wie eine Textur auf einer Geometrie ausgerichtet ist, und sind für die 

Darstellung in der späteren Echtzeitanwendung von elementarer Bedeutung. 

Die Erstellung der Texturen und die Texturierung der aller Geometrien dauerte 8 Wochen á 

5‐6 Tage pro Woche á 8 Stunden Arbeit pro Tag: macht zusammen 352 Stunden. 

Bezüglich der verwendeten Statistik der Bildschirmarbeit wurden bei den Schritten 2 und 4 

insgesamt 360.000 Mausklicks getätigt und 50 Km Mausweg zurückgelegt. Das entspricht 

etwa 18 Mausklicks und 2,4 Meter Mausweg pro Minute. 

Für die Erstellung der Geometrien und der Texturen wurden mit einer handelsüblichen Digi‐ 

talkamera (Panasonic Lumix TZ5, 9 Megapixel) etwa 3000 Einzelfotos mit einem Datenvolu‐ 

men von etwa 15 Gb (Gigabyte) gemacht. 

Abbildung 66: Texturierung der Geometrien in 3D Studio Max (eigene Darstellung)


Schritt 5: Erstellung der Vegetation 

Ein sehr wichtiges Element bei der Erstellung von 3D‐Stadtmodellen ist seine Ausstattung 

mit Vegetationselementen. Die Bäume und Grünelemente sind für die Wiedererkennung 

und damit für die Akzeptanz des Modells von entscheidender Bedeutung. 

Der Stadtkern von Kaiserslautern ist geprägt von zahlreichen Baumgruppen und sog. Stra‐ 

ßenbegleitgrün. Das bedeutet, dass die vorhandene Raumstruktur des Stadtkerns stark von 

Bäumen und Büschen beeinflusst wird. Für die Erstellung eines 3D‐Stadtmodells mit einem 

LOD 3+ sind Vegetationselemente üblich. Für die Verwendung desselben als Touristeninfor‐ 

mationssystem sind Vegetationselemente noch wichtiger. 

Für die Darstellung von Vegetationselementen gibt es verschiedene Methoden. Das Haupt‐ 

problem dabei ist aber immer die Darstellung von Blättern. Da ein 3D‐Stadtmodell geomet‐ 

risch immer auf Polygonen basiert, würde die Modellierung eines Baumes mit allen Blättern 

(eine 80 jährige Buche hat etwa 800.000 Blätter [www.wikipedia.de]) die Kapazitäten des 

Computers sprengen. Schon ein Baum mit diesen Daten wäre ausreichend, um die Darstel‐ 

lungsgrenzen eines Echtzeitmodells auszulasten. Die Darstellung von etwa 150 Bäumen wie 

im 3D‐Stadtmodell Kaiserslautern wäre unmöglich. 

In Zusammenhang mit der Lösung dieses Problems haben sich zwei Methoden durchgesetzt. 

Die erste Methode regelt die Darstellung von Vegetation über sog. Billboards. 

Definition: Billboard (eigene Definition) 

Ein Billboardelement meint im Kontext der 3D‐Stadtmodelle eine Scheibe, die mit einer teil‐ 

transparenten Textur belegt ist, um komplexe Elemente mit sehr wenigen Polygonen darzus‐ 

tellen. In der Regel werden polygonreiche Elemente wie Vegetation oder Personen durch 

Billboards ersetzt, um die Computerkapazitäten zu schonen [vgl. www.microsoft.com]. 

Häufig werden statt einfachen Scheiben sog. kreuzförmige Billboards (auch XFrogs genannt) 

verwendet, die sich mit der Kameraperspektive mitdrehen. Dadurch kann man ganze Wälder 

darstellen, ohne die Kapazitäten des Computers zu belasten. Die Qualität ist abhängig von 

der gewählten Textur. 

Der größte Nachteil ist der fehlende Realismus bei dieser Methode. Der Nutzer erkennt 

zwar, dass es sich um Vegetation handelt, die Wiedererkennung wird dadurch aber häufig 

herabgesetzt. Ein weiteres Problem ist die Erstellung von Lightmaps. Bei der Verwendung 

von Billboardbäumen kommt es bei der Erstellung von Lightmaps zu sehr unrealistischen 

Schatten. 

Trotzdem gibt es Hersteller, die diese Methode perfektioniert haben und Billboards in her‐ 

vorragender Qualität anbieten [vgl. www.greenworks.de]. Der Preis ist aber enorm hoch und 

nur für größere Projekte mit entsprechender planerischer Relevanz vertretbar (z.B. die Vi‐ 

sualisierung einer Bundesgartenschau).


Abbildung 67: Vergleich, links Billboard‐Baum; rechts im Erstellungsprozess verwendete Bäume (eigene Darstellung) 

Die zweite Methode ist die Abstraktion des Baumes auf seine wesentlichen Elemente wie 

den Stamm, die Äste und die Blätter. Ein einziger Hersteller hat es geschafft, eine Kombina‐ 

tion aus geometrischen Bäumen und niedrigen Polygonzahlen zu erstellen. Der Hersteller 

von 3D‐Bäumen „Speedtree“ vertreibt eine Software gleichen Namens zur generischen Ers‐ 

tellung aller Arten von Vegetation. Die Anzahl der Polygone variiert dabei zwischen 500 und 

1500 Polygonen pro Element, was branchenweit einmalig ist. Kombiniert mit dynamischen 

LOD (also Veränderung des LOD eines Objektes abhängig von seiner Entfernung zur Betrach‐ 

terposition) ist die Darstellung fotorealistischer Wälder kein Problem. Die Software kommt 

aber fast ausschließlich in kommerziellen Projekten der Unterhaltungsindustrie (Computer‐ 

spielen) zum Einsatz, da allein der Vertrieb eines Spiels die extremen Kosten von 10.000 Dol‐ 

lar pro Projekt ausgleichen kann. Der Hersteller besitzt auf dem Gebiet der 3D‐Vegetation 

ein absolutes Marktmonopol, welches er sehr gut schützt. Der Einsatz in der Planung wäre 

zwar von enormem Vorteil und wünschenswert, ist aber durch die hohen Kosten unrealis‐ 

tisch. 

Für das 3D‐Stadtmodell in dieser Arbeit wurde der Hersteller um eine Testversion oder ein 

kostenloses Testexemplar der Anwendung gebeten. Nach der Sichtung einer 30‐tägigen 

Testversion, für welche ein eigener Nutzungsvertrag erforderlich war, konnte die Erstel‐ 

lungsmethode der Bäume vom Autor adaptiert werden.


Durch einen eigens entwickelten Herstellungsprozess konnten ähnlich realistische 3D‐Bäume 

für den Praxisteil der Arbeit erstellt werden. 

Dazu wurden in der Anwendung Xfrog des Herstellers Greenworks, welche relativ preisgüns‐ 

tig (etwa 300 Dollar) ist, Stämme mit sehr wenigen Polygonen erstellt und nach 3D Studio 

MAX exportiert. Dort wurden unter Anwendung komplexer Programmfunktionen Billboards 

mit Blatttexturen an die Äste des Baumes angegliedert und der Stamm texturiert. 

Insgesamt wurden im 3D‐Stadtmodell der Arbeit etwa 150 Bäume in drei verschiedenen 

Qualitäten verwendet. Diese machen den Großteil der 3D‐Geometrien aus (etwa 350.000 

Polygone). 

Abbildung 68: Anwendung Speedtree mit einem Baum (IDV Inc., 2009, und eigener Screnshot) 

Schritt 6: Lightmapping 

Definition: Lightmapping 

Unter dem Begriff Lightmapping versteht man ein Verfahren Schatten in einem 3D‐Modell 

vorzuberechnen und anschließend in ein Bild (Lightmap) zu speichern. 

Das Modell mit Lightmaps zu versehen, geschah basierend auf dem gewählten LOD 3+ und 

der großen zur Verfügung stehenden Menge an Grafikspeicher, welche sich durch die neue 

Texturerstellungsmethode ergab. Lightmaps erhöhen den Wiedererkennungswert eines Mo‐ 

dells sehr und tragen stark zur späteren Akzeptanz des Modells bei den Adressaten bei. Dies


gelingt durch den höheren Realitätsgrad durch ein Modell mit Schattenwurf, da in der Reali‐ 

tät die Seiten eines Gebäudes fast nie gleichmäßig belichtet sind. 

Die Alternative zu Lightmaps stellt die Berechnung der Schatten in Echtzeit dar. Diese Me‐ 

thode war aber bis heute extrem hardwareintensiv und bei flächigen 3D‐Stadtmodellen aus 

Kapazitätsgründen nicht anwendbar. Es gibt heute innovative Ansätze im Bereich der Soft‐ 

wareproduzenten und extremleistungsfähige Grafikkarten, die dieses Problem lösen. Da das 

Modell aber einem möglichst großen Publikum zur Verfügung stehen soll, wurde im Praxis‐ 

teil auf Lightmaps statt Echtzeitschatten gesetzt. 

Die Erstellung funktioniert halb automatisch aus der Anwendung 3D‐Studio Max heraus. Da‐ 

zu muss für die 3D‐Daten ein zweiter Texturkoordinatensatz erstellt werden und anschlie‐ 

ßend über eine sog. „Render to Texture“‐Funktion die Lightmaps als Bilddateien gespeichert 

werden. Der verwendete Renderer war VRay des Herstellers Chaos Group. Die Auswahl wur‐ 

de wegen der hohen Geschwindigkeit und der sehr hohen Qualität im Bezug auf den Realis‐ 

mus der Schattenberechnung des Renderplug‐ins getroffen. 

Abbildung 69: Vergleich, links Szene ohne Lightmaps, rechts Szene mit Lightmaps (eigene Darstellung) 

Schritt 7: Export der Daten nach Quest3D 

Die Anwendung Quest3D (Version 4.2.2) des Herstellers Act 3D ist eine C++ basierte 3D‐ 

Engine, welche mit einer containerbasierten Programmierung die Echtzeitvisualisierung von 

3D‐Inhalten ermöglicht. Sie wurde auf Grund ihrer umfangreichen Editierbarkeit, ihrer her‐ 

vorragenden Performance und der guten Bedienbarkeit ausgewählt. 

Die Entscheidung für eine 3D‐Engine‐basierte Visualisierung wurde getroffen, weil diese Me‐ 

thode die beste Qualität sowie Performance für 3D‐Stadtmodelle birgt und die individuelle 

Editierung und Gestaltung am besten mit den Anforderungen an heutige 3D‐Stadtmodelle 

korreliert. 

Zur Integration von Daten in Quest3D steht vornehmlich das Datenformat der Grafikschnitt‐ 

stelle DirectX (Microsoft), das X‐Format (kurz: x‐Files), zur Verfügung. Dieses textbasierte 

Format speichert die Geometrie‐ und Texturkoordinaten in einer Datei und ist auf maximale 

Kompatibilität mit der Grafikhardware ausgerichtet. (Vgl. Kap. 2.2.4) Es kann aus den meis‐ 

ten 3D‐Modellierungsprogrammen heraus exportiert werden.


Nach der Migration der Daten nach Quest3D werden diese in Untergruppen (sog. Channelg‐ 

roups) organisiert. 

Abbildung 70: Anwendung Quest3D; von links nach rechts: Editor, Kamerascreen, Channelgroups (eigene Darstellung) 

Schritt 8: Optimierung der Daten und Erstellung der Programmlogik in Quest3D 

Nach der Organisation der Daten müssen diese noch optimiert werden, um ein Maximum an 

Qualität und Performance zu gewährleisten. 

Zum einen müssen die vorhandenen Texturen, welche als JPEG‐Bild‐Datei vorliegen, in das 

DDS‐Format umgewandelt werden, da es bei der Verwendung von JPEGs zu starken Leis‐ 

tungseinbußen kommt. Der Grund dafür liegt darin, dass JPEGs ein komprimiertes Bilddaten‐ 

format sind, die bei Verwendung als Textur von der Grafikkarte erst dekomprimiert werden 

muss und dadurch zusätzlichen Speicher belegt. Ein weiterer Vorteil des DDS‐Formats ist die 

integrierte, berechnete Verwendung von MIP‐MAP‐Leveln. Dabei geht es um die dynamische 

Reduzierung der Texturgröße mit zunehmender Entfernung zum Betrachter, dieser Aspekt 

soll an dieser Stelle aber nicht näher ausgeführt werden [www.modwiki.net]. 

Zur Erstellung von DDS‐Dateien wird ein Open‐Source‐Programm (DDS‐Converter 2.1) ver‐ 

wendet. 

Abbildung 71: DDS‐Converter (eigene Darstellung) 

Nach der abschließenden Einbindung der darzustellenden Daten kommt als nächster Schritt 

die Erstellung der anwendungsinternen Logik. Das heißt, es muss eine Benutzeroberfläche 

(auch GUI = Graphics User Interface genannt) erstellt werden sowie eine Logik, welche das 

„Drücken“ der Knöpfe ermöglicht. Dabei werden im Wesentlichen die Prinzipien von „wenn,


dann, oder“ angewendet. Allerdings ist eine Einarbeitung in die Anwendungslogik des Prog‐ 

rammes Quest3D und grundlegender Programmiertechniken unerlässlich. 

Folgende Funktionen sollen in die Anwendung eingebaut werden: 

1. ein Informationsbildschirm zu Beginn der Anwendung 

2. eine pragmatische Steuerung über das GUI 

3. eine Steuerung ohne GUI 

4. eine Kollision mit der Geometrie 

5. eine Screenshot‐Funktion 

6. eine Funktion zur Abfrage von Metadaten 

7. eine Funktion zur Überblendung verschiedener Modelle ineinander 

8. eine Funktion zum dynamischen Wechsel zwischen den einzelnen Modellen 

Funktion 1: Informationsbildschirm 

Zu Beginn der Anwendung wird der Anwender über einen Informationsbildschirm über die 

grundlegende Steuerung und die Inhalte der Anwendung aufgeklärt. 

Abbildung 72: Infoscreen der Anwendung (eigene Darstellung)


Funktion 2: Darstellung des GUI 

Das GUI besteht aus den Navigationstasten, der Infomodus‐Taste, um die Infopunkte zu akti‐ 

vieren, der Einblenden‐Taste, um andere Modelle in die aktuelle Szene einzublenden, die 

Hilfe‐Taste, um Informationen über die Inhalte, den Zweck und die Urheber der Anwendung 

darzustellen, und dem Zeitstrahl, um zwischen den verschiedenen Modellen hin und her zu 

schalten. 

Abbildung 73: Screenshot der Anwendung mit eingeschaltetem GUI (eigene Darstellung)


Funktion 3: Navigation ohne GUI 

Bei Ausblendung des GUI wird eine Steuerung entweder über die Richtungstasten oder über 

die Buchstaben W,A,S,D in Kombination mit der Maus aktiviert. Über die Tasten Bildlauf 

oben und unten kann die Höhe geändert werden. Die Bewegung der Maus hat eine Ände‐ 

rung der Blickrichtung zur Folge. 

Abbildung 74: Screenshot der Anwendung mit ausgeblendetem GUI (eigene Darstellung)


Funktion 4: Kollision mit der Geometrie 

Die Navigation wird durch eine permanente Kollisionserkennung mit der dargestellten Geo‐ 

metrie bestimmt. Es kann u.U. zu einem Fehler in der Kollisionslogik kommen, und eine Na‐ 

vigationssperre kann eintreten. Die Ursache dafür liegt in einem Softwareproblem. Um die‐ 

ses Problem zu beheben, wurde eine Positionsverschiebung über die K‐Taste eingebaut, wel‐ 

che die Navigationssperre aufhebt. 

Abbildung 75: Screenshot der Anwendung, Darstellung von Kollisionsobjekten (eigene Darstellung)


Funktion 5: Screenshots 

Durch Betätigen der B‐Taste können aus der Anwendung heraus Screenshots (Bildschirmfo‐ 

tos) erstellt werden, welche von der Anwendung auf dem Desktop abgelegt werden. 

Abbildung 76: Screenshots der Anwendung werden auf dem Desktop abgelegt (eigene Darstellung)


Funktion 6: Abfrage von Metadaten 

In die Anwendung wurde ein System zur Darstellung und die Abfrage von Metadaten einge‐ 

baut. Dieses System arbeitet mit sog. Infopunkten. Diese wurden gewählt, um die Übersicht‐ 

lichkeit des Modells nicht einzuschränken und dennoch die Auffindbarkeit von Interaktions‐ 

punkten zu ermöglichen. Vorbild für die Idee dazu war im Übrigen auch hier die Unterhal‐ 

tungsindustrie, in der sich dieses System der Infopunkte über Jahre bewährt hat. 

Zur Darstellung muss der Anwender die Infomodus‐Taste drücken und kann dann durch ei‐ 

nen Mausklick auf den Infopunkt Informationen über das jeweilige Objekt, in dessen Nähe er 

steht, erhalten. Die Informationen werden in einem roten Pop‐up‐Fenster dargestellt und 

geben auch Verweise auf die bestehenden anderen Modelle. Dadurch wird der Nutzer dazu 

animiert, sich den kompletten Inhalt der Anwendung anzusehen. 

Abbildung 77: Infopunkte in der Anwendung (eigene Darstellung) 

Abbildung 78: Darstellung von Metadaten im Infopop‐up (eigene Darstellung)


Funktion 7: Überblendung anderer Modelle 

Über die Einblenden‐Taste kann der Nutzer sich zusätzlich zum dargestellten Inhalt ein wei‐ 

teres Modell (z.B. die Kaiserpfalz) einzublenden. 

Abbildung 79: Gegenwartsmodell mit eingeblendetem Modell der Kaiserpfalz (eigene Darstellung) 

Funktion 8: dynamischer Wechsel zwischen den Modellen 

Der im unteren Bereich des GUI angeordnete Zeitstrahl stellt die Funktion zum dynamischen 

Wechsel zwischen den einzelnen Modellen. Durch Anklicken der Uhr auf dem Zeitstrahl und 

anschließendes Verschieben der Uhr auf eine andere Zeit wird dynamisch das entsprechen‐ 

de Modell dargestellt. Bei der ersten Betätigung kann es zu einer kurzen Verzögerung kom‐ 

men, die abhängig von der Hardwareausstattung des Computers ist. 

Die jeweilige aktive Zeit wird zusätzlich durch eine Rotfärbung der Jahreszahl und des ent‐ 

sprechenden Symbol angezeigt. 

Abbildung 80: Zeitstrahl zum Wechseln der angezeigten Zeit (eigene Darstellung)


Schritt 9: Integration von Metadaten 

Nach der Erstellung der Anwendungslogik können ohne größeren Aufwand die Metadaten, 

per Texteingabe eingetragen werden. Weiterhin könnten zusätzliche Infopunkte erstellt 

werden, und nach Belieben Metadaten eingefügt werden. 

Abbildung 81: Anwendung Quest, Eingabefenster für Metadaten (eigene Darstellung)


Schritt 10: Publizierung als Viewer 

Nach der Abarbeitung des Erstellungsprozesses kann das komplette Modell über eine „Publi‐ 

zieren“‐Funktion in eine einzelne Ausführungsdatei (Fachwort: „Executable“) zusammenge‐ 

fasst werden. Dabei wird die interne Anwendungslogik beibehalten. Die finale Zusammen‐ 

führung aller Daten in eine Executable hat den Vorteil, dass die Anwendung sehr portabel 

und sehr sicher bezüglich der integrierten Daten ist. Nachteilig dabei ist, dass alle Daten auf 

einmal geladen werden. Dies kann auf Rechnern mit geringerer Leistungsfähigkeit zu langen 

Ladezeiten führen. Daneben stehen als Publizierungs‐Formate noch die eines Installers, bei 

dem das gesamte Projekt als Anwendung auf dem Computer installiert wird, und die Veröf‐ 

fentlichung als webbasierter Viewer zur Verfügung. 

Die Statistik bezüglich der Bildschirmarbeit stellt für die Punkte 8, 9 und 10 des Erstellungs‐ 

prozesses 3 Wochen á 5‐6 Tage á 8 Stunden Arbeit fest: macht zusammen 132 Stunden. Zu‐ 

sätzlich wurden 127.000 Mausklick getätigt und 18 km Mausweg zurückgelegt. Das ent‐ 

spricht 16 Mausklicks und 2,3 Meter Mausweg pro Minute. 

Abbildung 82: Anwendung Quest3D, Publish‐Funktion (eigene Darstellung) 

Die Statistik für die komplette Erstellung des 3D‐Stadtmodells: 18 Wochen á 5‐6 Tage pro 

Woche á 6‐8 Stunden pro Tag: macht min. 715 Stunden Arbeit, da z. B. die Zeit für die Erstel‐ 

lung der Vegetation nicht mit erfasst wurde. Insgesamt wurden 997.000 Mausklicks getätigt 

und 129km Mausweg zurückgelegt. Das macht im Schnitt: 23 Mausklicks und 3 Meter 

Mausweg pro Minute.


4.8 Inhalte und technische Möglichkeiten 

Nach dem der Erstellungsprozess abgeschlossen wurde, sollen nun die Inhalte des Modells 

und mögliche Erweiterungen und technische Möglichkeiten diskutiert werden. 

Modell 2009 

Das 3D‐Stadtmodell besitzt in der Gegenwart ein LOD‐3‐ bis LOD‐4‐Modell. Dieses bietet 

einen realistischen Überblick über die tatsächliche Raumstruktur und ist als Basis für öffent‐ 

liche Diskussionen durch seinen hohen Wiedererkennungswert hervorragend geeignet. Alle 

integrierten Gebäude sind mit einer sehr hohen Detailtreue erstellt worden und weichen nur 

unwesentlich vom Original ab. 

Eine weitere Erhöhung des LOD ist nur noch durch sehr aufwendige Detailmodellierung oder 

den Einsatz spezieller Darstellungstechniken, wie Normal‐Mapping oder Steep‐Paralax‐ 

Mapping (beides Techniken zur Verstärkung der Tiefenwirkung von Geometrien) möglich. 

Weiterhin könnte durch eine Integration einer größeren Zahl von Raummöbeln wie Later‐ 

nen, Pollern oder Parkuhren ein höherer LOD erreicht werden. Diese wurden absichtlich 

weggelassen, um den planerischen Wert des Modells nicht zu mindern. Auch Büsche und 

kleinräumige Vegetation wurden bewusst weggelassen, um eine bessere Übersichtlichkeit zu 

gewährleisten. Vor allem die Treppenanlage im Bereich des Rathausvorplatzes wäre mit vol‐ 

ler Vegetation nicht mehr übersichtlich navigierbar. Alle genannten Elemente sind aber ohne 

Weiteres nachträglich einfügbar. 

Auch die Darstellungsqualität der Pflanzen ist noch verbesserbar. Die verwendeten Bäume 

im Modell können nur als Exempel gelten, da es insgesamt nur drei verschiedene Sorten 

gibt. Ihre Erstellung war sehr aufwendig, für das Modell sollten aber keine scheibenartigen 

Billboards zu Einsatz kommen. Durch den Einsatz einer differenzierten Vegetation ist eine 

Steigerung des Wiedererkennungswertes und des LOD auf jeden Fall möglich. 

Insgesamt ist der Erstellungsprozess wiederholbar und rückwärts editierbar. Das heißt, Än‐ 

derungen können sehr leicht vorgenommen werden und der Workflow ist keine „Einbahn‐ 

straße“. Dies ist vor allem im Hinblick auf die Schaffung eines langfristigen Workflows zur 

Erstellung eines 3D‐Stadtmodells der Gesamtstadt wichtig. 

Die integrierten Metadaten können beliebig abgefragt werden und können, im Sinne einer 

Erweiterung, auch mit anwendungsexternen Inhalten verknüpft werden. Die Realisierung 

einer Datenbankanbindung wurde aus Zeitgründen in dieser Arbeit aber nicht durchgeführt. 

Damit wären z. B. die Metadaten im Modell, ähnlich wie bei den Virtual Globes, dynamisch 

aktualisierbar. Ein weiteres sinnvolles Feature stellen Verknüpfungen zu Internetauftritten 

dar. Bei der Aktivierung bestimmter Infopunkte würde im Modell oder extern ein Fenster mit 

dem passenden Internetauftritt geöffnet. Dieser Punkt ist u.a. einen Ansatz zu einem Refi‐ 

nanzierungsmodell. Da im Modell auch Gebäude des Einzelhandel dargestellt werden, könn‐ 

te man gegen eine Gebühr eine Texturierung mit dem Logo des Einzelhandelbetriebs integ‐ 

rieren und einen Infopunkt mit einem Link auf seinen Internetauftritt.


Modell 1889 

Das Modell von 1889 ist ein LOD 1 Modell ohne Texturierung. Es stellt aber einen nicht zu 

unterschätzenden Wert in Bezug auf zukünftige Planungen dar, da es die alte Stadtstruktur 

in der Gegenwart übersichtlich darstellt und planerische Rückschlüsse und Analysen zulässt. 

Weiterhin lässt sich das Modell gegen eines mit einem höheren LOD austauschen. 

Modell 1160 

Das Modell von 1160 beruht zwar auf einer monatelanger Recherchearbeit der Firma ReUni‐ 

on‐Media bezüglich der möglichen historischen städtebaulichen Situation, kann aber nur als 

wahrscheinlicher Rekonstruktionsversuch der historischen Realität gelten. Um die Maßstäbe 

der Denkmalpflege oder der Archäologie durchzusetzen, müssten wesentlich größere Pro‐ 

jektlaufzeiten und Finanzierungspläne aufgestellt werden. Das Modell gibt dennoch einen 

guten Überblick über die Situation der alten Kaiserpfalz und seiner Umgebung. Sowohl für 

Planer als auch für Bürger der Stadt, Touristen und sonstige Interessierte stellt dieses Modell 

eine hervorragende Informationsquelle dar. Ein Einsatz in städtischen Museen, in der Touris‐ 

tinfo, dem Theodor‐Zink‐Museum Kaiserslautern oder im Foyer des Rathauses ist denkbar. 

Weiterhin könnte das Modell in Schulen im Geschichtsunterricht eingesetzt werden 

[www.stadtplanungsamt‐bamberg.de] 

Die historischen Inhalte können nur als Exempel dienen, nachdem nach genauer Recherche 

festgestellt wurde, dass die Erstellung historischer 3D‐Inhalte mit hohen HLOD nur in Zu‐ 

sammenarbeit mit anderen Wissenschaften möglich ist. Trotzdem zeigen sie auf, wie ein 

historisches 3D‐Stadtmodell erstellt und visualisiert werden kann. Auch ihr Nutzen für ver‐ 

schiedene Anwendungsfelder ist im Modell erkennbar. Denkbar wäre eine langfristig ange‐ 

legte Erstellung von Einzelmodellen der Geschichte, welche Stück für Stück in das vorliegen‐ 

de Modell integriert werden. 

Die möglichen Einsatzfelder sollen aber im nachfolgenden Kapitel genauer beleuchtet wer‐ 

den. 

4.9 Einsatzfelder und Weiterbearbeitung 

Die möglichen Einsatzfelder von 3D‐Stadtmodellen werden von ZEILE [2004] sehr ausführlich 

beschrieben und decken eine große Bandbreite an Möglichkeiten ab. KIRMSE [2006] geht 

ebenfalls sehr detailliert auf die potenziellen Anwendungsfelder ein, unterscheidet aber 

noch genauer, indem er den notwendigen LOD für das jeweilige Anwendungsfeld qualifiziert. 

Im Folgenden sollen die Einsatzfelder eines historischen 3D‐Stadtmodells beleuchtet wer‐ 

den. 

Das Ziel, ein digitales historisches 3D‐Stadtmodell zu erstellen, wurde erfüllt. Doch wofür 

lässt sich ein solches Modell nutzen? Gerade für die Neuplanung des Rathausareals ist dieses 

Modell von großem Nutzen. Die Planer können zum einen die aktuelle und die historische 

Situation besser beurteilen und bekommen eine völlig neue Sichtweise bezüglich ihrer Pla‐ 

nungen. Auch die Dimension der historischen Baukörper kann besser bemessen werden.


Denkbar wäre ein Variantenmodell, bei dem Neuplanungen in das vorliegende 3D‐ 

Stadtmodell integriert werden und zur Präsentation im Stadtrat und in der Öffentlichkeit 

genutzt werden. Allen Beteiligten wäre ein besserer Zugang zum Thema gewährt, und auch 

Laien könnten die Bedeutung und Auswirkung von Neuplanungen besser beurteilen. 

Ein weiterer Einsatzzweck könnte der eines Touristeninformationssystems sein. Kaiserslau‐ 

tern ist, mit seiner Nähe zum Pfälzer Wald, dem 1.FCK und nicht zuletzt wegen seiner histori‐ 

schen Vergangenheit, das Ziel von Touristen. Wie in Kapitel 4.1 schon erwähnt, plant die 

Stadt eine Verbesserung der touristischen Nutzung des Areals um die bestehenden histori‐ 

schen Bauten. Dazu wäre der Aufbau eines Touristeninformationssystems denkbar, bei dem, 

an verschiedenen Stellen im Stadtkern, Terminals aufgebaut werden, an denen sich der Nut‐ 

zer (in diesem Fall der Tourist) über die Historie bestimmter Lokalitäten informieren kann. 

Durch die zeitliche Dimension des 3D‐Stadtmodells würde er auch einen optischen Eindruck 

von der Vergangenheit bekommen. 

Abbildung 83: Beispiel für ein Terminal des Touristeninformationssystems (eigene Darstellung) 

Zudem stellt das 3D‐Stadtmodell ein Produkt dar, welches an Touristen vermarktet werden 

kann. Hier ist ein Ansatz für ein Refinanzierungskonzept für die Kosten eines solchen Modells 

erkennbar. 

Alles in allem würde ein solches Touristeninformationssystem auf Basis des vorliegenden 3D‐ 

Stadtmodells das historische Verständnis der Stadt bei allen potenziellen Nutzern verbes‐ 

sern. 

Wie oben schon erwähnt, kann dieses Modell auch als Ausgangpunkt für ein gesamtstädti‐ 

sches Modell dienen, bei dem die Fläche der Stadt in Einzelprojekten modelliert, texturiert


und dann an das Modell des Stadtkerns angegliedert werden kann. Dies kann sowohl für 

Modelle der Gegenwart als auch für historische Modelle gelten. Die Erweiterung des 3D‐ 

Stadtmodells um historische Teilmodelle unterscheidet sich lediglich im Zeitfaktor von einer 

Erweiterung mit Gegenwartsmodellen, da sie aufwendiger in ihrer Generierung sind. 

Abbildung 84: Raster der Teilstücke des Stadtmodells von Bamberg (eigene Darstellung) 

Die Betrachtung der möglichen Anwendungsfelder ist keineswegs abschließend, denn die 

Bandbreite dieser ist wie bei den herkömmlichen 3D‐Stadtmodellen sehr groß. Weitere An‐ 

wendungsfelder finden sich im Bereich der Denkmalpflege, der Stadtgestaltplanung oder der 

Freiraumplanung. 

Im nachfolgenden, abschließenden Kapitel sollen die Probleme bei der Erstellung behandelt 

und ein Ausblick in die Entwicklung der 3D‐Stadtmodelle gegeben werden. Anschließend soll 

in der Zusammenfassung ein Resümee der gesamten Arbeit erfolgen.

5. Fazit und Ausblick 

5.1 Probleme und Hindernisse 

5.Fazit und Ausblick 99 

Im Folgenden sollen einige Probleme und Hindernisse, die während der Arbeit und speziell 

während der Erstellung des 3D‐Stadtmodells auftraten, aufgezeigt werden. Im Sinne einer 

Optimierung zukünftiger Projekte und einer Evaluation des Workflows soll durch Dokumen‐ 

tation der Fehlerquellen zukünftigen Projekten ein Wissensvorsprung ermöglicht werden. 

Der gewählte Erstellungs‐Workflow hat sich zwar als effektiv herausgestellt, war aber trotz‐ 

dem von Einzelproblemen durchzogen. Diese Probleme werden nachfolgend aufgelistet und 

beschrieben. Dies kann aber nicht abschließend geschehen, da viele Fehler, z. B. die Gründe 

für Programmabstürze, nicht erfasst werden konnten. 

Hindernisse bei der Datenerhebung 

Bei der Erhebung der Daten musste sich der Autor oftmals auf persönliche Gespräche und 

mündliche Verweise verlassen. Diese waren oftmals unzuverlässig und gefährdeten dadurch 

den Erstellungsprozess. Der Grund war, dass sich einige Daten an völlig anderen Orten be‐ 

fanden, als in den Einzelgesprächen angegeben worden war. Manche Daten existierten gar 

nicht. Im Nachhinein ist festzustellen: Nur bereits verwendete Daten sind sichere Daten. 

Durch die Vielzahl an Datenquellen war im Übrigen nur sehr schwer ein Überblick zu behal‐ 

ten. Gerade bei der Recherche von historischen Daten und der Arbeit mit ihnen wäre ein 

besseres Datenmanagement notwendig gewesen. Weiterhin war bei der Anwendung von 

Datenredundanz auf eine durchdachte „Versionierung“ der Einzeldateien zu achten. Durch 

schlechte Datenverwaltung kam es vereinzelt zu einem Informationschaos, das nur durch 

aufwendige Neustrukturierung zu bewältigen war. Im schlechtesten Fall wurden sogar Daten 

überschrieben, die gar nicht oder nur sehr schwer wiederzubeschaffen waren. 

Bei der Erhebung von Daten von externen Quellen wie Firmen war darauf zu achten, dass 

der Projektzeitplan nicht außer Acht gelassen wurde und Alternativen im Voraus eingeplant 

wurden. Der Praxisteil der vorliegenden Arbeit wäre fast an der extrem verzögerten Liefe‐ 

rung von Daten gescheitert. Die Geometrien der Firma ReUnion‐Media mussten immer wie‐ 

der telefonisch und per Mail angefordert werden und kamen dennoch mit einer Verspätung 

von zweieinhalb Monaten beim Autor an. Die Texturdaten sogar erst 3 Wochen vor Ende der 

Arbeit. Die Gründe dafür lagen in der Projektarbeit der Firma. ReUnion‐Media war durch ein 

hohes Auftragsvolumen und wichtige Abgabetermine nicht in der Lage, die Daten aufzufin‐ 

den und zu versenden. 

Ein weiteres Problem in diesem Zusammenhang war die rechtliche Situation. Während die 

Stadt sich sicher war, alle Rechte bezüglich der 3D‐Daten des Animationsfilm von 1160 inne 

zu haben, sah die Realität anders aus. Die Stadt hatte zwar alle Rechte an der Vermarktung 

der DVD, inklusive des enthaltenen Animationsfilms, nicht aber an den eigentlichen 3D‐ 

Daten. Die Rechte an den Rohdaten lagen nämlich bei ReUnion‐Media. Um deren Verwen‐ 

dung und um den Einsatz rechtlich in dieser Arbeit zu ermöglichen, mussten viele Telefonate 

und Einzelgespräche geführt werden.

100 5. Fazit und Ausblick 

Bei der Erhebung von Texturdaten waren weitere Probleme zu bewältigen. Zunächst gab es 

technische Hürden. Um die Bildbearbeitung im Voraus auf ein Minimum zu reduzieren, 

mussten die Fotos bei möglichst ähnlichen Licht‐ und Wetterbedingungen erstellt werden. 

Dies war bei einem Plangebiet wie dem Stadtkern von Kaiserslautern an einem Tag nicht 

realisierbar. Das heißt, dass die Bilddaten im Nachhinein noch zusätzlich im Hinblick auf Be‐ 

lichtung und Weißabgleich miteinander verglichen und nachbearbeitet werden mussten. 

Neben dem Wetter stellen die alltäglichen Prozesse des Stadtlebens einen nicht zu unter‐ 

schätzenden Faktor dar. Das sich das Plangebiet an einem ÖPNV‐Knotenpunkt befindet, 

waren Bildaufnahmen, auf denen keine Passanten im Bild waren, in diesem Bereich beson‐ 

ders schwierig. Dazu musste auf sehr frühe oder sehr späte Tageszeiten ausgewichen wer‐ 

den, zu denen wiederum die Lichtverhältnisse sehr ungünstig waren. 

Im Zusammenhang mit Bilddaten wurde auch die Erfahrung der Anfeindung gemacht. Nicht 

jeder Passant ist bereit, ein potenzielles Beiwerk einer Fotografie zu werden. Die rechtliche 

Lage ist zwar eindeutig, schützt aber nicht vor Anfeindungen. 

Abbildung 85: Beispiel für das Motiv und das „Beiwerk“ eines Bildes (eigene Darstellung) 

In Deutschland dürfen Fotos von Gebäuden zum nichtkommerziellen Gebrauch von jeder 

öffentlich zugänglichen Position gemacht werden, ohne dabei rechtliche Probleme zu verur‐ 

sachen. Das heißt, sofern nicht die Privatsphäre einer Person verletzt wird und sich der 

Standpunkt des Fotografen auf einer öffentlich zugänglichen Fläche befindet, ist ein Foto 

erlaubt. Personen, die nicht gezielt fotografiert werden, und nur zufällig sog. „Beiwerk“ eines 

Fotos sind, haben keinen Anspruch auf entsprechende Bildrechte, und sind auch nicht in 

ihrer Privatsphäre beeinträchtigt.[ www.fotorecht.de] 

Selbst die ausführliche Erklärung des wissenschaftlichen Verwendungszwecks konnte die 

Betroffenen nicht besänftigen. Weiterhin war es notwendig, Fotos von privatem Grund und 

Boden zu machen, da ansonsten Texturdaten gefehlt hätten, die auch nicht alternativ er‐ 

hebbar gewesen wären. Hierfür mussten wiederum zahlreiche Telefonate getätigt werden. 

In diesem Zusammenhang wäre eine entsprechende Genehmigung von Seiten der Stadt hilf‐ 

reich gewesen. Rechtlich ist dies ohne die Einschränkung von aber kaum zu bewerkstelligen


ohne die Einschränkung von Persönlichkeitsrechten. An dieser Stelle sei aber versichert, dass 

kein einziges Foto ohne die notwendige rechtliche Grundlage erstellt wurde. 

Hindernisse bei der Modellerstellung 

Die Modellerstellung war von zahlreichen Hindernissen geprägt, die teilweise überwunden 

werden konnten, für die teilweise aber eigene Lösungen gesucht werden mussten, um das 

Problem zu umgehen. Vor allem der Einsatz der gewählten Software verzögerte die Erstel‐ 

lung des Modells teilweise sehr. 

Google ‐ Sketchup 

Die Geometrieerstellung wurde vor allem durch die sehr zahlreichen Programmabstürze der 

Anwendung Google Sketchup behindert. Dadurch wurde mehrfach die Arbeit von Stunden 

zerstört. Ein kontinuierliches Speichern von Daten sollte der Grundsatz einer jeden wissen‐ 

schaftlichen Arbeit sein, wurde aber oft im Arbeitseifer vergessen. Gleichzeitig sollte, entge‐ 

gen den Angaben des Herstellers, immer damit gerechnet werden, dass Computerprogram‐ 

me abstürzen können. Ein weiteres Manko sind Fehlfunktionen der Programmlogik und der 

anwendungsinternen Darstellung von Geometrie. So mussten oft in stundenlanger Handar‐ 

beit Geometrien mehrfach erstellt werden, weil die Fangfunktion von Sketchup die falschen 

Punkte fängt. Dadurch wurden „windschiefe“ (nicht rechtwinklige) Geometrien erzeugt, die 

vom Anwender und dem Programm als lotrecht angenommen wurden. Unerklärlich waren 

auch oft Flächendefinitionen des Programms. Es zeigte Flächen an Positionen an, an denen 

überhaupt keine Flächen gezeichnet wurden. Auf der anderen Seite verschwanden Teile der 

Geometrie ohne Grund spurlos und konnten nur durch gute Datenredundanz gerettet wer‐ 

den. Zusätzlich stellte die benutzerunfreundliche Navigation im Modell den Autor teilweise 

vor erhebliche Probleme. Eine Navigation war teilweise nur nach einem Neustart des Prog‐ 

ramms möglich. Weiterhin war die Inkompatibilität der Anwendung Google Sketchup mit 

Grafikhardware (z. B. des Herstellers ATI) ein sehr zeitraubender Faktor. Ohne kompatible 

Treiber können in Sketchup selbst hochmoderne Grafikkarten nicht über eine Framerate von 

4 FPS bei der Darstellung eines einfachen Würfels hinaus kommen. 

Abbildung 86: Fangfehler in Sketchup bei sehr kleinen Punktabständen (eigene Darstellung)


Autodesk ‐ 3D Studio Max 

Das zweite verwendete Programm Autodesk 3D Studio Max verweigerte ebenso oft, teilwei‐ 

se aber mit wesentlich gravierenderen Folgen, den Dienst. Man sollte genauestens darauf 

achten, dass die Auto‐Save‐Funktion der Anwendung deaktiviert ist. Ansonsten kann es vor‐ 

kommen, dass das Programm bei einem Absturz, der ohne Ankündigung und offensichtli‐ 

chen Grund vorkommen kann, selbst gesicherte Daten überschreibt und somit löscht. Eine 

weitere Hürde stellte der Versuch der Automatisierung von Arbeitsprozessen dar. Diese 

wurden zwar bewältigt, bedurften aber oft eine stundenlangen Studiums von irreführenden 

Anleitungen und Tutorials des Herstellers der Anwendung. Weiterhin ist festzustellen, dass 

Autodesk 3D Studio Max nicht in der Lage ist ein standardkonformes DWG‐, DXF‐ oder 3DS‐ 

Format (Datenformate, siehe Glossar) zu schreiben und oft auch zu lesen, obwohl es Stan‐ 

dard‐Formate des Anwendungsherstellers sind. Auch die „Render to Texture‐Funktion“ der 

Anwendung ist alles andere als fehlerfrei und zerstörte Stunden an Arbeit durch die Über‐ 

schreibung von Texturkoordinaten. 

Abbildung 87: Autosave‐Funktion in 3D Studio Max (eigene Darstellung) 

Chaosgroup ‐ VRay 

Auch der verwendete Renderer VRay ist nicht fehlerfrei und verursachte Systemabstürze am 

Fließband. Nur durch langwieriges Studium von hochtechnischen Forenseiten konnten die 

Probleme dabei behoben werden.


Act 3D ‐ Quest3D 

Die Anwendung Quest3D übertrifft die drei Vorhergehenden in Punkto Komplexität, aber 

auch in Punkto Fehleranfälligkeit um ein Vielfaches. Dadurch kam es zu sehr langen Unterb‐ 

rechungen des Arbeitsprozesses. Oft musste das Programm oder auch der ganze Rechner 

neu gestartet werden, weil das Progamm mit den eigenen Programmroutinen überfordert 

war. Insbesondere die finale Publizierung des Projekts musste mehrfach um Tage verscho‐ 

ben werden, weil ein Fehler das Programm zum Abstürzen brachte. 

Abbildung 88: Anwendung Quest3D, Publish‐Error (eigene Darstellung)


Speedtree 

Für die Erstellung von Vegetation wurde zwischenzeitlich die Anwendung „Speedtree“ in 

Betracht gezogen. Dazu wurde der Hersteller unter Schilderung des wissenschaftlichen, nicht 

kommerziellen Hintergrundes der Arbeit angeschrieben und um eine kostenlose oder we‐ 

sentlich kostengünstigere Version gebeten. Nach dem Abschluss eines vierseitigen Vertrages 

wurde aber lediglich die Herausgabe einer 30‐tägigen Demoversion mit starken Einschrän‐ 

kungen bezüglich der Nutzung erreicht. Zusätzlich wurde von Seiten des Herstellers der Ver‐ 

kauf des Originalprodukts für 10.000 Dollar mit ungewöhnlicher Beharrlichkeit angestrebt, 

obwohl die Verwendung in einer Diplomarbeit durch einen Studenten bekannt war. 

Abbildung 89: Ablauf der Demolizenz der Anwendung Speedtree (eigene Darstellung) 

Adobe ‐ Photoshop 

Das einzige Programm, welches ohne Ausnahme zuverlässig arbeitete, war die Bildbearbei‐ 

tung Adobe Photoshop CS 4, die an dieser Stelle positiv hervorgehoben werden soll. 

Microsoft Windows XP 

Das verwendete Betriebssystem Windows XP steht in der Allgemeinheit nicht im Verdacht, 

besonders zuverlässig zu sein. Es wird in dieser Liste aber nicht etwa wegen häufiger Sys‐ 

temabstürze aufgeführt, sondern wegen der Beschränkung der Größe des Arbeitsspeichers. 

Im Arbeitsprozess war es oft nötig, mehrere speicherintensive Anwendungen gleichzeitig zu 

benutzen und in ihnen sehr große Mengen an Daten zu bearbeiten. Im Nachhinein stellt die 

Wahl eines 32‐Bit‐Betriebssystems wie Windows XP einen Nachteil dar. Windows XP unters‐ 

tützt wie jedes 32‐Bit‐Betriebssystem insgesamt nur maximal 3,4 Gb an Arbeitsspeicher. 

Weiterhin wird einer Anwendung, selbst wenn es durch freien Speicher möglich wäre, in den 

seltensten Fällen die entsprechende Menge an Speicher zugeordnet. Stattdessen wird der 

Anwendung Speicher aus der wesentlich langsameren Auslagerungsdatei zugewiesen. Das 

Ergebnis sind Systemabstürze oder sehr lange Wartezeiten während der Bildschirmarbeit, da 

die Anwendung nur sehr langsam agiert. Es bleibt festzustellen, dass ein 64‐Bit‐ 

Betriebssystem für die Erstellung von 3D‐Stadtmodellen besser geeignet ist, da es bis zu 16 

Gb Arbeitsspeicher verwalten kann. Außerdem sollte bei der Auswahl des Betriebssystems 

auf eine intelligentere Speicherverwaltung geachtet werden.


Abbildung 90: Windows XP, Vergleich zwischen genutzter und reeller Größe des Arbeitsspeichers (eigene Darstellung) 

Die Probleme durch Softwarefehler sind aber nicht neu und wurden auch erwartet. Die 

Hauptproblematik liegt dabei eher darin, dass Anwender, die weniger versiert sind und sich 

mit den Programmen nicht eindringlich beschäftigt haben, keine Möglichkeit haben, um al‐ 

ternative Lösungswege für Softwarefehler zu finden. Als Beispiel sei der Export von x‐Files 

aus 3D Studio Max genannt, der bei Vorkommen von extrem kleinen Polygonen im Modell 

nicht mehr funktioniert. Er gibt eine Fehlermeldung aus und beendet die Anwendung. Nur 

das sehr aufwendige Entfernen dieser „Minipolygone“ behebt das Problem. Hier kommt das 

in Kap. 2.2.4 erwähnte Problem des notwendigen Spezialwissens zum Tragen, das für die 

Erstellung von 3D‐Stadtmodellen mit 3D‐Engine‐basierten Anwendungen erforderlich ist.


5.2 Entwicklung und offene Fragen 

Der Bereich der 3D‐Stadtmodelle entwickelt sich sehr schnell in teilweise sehr unterschiedli‐ 

che Richtungen. Der Erfolg dieses Instruments zur Visualisierung von 3D‐Inhalten in der Pla‐ 

nung ist zwar stellenweise gegeben, eine Prognose für die Zukunft ist aber sehr schwierig. 

Der Grund dafür liegt in der Tatsache, dass für viele Probleme und Fragestellungen noch kei‐ 

ne Lösung gefunden wurde. Im Folgenden sollen einige offene Fragen aus diesem Kontext 

aufgegriffen und erörtert werden. 

Frage 1: Kann es einen einheitlichen Workflow für die Erstellung geben? 

Aus Gründen der Vielfalt der Anwendungsfelder sowie Anforderungen von Seiten der unter‐ 

schiedlichen Adressaten kann diese Frage nach Ansicht des Autors nur mit einer Verneinung 

beantwortet werden. Ein weiteres Problem ist die verwirrende Vielfalt an vorhandenen 

Softwarelösungen und Datenformaten. Das dadurch entstandene Informationschaos bezüg‐ 

lich der 3D‐Stadtmodelle schadet der Branche und dem möglichen Einsatz von Stadtmodel‐ 

len insgesamt. Viele Hersteller von entsprechenden Anwendungen propagieren jeweils ihren 

eigenen Workflow sowie ihre Software und machen gleichzeitig die vorhandende Konkur‐ 

renz schlecht. Diese Strategie ist, wie schon gesagt, kontraproduktiv und verzögert den po‐ 

tenziellen Nutzen von 3D‐Stadtmodellen als Instrument der Planung. 

Gleichzeitig besteht unter den Planern ein starkes Informationsdefizit bzw. Informations‐ 

missverständnis. Viele Stadtplanungsämter kennen zwar die Thematik der 3D‐Stadtmodelle 

mittlerweile. Durch die Komplexität des Themas und die Informationspolitik der Software‐ 

hersteller fällt ihnen die Wahl eines möglichen Anwendungsfeldes oder einer möglichen 

Technik sehr schwer. Deshalb entscheiden sie sich oftmals gegen den Einsatz eines digitalen 

3D‐Stadtmodells. 

Abschließend bleibt zu sagen, dass es keinen einheitlichen Workflow oder eine Anzahl erfor‐ 

derlicher Softwareprodukte gibt, die die problemlose Erstellung eines 3D‐Stadtmodells ga‐ 

rantieren. An dieser Stelle soll auch die Frage nach einer „All in One“‐Softwarelösung beant‐ 

wortet werden. Es gibt keine Anwendung, die alle Schritte des Erstellungsprozesses durch‐ 

führen kann. Es wird also immer auf einen Software‐Mix, also den Einsatz mehrerer speziel‐ 

ler Anwendungen hinauslaufen, dessen mix‐interne Kompatibilität entscheidend für die Effi‐ 

zienz eines Erstellungs‐Workflows ist. Zwar versuchen Softwarehersteller, eine solche Infor‐ 

mationspolitik durchzusetzen, und bringen auch entsprechende Anwendungen auf den 

Markt, viele Arbeitsschritte müssen dabei aber dennoch in externe Anwendungen ausgela‐ 

gert werden. 

Frage 2: Kann die Erstellung von 3D‐Stadtmodellen automatisiert werden? 

Auch diese Frage wird vom Autor verneint. Es gibt zwar erfolgreiche Ansätze aus dem Be‐ 

reich der Softwarehersteller, Teile des Erstellungsprozesses zu automatisieren, die vollstän‐ 

dige Automatisierung wird aber auf absehbare Zeit nicht erreicht werden.


Die möglichen Automatisierungen beschränken sich momentan auf die Arbeitsschritte Geo‐ 

metrieerstellung (auch nur bis LOD 2) oder die Texturierung von Luftbildern. Diese Automa‐ 

tisierung ist aber nur als Dienstleistung verfügbar und nicht als käufliches Produkt [vgl. www. 

virtualcitysystems.de]. Der Grund dafür liegt im Monopolstatus der Hersteller dieser Anwen‐ 

dungen. 

Abbildung 91: Screenshot der Anwendung Building Reconstruction, automatisierte Geometrieerstellung aus Scandaten 

(virtualcitySystems GmbH, 2009) 

Ein weiterer Weg, auf dem teilautomatisiert 3D‐Stadtmodelle produziert werden können, 

hat GIS‐Anwendungen zur Grundlage. Einige GIS‐Anwendungen können aus ihrem Datenbe‐ 

stand per Export‐Funktion vollautomatisch Gebäudegeometrien im LOD 1 erstellen. 

Die Bildretusche hingegen ist ein Bereich, der nur sehr schwer zu automatisieren ist. Dazu 

wären für die herkömmliche Methode (eine Textur pro Fassade) hochkomplexe Algorithmen 

notwendig, um z. B. Gebäudekanten, Fenster oder Retuscheobjekte (Bäume, Autos etc.) ge‐ 

trennt zu erkennen. Zusätzlich zu dieser schwierigen intelligenten Erkennung müsste der 

Algorithmus auch noch die Entscheidung über die passende Retuschemethode treffen. Das 

bedeutet eine solche Anwendung müsste über ein großes Maß an künstlicher Intelligenz 

oder über extrem leistungsfähige Algorithmen verfügen. Diese existieren jedoch dem Wis‐ 

sensstand des Autors nach noch nicht. 

Ein LOD 3 Modell voll automatisiert aus Datengrundlagen heraus zu generieren, wird wie 

gesagt nach der Meinung des Autors in absehbarer Zeit nicht möglich sein. 

Frage 3: Werden sich 3D‐Stadtmodelle als Instrument der Planung durchsetzen? 

3D‐Stadtmodelle haben in vielen Kommunen Planungen begleitend visualisiert oder wurden 

als Plattform für Wettbewerbe [Quelle: Stadtplanungsamt Bamberg] und Öffentlichkeitsbe‐ 

teiligungen herangezogen. Welcher Trend sich daraus ableiten lässt, ist nicht abschließend


zu beantworten. Wichtig für den weiteren Einsatz dieser Modelle in der Planung ist aber die 

Entwicklung von neuen Funktionen und die Integration von neuen Technologien. 

Vor allem der CityGML‐Standard (siehe Glossar) stellt in diesem Zusammenhang einen wich‐ 

tigen Meilenstein einer zukünftigen Entwicklung dar. Dazu müssen zuverlässige Migrations‐ 

Workflows zwischen GIS‐Systemen und 3D‐Stadtmodellen entwickelt werden, um eine Ein‐ 

bindung dieses Standards in 3D‐Stadtmodelle sicherzustellen. Weiterhin muss sich die Bran‐ 

che weiter an innovativen Technologien aus anderen Zweigen der Visualisierungsbranche 

orientieren. Der Aufbau einer eigenen Technologie wäre erstens zu kostenintensiv, und 

zweitens kann das entsprechende Kow‐how von Planern nicht voraus gesetzt werden. Statt‐ 

dessen sollte die Richtung verfolgt werden, in der zuverlässige Technologien von anderen 

Wissenschaften adaptiert werden. Die Unterhaltungsindustrie war in der Vergangenheit 

Ideengeber und Know‐how‐Quelle und wird auch in Zukunft diese Position innebehalten. 

Abbildung 92: 3D‐Stadtmodell der Stadt Heidelberg basierend auf CityGML (Universität Bonn, 2009) 

Ein Trend, der sich beobachten lässt, ist die Verlagerung von Verwaltungsdienstleistungen in 

das Internet, im Sinne von E‐Government (elektronische Verwaltung, siehe Glossar). Wenn 

3D‐Stadtmodelle ein Partizipationswerkzeug in der Planung sein sollen, müssen auch sie 

internetfähig sein. Google Earth ist nach EXNER [2009] ein praktikables Instrument in diesem 

Zusammenhang. Die technischen Hürden sind bei dieser Zielsetzung aber gegeben und kön‐ 

nen teilweise nur durch neue Technologien überwunden werden. Vor allem die Darstellung 

von 3D‐Stadtmodellen mit hohem LOD stellt im Internet ein großes Problem dar.


Eine weitere Anforderung für die 3D‐Stadtmodelle der Zukunft wird schon von ZEILE [2004] 

postuliert: Die Anbindung von Datenbanken an 3D‐Stadtmodelle und die Ablage von 3D‐ 

Informationen in einer Datenbank. Während ersteres mittlerweile möglich ist, z. B. in 

Quest3D, ist die Ablage von texturierten 3D‐Geometrien in einer Datenbank ein ungelöstes 

Problem. Die Anwendung Quest3D stellt in diesem Zusammenhang zwar Ansätze einer sol‐ 

chen Technologie zur Verfügung, ist aber als flächendeckende Lösung auf Grund von Kompa‐ 

tibilitätsproblemen mit den eingesetzten Datenbanken, z. B. bei den Kommunen, nicht prak‐ 

tikabel. 

Ein Lösungsansatz könnte die Verknüpfung des erwähnten CityGML‐Standards mit 3D‐ 

Stadtmodellen sein, da CityGML mit Datenbanken und GIS‐Systemen kompatibel ist. Fraglich 

ist aber, wann sich der Standard in der Fläche durchsetzen wird, denn Standard ist er schon 

seit August 2008 [www.citygml.org]. 

Frage 4: Welche Neuerungen sind in Zukunft zu erwarten? 

Neuerung 1: 

Durch die starke Beschleunigung bei der Entwicklung neuer Technologien im Hardwarebe‐ 

reich sowie durch den starken Preisverfall auf dem Hardwaremarkt wird in der Zukunft der 

LOD von 3D‐Stadtmodellen nicht zwangläufig auch die Qualität erhöhen. Immer leistungsfä‐ 

higere Computer ermöglichen immer komplexere Modelle. In diesem Zusammenhang bleibt 

die Frage nach einer selbst gesetzten oder technischen Grenze im Bezug auf die LOD‐ 

Thematik. 

Abbildung 93: Entwicklung der Transistorenzahlen bei Grafikkarten (PCGames Hardware, 2009)


Neuerung 2: 

Es wird erwartet, dass eine zweite Neuerung im Bereich der Verlagerung von 3D‐Inhalten auf 

das Internet und in den Bereich der „Mobile Devices“ stattfinden wird. EXNER [2009] nimmt 

in diesem Zusammenhang Bezug auf die Entwicklungen im Bereich der Unterhaltungsindust‐ 

rie. Anwendungen wie „Second Life“ bilden die Realität mit einem hohen Detaillierungsgrad 

im Internet ab [www.berlinin3D.de]. Interaktion und Kommunikation in generierten Paral‐ 

lelwelten sind erwünscht und möglich. Dass es für solche Parallelwelten einen Markt gibt, 

zeigt sich vor allem die rege Nachfrage nach solchen Anwendungen und Inhalten. 

Diese Entwicklung einer stärkeren Nutzung des Internets wird durch den stetigen Ausbau 

von Kommunikationsinfrastruktur begünstigt. Mittlerweile sind in Deutschland Downstream‐ 

Geschwindigkeiten von bis zu 50 Mbit möglich. Dadurch ist der Transfer von wesentlich grö‐ 

ßeren Datenmengen möglich. [www.heise.de] 

Auch die Entwicklung der Virtual Globes wie Google Earth ist noch nicht abgeschlossen und 

wird durch immer neue Funktionen erweitert. [www.google.com] Weiterhin ist auch die 

Migration der Anwendungen von Personal Computern auf sog. „Mobile Devices“ (engl. 

Fachwort: mobile Geräte) schon jetzt spürbar. Die Generation der Smartphones (Mobiltele‐ 

fone mit stark erweitertem Funktionsumfang) erschließt den Handymarkt in rasantem Tem‐ 

po [www.apfelnews.de] und ermöglicht immer neue Anwendungen, bei denen der Nutzer 

Informationen ortsunabhängig abrufen kann oder zu einer Interaktion zwischen virtueller 

und realer Welt befähigt wird. Das beste Beispiel ist die Vielzahl an Anwendungen, die für 

das Smartphone Apple Iphone 3G verfügbar sind. Mittlerweile ist auch der Einsatz der An‐ 

wendung Google Earth oder Second Life auf dem Iphone möglich [vgl. www.heise.de und 

www.techdigest.tv]. 

Abbildung 94: Smartphone „Apple Iphone“ mit der Anwendung Google Earth (Pierre Markuse, 2009, und eigene Re‐ 

tusche)

5.3 Zusammenfassung 


Das Ziel dieser Arbeit war die Erstellung eines digitalen historischen 3D‐Stadtmodells sowie 

eine Auseinandersetzung mit dem Thema der Visualisierung von historischen 3D‐Daten. Die‐ 

se Ziele wurden erreicht. 3D‐Stadtmodelle zeigen auch bei der Darstellung von historischen 

Daten ihre Vorteile. Die erwähnten Vorteile dabei sind die Anschaulichkeit und die effektive 

Zusammenführung komplexer Daten. Ihr Nutzen für die Planung lässt sich nur schwer vor‐ 

hersagen, sollte aber nicht unterschätzt werden. Dies soll anhand der Entwicklung der 3D‐ 

Stadtmodelle insgesamt verdeutlicht werden. Im Rahmen einer abschließenden Betrachtung 

soll aber auch noch einmal kritisch auf die Probleme der 3D‐Stadtmodelle eingegangen wer‐ 

den. 

Probleme 

Aufgrund der fehlenden Beispiele, z. B. in Deutschland, lässt sich eine Evaluation ihres tat‐ 

sächlichen Nutzens durch empirische Methoden kaum realisieren. Echte interaktive 3D‐ 

Stadtmodelle existieren seit knapp 10 Jahren. Sie waren anfänglich von einem ähnlichen Hy‐ 

pe umgeben wie z. B. Google Earth. Doch versiegte dieser auf Grund der geringen Verbrei‐ 

tung. 3D‐Stadtmodelle sind ab einem bestimmten LOD (etwa LOD 2) relativ teuer in ihrer 

Erstellung, und die Anschaffung der notwendigen Software ist ebenfalls sehr kostenintensiv. 

Da die Kommunen parallel über unzureichende Mittel verfügen und teilweise große Haus‐ 

haltslöcher zu stopfen haben, sind 3D‐Stadtmodelle bei weitem nicht so bekannt wie Google 

Earth. Ein weiterer Grund für ihre geringe Verbreitung stellt ihr Anwendungsfeld dar. Sie 

werden in Wettbewerben als Variantensimulation oder zur Präsentation von Großprojekten 

eingesetzt. Dabei geht es fast immer um die Visualisierung empfindlicher Daten, die vorerst 

nicht für die Öffentlichkeit bestimmt sind, sondern nur für den kleinen Kreis der Entschei‐ 

dungsträger. Hier liegt nach der Meinung des Autors ein Kernproblem bei der Verbreitung 

von Stadtmodellen. 

These 1: Da das Ergebnis einer Planung entweder zu unpopulär oder für die Öffentlichkeit zu 

unbedeutend ist, wird der Einsatz eines 3D‐Stadtmodells in der Öffentlichkeit oft vermieden. 

Ein solches Modell sollte ja nur populäre Ergebnisse kommunizieren. 

Von Zeit zu Zeit kommen in der Presse Berichte über die Existenz von 3D‐Stadtmodellen (z. 

B. Hamburg, Berlin oder München) vor. Der Nutzen und der Zweck dieser Modelle wird der 

Öffentlichkeit aber nur unzureichend kommuniziert. Teilweise werden diese sogar von der 

Presse als Spielerei abgetan: „Derzeit ist das Internet‐Rom also eher eine Spielerei, eine Art 

ruckelnde interaktive Landkarte.“ (Kommentar der Fachzeitschrift Spiegel zum Rome‐ 

Reborn‐Projekt [www.spiegel.de]) Das Ergebnis ist ein geringes Interesse der Öffentlichkeit 

an solchen Modellen. 

These 2: Ein geringes Interesse der Öffentlichkeit an 3D‐Stadtmodellen wird auch dadurch 

erzeugt, dass Planung insgesamt und der Planungsalltag insbesondere, kein großes Interesse 

in der Öffentlichkeit genießen.


Aus den vorhergehenden Gedankengängen sind mehrere mögliche Gründe für die Probleme 

der 3D‐Stadtmodelle festzustellen: 

1. 3D‐Stadtmodelle sind meist einem exklusiven Publikum vorbehalten und werden nur 

zögerlich in der Öffentlichkeit eingesetzt (Gegenbeispiel: z. B. Weltkulturerbelauf 

Bamberg [www.stadtplanungsamt‐bamberg.de]) 

2. 3D‐Stadtmodelle, speziell ihr Nutzen, besitzen vor allem in der Öffentlichkeit ein star‐ 

kes Informations‐ und Kommunikationsdefizit 

3. es gibt zu wenige Best‐Practices, die den Nutzen von 3D‐Stadtmodellen effektiv 

kommunizieren 

4. 3D‐Stadtmodelle sind mit Vorurteilen behaftet 

5. 3D‐Stadtmodelle genießen ein geringes öffentliches Interesse 

Aus genannten Gründen haftet 3D‐Stadtmodellen immer noch der Beigeschmack des Exoti‐ 

schen an. In diesem Zusammenhang wäre eine empirische Untersuchung über den Kenntnis‐ 

stand bezüglich der 3D‐Stadtmodelle in entsprechenden Ämtern hilfreich. 

Nutzen 

3D‐Stadtmodelle sind Computersimulationen im Rahmen der Methoden der Stadtplanung. 

Dabei findet eine modellhafte Abbildung der Realität in einem Computersystem statt. Die 

Aufgabe solcher Simulationen besteht in der Auffindung von Gesetzmäßigkeiten in der Reali‐ 

tät oder darin, in experimentellen Studien neue Ideen für eine Umsetzung in der Realität zu 

erzeugen. [STREICH, 2005] 

Aus dieser Definition lassen sich erneut die Anwendungsmöglichkeiten von 3D‐ 

Stadtmodellen ableiten. Diese sind nach KIRMSE [2006] zahlreich, können aber nur schwer 

mit Beispielen belegt werden. Die vorliegende Arbeit kann in diesem Zusammenhang als 

Beispiel dienen und den Mehrwert von digitalen historischen 3D‐Stadtmodellen aufzeigen. 

Auch bei der Visualisierung von historischen Daten wird es darauf ankommen, wie dieses 

Instrument von der Planung angenommen wird und wie es kommuniziert wird. 

Das erstellte historische 3D‐Stadtmodell Kaiserslautern zeigt, dass die Erstellung eines sol‐ 

chen möglich ist und dass es einen großen potenziellen Mehrwert für die Planung und die 

Allgemeinheit besitzt. EXNER [2009] stellt treffend fest, dass die technische Entwicklung, die 

sich momentan vollzieht, beste Voraussetzungen bietet, um das Instrument der 3D‐ 

Stadtmodelle weiter in Planungsprozesse zu integrieren. Im Sinne einer Optimierung der 

Planung und damit einer optimierten Erreichung der Ziele der Planung sollte diese Integrati‐ 

on nicht aus Kostengründen verzögert werden. Um genannte Kosten gering zu halten, ist 

eine Weiterbildung der Planer mit Ausrichtung auf CAD‐Kenntnisse und die Anwendungs‐ 

möglichkeiten neuer Technologien notwendig. 

Die Planung hat sich aber in der Vergangenheit nicht sehr Kontaktfreudig gegenüber neuen 

Technologien gezeigt. Vor allem in den 1980er Jahren beschränkte sich die Nutzung neuer


computergestützter Technologien durch die städtebauliche Planung auf die der Dienstleis‐ 

tung von anderen Fachdisziplinen (Vermessung, Verkehr etc.). Man versäumte die aktive 

Mitgestaltung bei der Erstellung neuer Datenformate oder Fachinformationssysteme. Man 

sah in computergestützter Planung lediglich eine effiziente Methode der Informationsge‐ 

winnung [vgl. STREICH, 1997] 

Diese Haltung sollte nicht wieder eingenommen werden. Stattdessen sollte versucht wer‐ 

den, neue Entwicklungen im Hinblick auf computergestützte Planung so aktiv und so zeitnah 

wie möglich umzusetzen, um weiterhin eine kontinuierliche Optimierung der Planung zu 

gewährleisten. Es darf nicht vergessen werden, dass eine Optimierung von Planung immer 

dem Wohl der Allgemeinheit und der Verbesserung der allgemeinen Wohn‐ und Arbeitsver‐ 

hältnisse der gesamten Bevölkerung dient.

114 6. Anhang 

6. Anhang 

6.1 Glossar 

2D zweidimensional 

3D dreidimensional 

3DS Abkürzung für: „3D‐Studio‐Mesh“, Datenformat der Anwendung 3D 

Studio Max (Autodesk) 

airborne luftgestützt, z.B. airborne Laserscanning meint Laserscanning von ei‐ 

nem Flugzeug aus 

Algorithmus genau definierte Handlungsvorschrift zur Lösung von Problemen in 

endlich vielen Schritten 

All‐in‐One Alles in Einem 

Animation Sequenz von Einzelbildern die ähnlich einem Film eine Bewegung dar‐ 

stellen 

AutoCAD CAD Anwendung der Firma Autodesk 

Best Practice englisch für: beste Übung; meint die Bewertung eines Projekts als vor‐ 

bildlich 

Billboard rechteckige Geometrie aus zwei Polygonen mit einer teiltransparenten 

Textur; z.B. als Ersatz für polygonreiche Geometrien 

CAD Computer‐Aided‐Design, meint die Erstellung von Zeichnungen oder 

Plänen mit Unterstützung des Computers 

CG‐Artist englische Abkürzung für: Computer Graphics Artist, meint einen Beruf 

bei dem computergestützt Darstellungen erstellt werden 

Channelgroup Datenformat der Anwendung Quest3D (Act3D) 

CityGML City Geography Markup Language; Standard zur Speicherung und zum 

Austausch von virtuellen 3D‐Stadtmodellen 

coplanar coplanare Fläche meint eine Fläche, bei der alle Punkte in einer Ebene 

liegen 

DGM Digitales Geländemodell; meint ein Netz aus Polygonen, das die Ober‐ 

fläche des Geländes abbildet 

digital Szene aus dem Computerspiel GTA 4 

DirectX Grafikschnittstelle von Microsoft, diese ist eine Programiersprache zur 

Steuerung von Grafikkarten 

DOM digitales Oberflächenmodell, meint ein Netz aus Polygonen, das die 

Oberfläche des Geländes und der Gebäude abbildet 

DWG englische Abkürzung für: Drawing = Zeichnung; Datenformat der Firma 

Autodesk 

DXF englische Abkürzung für: Data Exchange Format; Datenformat der 

Firma Autodesk 

E‐Government Elektronische Verwaltung; meint z.B. die Verlagerung von Verwal‐ 

tungsdienstleistungen ins Internet 

Engine‐basiert Anwendung mit einer integrierten Grafikengine 

Error englisch für: Fehler; meint oft einen Anwendungsfehler oder den Ab‐ 

sturz eines Computersystems 

Executable Ausführungsdatei, im Computerjargon eine ausführbare Datei 

FPS englisch für: frames per second, Einzelbilder pro Sekunde; ist eine Ein‐ 

heit zur Messung von Darstellungsgeschwindigkeit bei Anwendungen

6. Anhang 115 

Game Engine auch Grafikengine, koordiniert den Datenaustausch zwischen Anwen‐ 

dung und Grafikhardware (siehe Seite 22) 

Gb Gigabyte, 1Gb=1024 Mb 

Geo Prefix für Begriffe aus Bereichen mit Bezug zur Vermessung oder mit 

allgemeinem Raumbezug, z.B. Geodaten meint geographische Daten 

GIS Geografisches Informationssystem 

Grafikspeicher Speicher der Grafikkarte eines Computers 

GTA Abkürzung für: Grand Theft Auto (Computerspiel, siehe Seite 20) 

GUI Graphics User Interface, englisch für: Benutzeroberfläche einer Anwe‐ 

nung 

ISO‐Standard Standard der International Standardisation Organisation, einer Institu‐ 

tion zur Schaffung internationaler Standards 

Kachelung Wiederholung von Texturen auf einer Geomtrie durch Nebeneinander‐ 

setzen oder Spiegeln der Originaltextur 

Kubatur Gebäudekörper/Gebäudegeometrie 

Laserscanning Scanverfahren bei dem mit einem Laser gemessen wird; meint die 

Abtastung eines Objekts mit einem Laser 

Layer englisch für: Ebene 

Lightmap in eine Bilddatei gespeichterte Daten über den Schattenwurf eines 3D‐ 

Objekts 

Lightmapping Verfahren zur Erstellung von Lightmaps 

LOD Level of Detail, englisch für: Detaillierungsgrad 

Mb Megabyte, 1024 Kilobyte oder 1024 mal 1024 Byte 

MBit Einheit der Übertragungsgeschwindigkeit von Daten in einem Compu‐ 

ternetzwerk; 1MBit entspricht etwa 125 Kilobyte pro Sekunde 

Metadaten Daten, die Informationen über andere Daten enthalten 

Metatag HTML‐Element, das Metadaten über ein Dokument bereithält 

Mip‐Map Bilddatei mit einer integrierten Abstufung der Detaillierung abhängig 

von der Entfernung zum Betrachter 

Mip‐Mapping Verfahren zur Erstellung von MIP‐Maps 

mobile device englisch für: mobiles Gerät 

MRT Abkürzung für: Magnetresonanztomografie; medizinisches Verfahren 

zur Durchleuchtung eines Körpers 

Normal‐Mapping Bilddatei mit integrierter Höheninformation für 3D‐Geometrien 

OpenGL Open Graphics Library, plattform‐ und programmierunabhängige Gra‐ 

fikschnittstelle zur Darstellung von 2D‐ und 3D‐Inhalten 

ÖPNV Abkürzung für: Öffentlicher Personennahverkehr; Fachjargon im Be‐ 

reich der Raumplanung 

Overlay englisch für: Überlagerung; meint eine Bildüberlagerung in Google 

Earth 

Photomatch Unterprogramm der Anwendung Google Sketchup zur Erstellung von 

Geometrien aus Bilddaten

116 6. Anhang 

Pixel Computerjargon für: Bildpunkt, bei Rasterdaten oder Computerbild‐ 

schirmen 

Polygon griechisch/englisch für Vieleck, im Computerjargon ist meist ein 

Dreieck gemeint 

Pop‐Up Computerjargon für: das Erscheinen eines Objekts auf dem Bildschirm, 

z.B. bei Fenstern in einem Internet 

post processing englisch für: Nachbearbeitungsprozess; meint die Bearbeitung von 

Daten nach dem Prozess der Datenerhebung 

PS3 Abkürzung für Sony Playstation 3 (Spielekonsole) 

realtime englisch für: in Echtzeit 

Render to Texture Verfahren zur Erstellung von Texturen aus einer 3D‐Szene heraus, z.B. 

die Berechnung und das Speichern von Schatten in eine Bilddatei 

rendern Generierung von Bildern oder Bildsequenzen aus 2D‐ oder 3D‐ 

Modellen durch Berechnung ihres Aussehens 

Retusche Verändern von Bildern mit Hilfe von Bildbearbeitungssoftware 

Rome Reborn englisch für: wiedergeborenes Rom, Projekt bei dem ein Modell des 

antiken Roms erstellt wurde 

SIG3D Special Interest Group 3D; Arbeitsgemeinschaft, die sich mit 3D‐Stadt‐ 

und Regionalmodellen auseinandersetzt 

Stand‐Alone englisch für: alleine stehen, meint das Gegenteil von vernetzt im Zu‐ 

sammenhang mit Computern 

Steep‐Paralax‐Mapping Verfahren zur Anzeige von Tiefeninformationen auf ebenen Geomet‐ 

rien mit Hilf von Texturen, ähnelt dem Normal‐Mapping 

Verfahren zur Vermessung von Objekten durch die parallele Ansicht 

Stereoskopie 

von zwei Bildern; meint meist die Auswertung von überlappenden 

Luftbildern oder anderen Fotos zur Erstellung von Geometrien 

stitchen englisch für: zusammennähen, meint im Computerjargon das über‐ 

gangslose Zusammenfügen von überlappenden Bildern 

terestrisch erdgebunden, z.B. terestrischer Laserscanner meint einen erdgebun‐ 

denen Laserscanner 

Textur Bilddatei, die auf eine Geometrie gelegt wird 

Texturierung Verfahren zur Belegung von Geometrien mit Bilddaten 

Theodolit Instrument zur Winkelmessung in den Vermessungswissenschaften 

Variantenmodell 3D‐Stadtmodell, das verschiedene Varianten einer Szene darstellen 

kann 

Versionierung Speichern von Dateien mit verschiedenen Versionsnummern 

Virtual Globe englisch für: virtueller Globus, z. B. Google Earth 

VRML englisch für: Virual Reality Modelling Language, Beschreibungssprache 

zur Darstellung von 3D‐Szenen im Internet 

Web‐Map‐Services eine Schnittstelle zum Abrufen von Auszügen von Landkarten im Inter‐ 

net 

Workflow englisch für: Arbeitsablauf oder Arbeitsprozess 

X3D Screenshots der Anwendung werden auf dem Desktop abgelegt 

x‐File Datenformat der Grafikschnittstelle Mircosoft DirectX, kann Geomet‐ 

rie‐ und Texturkoordinaten speichern 

Xfrog Gebilde aus zwei Billboards, die über Kreuz stehen

6.2 Abbildungsverzeichnis 

6. Anhang 117 

Abbildung 1 : 3D‐Stadtmodell Bamberg in der Anwendung Quest3D 7 

Abbildung 2 : 3D‐Modell eines Mäuseherzen 8 

Abbildung 3 : LOD‐0‐Modell am Beispiel des DGM Kaiserslautern 9 

Abbildung 4 : Beispiel für ein LOD‐1‐Modell 9 

Abbildung 5 : LOD‐2‐Modell der Universität Kaiserslautern in Google Earth 10 

Abbildung 6 : LOD‐3‐Modell der Stadt Bamberg in Google Earth 11 

Abbildung 7 : LOD‐4‐Modell der Stadt Kaiserslautern 12 

Abbildung 8 : Beispiel für ein Quicktime VR 13 

Abbildung 9 : Screenshot der Anwendung Photosynth 14 

Abbildung 10 : Screenshot der Anwendung Google Earth 15 

Abbildung 11 : Screenshot der Anwendung NASA World Wind 16 

Abbildung 12 : Screenshot der Anwendung Microsoft Virtual Earth 17 

Abbildung 13 : VRML‐Modell der Stadt Philadelphia 18 

Abbildung 14 : Szene aus dem Computerspiel GTA 3 20 

Abbildung 15 : Szene aus dem Computerspiel GTA 4 21 

Abbildung 16 : Screenshot des Editors der Unreal‐2‐Engine 22 

Abbildung 17 : Screenshot des 3D‐Stadtmodells Bamberg in der Irrlicht‐Engine 23 

Abbildung 18 : 3D‐Stadtmodell im Cypercity‐Modeller 24 

Abbildung 19 : 3D‐Stadtmodell in der Anwendung Terrain View 25 

Abbildung 20 : Screenshot des 3D‐Stadtmodells Bamberg 26 

Abbildung 21 : interaktives 3D‐Stadtmodell der Stadt Sindelfingen 27 

Abbildung 22 : Visualisierung des Einzelhandelsgroßprojekts in der Anwendung Quest3d 28 

Abbildung 23 : Beispiel für ein Architekurmodell 30 

Abbildung 24 : Beispiel für ein Stadtmodell 31 

Abbildung 25 : Modell der Kaiserpfalz Ingelheim 32 

Abbildung 26 : Modell des Casimirschlosses im Theodor‐Zink‐Museum in Kaiserslauern 32 

Abbildung 27 : Modell der Stadt Kaiserslautern um 1623 33 

Abbildung 28 : gerendertes Bild der Rekonstruktion der „Aula regia“ in Ingelheim 34 

Abbildung 29 : DVD‐Cover und Filmszene 35 

Abbildung 30 : Anwendung Google Earth mit Inhalten von „Rome Reborn“ 36 

Abbildung 31 : Screenshot der 3D‐Visualisierung der Burg Inuyama 37 

Abbildung 32 : Screenshot der 3D‐Visualisireung der Inkastadt Machu Picchu 38 

Abbildung 33 : Zeitungsartikel aus der Rheinpfalz 43 

Abbildung 34 : Zeichnung mit Wohnspeicherhäusern 45 

Abbildung 35 : Handzeichnung von Franz Joseph Kisling aus dem Jahr 1764 46 

Abbildung 36 : Kupferstich der Kaiserslautern im Jahr 1620 zeigt 48 

Abbildung 37 : Schloß und Kaiserpfalz um 1706 48 

Abbildung 38 : Grundrissplan der Burg mit Schloss von 1713 49 

Abbildung 39 : Centralgefängnis auf einer Darstellung von 1830 50 

Abbildung 40 : Darstellung der Fruchthalle um 1875 52 

Abbildung 41 : Ausschnitt des Bindewaldplans von 1889 52 

Abbildung 42 : Luftbild von einem Luftschiff aus aufgenommen (um 1914) 54 

Abbildung 43 : Front des Casimirsaal um 1937 55 

Abbildung 44 : Denkmal an der Fruchthalle kurz nach dem Kriegsende 1945 56

118 6. Anhang 

Abbildung 45 : Luftbild des Stadtkerns von Kaiserslauten, 2008 58 

Abbildung 46 : Ausschnitt Bindewaldplan von 1889 60 

Abbildung 47 : Untersuchungsraum für die Bestandsaufnahme 61 

Abbildung 48 : Screenshot des digitalen Katasters von Kaiserslautern in AutoCAD 62 

Abbildung 49 : GIS‐Daten in 3D Studio Max 62 

Abbildung 50 : altes 3D‐Stadtmodell von Kaiserslautern in 3D Studio Max 63 

Abbildung 51 : Screenshot des DGM in 3D Studio Max 63 

Abbildung 52 : aktuelles Luftbild der Stadt Kaiserslautern 64 

Abbildung 53 : Plan von Kaiserslautern aus dem Jahr 1823 (Etienneplan) 65 

Abbildung 54 : historisches Foto des Fackelrondells (1909) 65 

Abbildung 55 : Ansicht des Casimirschlosses und der Kaiserpfalz von 1740 66 

Abbildung 56 : Graph HLOD 68 

Abbildung 57 : Screenshot mit den Rohdaten der Kaiserpfalz in 3D Studio Max 70 

Abbildung 58 : Screenshot mit einer Detailaufnahme der Rohdaten der Kaiserpfalz 70 

Abbildung 59 : Anwendung Architectural Space 72 

Abbildung 60 : Photomatch in Sketchup 7 73 

Abbildung 61 : Vergleich zwischen Realität, DGM, und finalem Modell 74 

Abbildung 62 : Anwendung Mousemeter zur Analyse der Mausaktivität 75 

Abbildung 63 : Bildentzerrung in Photoshop 76 

Abbildung 64 : Methodenvergleich 77 

Abbildung 65 : Prinzip der Kachelung von Texturen 78 

Abbildung 66 : Texturierung der Geometrien in 3D Studio Max 79 

Abbildung 67 : Vergleich Vegetation 81 

Abbildung 68 : Anwendung Speedtree mit einem Baum 82 

Abbildung 69 : Lightmap‐Vergleich 83 

Abbildung 70 : Anwendung Quest3D 84 

Abbildung 71 : DDS‐Converter 84 

Abbildung 72 : Infoscreen der Anwendung 85 

Abbildung 73 : Screenshot der Anwendung mit eingeschaltetem GUI 86 

Abbildung 74 : Screenshot der Anwendung mit ausgeblendetem GUI 87 

Abbildung 75 : Screenshot der Anwendung, Darstellung von Kollisionsobjekten 88 

Abbildung 76 : Screenshots der Anwendung werden auf dem Desktop abgelegt 89 

Abbildung 77 : Infopunkte in der Anwendung 90 

Abbildung 78 : Darstellung von Metadaten im Infopop‐up 90 

Abbildung 79 : Gegenwartsmodell mit eingeblendetem Modell der Kaiserpfalz 91 

Abbildung 80 : Zeitstrahl zum Wechseln der angezeigten Zeit 91 

Abbildung 81 : Anwendung Quest, Eingabefenster für Metadaten 92 

Abbildung 82 : Anwendung Quest3D, Publish‐Funktion 93 

Abbildung 83 : Beispiel für ein Terminal des Touristeninformationssystems 96 

Abbildung 84 : Raster der Teilstücke des Stadtmodells von Bamberg 97 

Abbildung 85 : Beispiel für das Motiv und das „Beiwerk“ eines Bildes 99 

Abbildung 86 : Fangfehler in Sketchup bei sehr kleinen Punktabständen 100 

Abbildung 87 : Autosave‐Funktion in 3D Studio Max 101 

Abbildung 88 : Anwendung Quest3D, Publish‐Error 102 

Abbildung 89 : Ablauf der Demolizenz der Anwendung Speedtree 103 

Abbildung 90 : Windows XP 104

6. Anhang 119 

Abbildung 91 : Screenshot der Anwendung Building Reconstruction 106 

Abbildung 92 : 3D‐Stadtmodell der Stadt Heidelberg basierend auf CityGML 107 

Abbildung 93 : Entwicklung der Transistorenzahlen bei Grafikkarten 108 

Abbildung 94 : Smartphone „Apple Iphone“ mit der Anwendung Google Earth 109 

Diagramm 1 : Aufbau der Arbeit 5 

Diagramm 2 : Arbeitsablauf 44

120 6. Anhang 

6.3 Literaturverzeichnis 

A 

ArchimediX ‐ Möckl, Munzel GbR , http://www.archimedix.com: i_final01_gr.jpg, auf 

http://www.archimedix.com/ingelheim/images/i_final01_gr.jpg, aufgerufen am 7.09.09 

Autodesk Inc., www.autodesk.de: Neue Funktionen 3D Max 2010, auf 

http://www.autodesk.de/adsk/servlet/index?siteID=403786&id=12353717, aufgerufen 

7.09.09 

B 

Baugesetzbuch: Baugesetzbuch, Deutscher Taschenbuchverlag, München, 2006 

C 

Canadian Broadcasting Corporation: The invisible middleman of the game‐industry, auf 

http://www.cbc.ca/news/background/tech/tech‐games‐middleman.html, aufgerufen am 

7.09.09 

COMPUTEC MEDIA AG, http://www.pcgameshardware.de: PCGH History: Entwicklung der 

Transistoranzahl, auf http://www.pcgameshardware.de/aid,627809/PCGH‐Rueckblick‐ 

Entwicklung‐der‐3D‐Grafik‐Teil‐1/Grafikkarte/Wissen/bildergalerie/?iid=758568, aufgerufen 

am 7.09.09 

CPA Systems GmbH, www.supportgis.de: supportgis 3d Technologie, auf 

http://www.supportgis.de/Dip2/SupportGIS/3D/SupportGIS‐3D.pdf, aufgerufen am 7.09.09 

D 

DATACOM Buchverlag GmbH ‐ IT‐Lexikon: Begriff Rendering, auf 

http://www.itwissen.info/definition/lexikon/Rendering‐rendering.html, aufgerufen am 

7.09.09 

E 

EARSeL , http://www.earsel.org :Poster2_Ulm.pdf, auf 

http://www.earsel.org/workshops/SIG‐URS‐2006/PDF/Poster2_Ulm.pdf, aufgerufen am 

7.09.09 

Exner J.: Planen im Geoweb ‐ Partizipation und Akzeptanzsteigerung durch Projektvisualisie‐ 

rung am Beispiel des Kaohsiung Advanced Intelligent Science Parks, Kaiserslautern, 2009 

F

Fee James, www.spatiallyadjusted.com: thestrip.jpg, auf 

http://www.spatiallyadjusted.com/wp‐content/uploads/2006/11/thestrip.jpg, aufgerufen 

am 7.09.09 

Forschungsstelle Kaiserpfalz Ingelheim ‐ Holger Grewe, www.kaiserpfalz‐ingelheim.de: 

Kaiserpfalz Ingelheim, auf http://www.kaiserpfalz‐ingelheim.de, aufgerufen am 7.09.09 

6. Anhang 121 

Friedel H.: Kaiserslautern – Von den Anfängen bis zur Reichsgründung, Geschwister Schmidt 

Verlag, Kaiserlautern, 1995 

und Kaiserslautern – Von der Kaiserzeit bis zur Universitätsgründung, Geschwister Schmidt 

Verlag, Kaiserslautern, 1998 

Frischer B., University of Virginia, www.romereborn.virginia.edu: Rome Reborn, auf 

http://www.romereborn.virginia.edu/, aufgerufen am 7.09.09 

G 

Geographisches Institut der Universität Bonn, http://www.giub.uni‐bonn.de: 

Schloss_Heidelberg‐3D_5.jpg, auf http://www.giub.uni‐bonn.de/karto/heidelberg‐ 

3d/screenshots/ScreensNeu/Schloss/Schloss_Heidelberg‐3D_5.jpg, aufgerufen am 7.09.09 

GeoSim Systems Ltd, http://www.geosim.co.il: image_Municipalities_03_big.jpg, auf 

http://www.geosim.co.il/images/Solutons/image_Municipalities_03_big.jpg, aufgerufen am 

7.09.09 

Google Inc.: Fallstudie Dafur Krise, auf 

http://earth.google.de/outreach/cs_darfur.html, aufgerufen am 7.09.09 

und KML Reference, auf http://code.google.com/intl/de‐ 

DE/apis/kml/documentation/kmlreference.html#model, aufgerufen am 7.09.09 

und 5723987.jpg, auf 

http://static.panoramio.com/photos/original/5723987.jpg, aufgerufen am 7.09.09 

Gorus Rafael, www.gtavision.com: Vergleich GTA4 und NewYork, auf 

http://www.gtavision.com/index.php?section=content&site=112, aufgerufen am 7.09.09 

H 

H² media factory GmbH, www.netzwelt.de: Keine Open‐Source‐Alternative zu Google Earth, 

auf http://www.netzwelt.de/news/74903‐keine‐open‐source‐alternative‐google‐earth.html, 

aufgerufen am 7.09.09

122 6. Anhang 

Heise Zeitschriften Verlag GmbH & Co. KG, www.heise.de: Google Earth fürs iPhone, auf 

http://www.heise.de/newsticker/Google‐Earth‐fuers‐iPhone‐‐/meldung/117986, aufgerufen 

am 7.09.09 

und Telekom‐VDSL mit Datendrossel für Powersauger, auf 

http://www.heise.de/newsticker/Telekom‐VDSL‐mit‐Datendrossel‐fuer‐Powersauger‐‐ 

/meldung/144991, aufgerufen am 8.09.09 

Höffken S.: Google Earth in der Stadtplanung ‐ Die Anwendungsmöglichkeiten von Virtual 

Globes in der Stadtplanung am Beispiel von Google Earth – eine Standortbestimmung, Berlin, 

2007 

Huß A., www.maxani.de: Telefonat vom 2.09.09 

I 

ID‐Software Inc.,www.modewiki.net: Erklärung dds‐Format, auf 

http://www.modwiki.net/wiki/DDS_%28file_format%29 , aufgerufen am 7.09.09 

K 

Kawata Masaaki, www.kawatan.net: Photosynth.jpg, auf 

http://www.kawatan.net/archives/Photosynth.jpg, aufgerufen am 7.09.09 

Kirmse J.: 3D to be – Anwendungsfelder und Integrationsmöglichkeiten von Virtuellen 3D – 

Stadtmodellen, Kaiserslautern, 2006 

Kolbe T., www.citygml.org: What is CityGML?, auf 

http://www.citygml.org/1523/, aufgerufen am 7.09.09 

Kornev Pavel: Quest3D_Demo_MachuPicchu.exe, auf 

http://download.quest3d.com/Demos/Quest3D_Demo_MachuPicchu.exe, aufgerufen am 

7.09.09 

Krause K.J.: Grundsätze der Gestaltplanung von Großstädten. Dargestellt am Beispiel der 

Innenstadt Frankfurt/M. in Hellmut Schroeder – Lanz, Stadtgestalt – Forschung, Deutsch‐ 

Kanadisches Kolloquium, Trierer Geografische Studien, Trier, 1982 

L 

Law Herbert, Khronos Group, www.khronos.org: COLLADA RT on PS3, auf 

http://www.khronos.org/developers/library/2007_siggraph_bof_collada/SCIE.pdf, aufgeru‐ 

fen am 7.09.09

M 

Markuse Pierre, http://www.hardware‐observer.com:iphone_3g_s_3.jpg, auf 

http://www.hardware‐observer.com/wp‐content/uploads/2009/06/iphone_3g_s_3.jpg, 

aufgerufen am 7.09.09 

6. Anhang 123 

microsoft corporation, msdn developer library: Billboarding (Direct3D 9), auf 

http://msdn.microsoft.com/de‐de/library/bb172358%28en‐us,VS.85%29.aspx, aufgerufen 

am 7.09.09 

microsoft corporation, msdn magazine: Bearbeiten von Fotos mit Photosynth, auf 

http://msdn.microsoft.com/de‐de/magazine/cc163398.aspx, aufgerufen am 7.09.09 

N 

Nyberg Hans, http://virtualdenmark.dk: the_little_mermaid_960.jpg, auf 

http://virtualdenmark.dk/qtvr/images/the_little_mermaid_960.jpg, aufgerufen am 7.09.09 

P 

Photobucket Inc., www.tinypic.com: 2wlyemo.jpg, auf http://i39.tinypic.com/2wlyemo.jpg, 


Play3.de: Entwicklungskosten GTA4, auf http://www.play3.de/2008/05/02/rockstar‐nennt‐ 

rekord‐entwicklungskosten‐problemlosungen/, aufgerufen am 7.09.09 

Poesch, T., Schildwächter, R., Zeile, P.: Eine Stadt wird dreidimensional: 3D 

Stadtmodell Bamberg, in Schrenk, Manfred (Hrsg.): 9. Symposion 

„Computergestützte Raumplanung“ – CORP 2004, Wien, 2004 

R 

Rheinpfalz GmbH & Co KG: Neue Pläne für den alten Burghügel, in Rheinpfalz Ausgabe vom 

20.06.09, Rheinpfalz Verlag, Kaiserslautern, 2009 

Rockstar Games: realgta3ou3.jpg, auf 

http://img228.imageshack.us/img228/4919/realgta3ou3.jpg, aufgerufen am 7.09.09 

S 

SARL Futura‐Sciences, http://www.futura‐sciences.com: GoogleEarthColiseeBon2.jpg, auf 

http://www.futura‐sciences.com/fileadmin/Fichiers/images/High‐ 

Tech/GoogleEarthColiseeBon2.jpg, aufgerufen am 7.09.09

124 6. Anhang 

Schildwächter Ingenieure, www.schildwächter.name: IDA Lodge Road, auf 

http://www.schildwaechter.name/html/ida_lodge_road.html, aufgerufen am 7.09.09 

und Sindelfingen, auf 

http://www.schildwaechter.name/html/ida_lodge_road.html, aufgerufen am 7.09.09 

und Hotel Bamberg, auf 

http://www.schildwaechter.name/html/hotel_bamberg.html, aufgerufen am 7.09.09 

Schildwächter R.: 3D‐Stadtmodelle – Spielzeug oder Arbeitshilfe, in EDV IN DER RÄUMLI‐ 

CHEN PLANUNG und BAUVERWALTUNG. 502. Tagung der Deutsche Akademie für Städtebau 

und Landesplanung / Institut für Städtebau Berlin. 07‐09.12.2006, Berlin, auf 

http://www.schildwaechter.name/html/forschung.html, aufgerufen am 7.09.09 

Seiler David, www.fotorecht.de: Fotografieren von und in Gebäuden, auf 

http://www.fotorecht.de/publikationen/gebaeude.html, aufgerufen am 7.09.09 

Sharpened Productions, The Techterms Dictionary: Definition Realtime, auf 

http://www.techterms.com/definition/realtime, aufgerufen am 7.09.09 

Shiny Media Limited, www.techdigest.tv: MWC 2008: Second Life now runs on... an 

iPhone?!, auf 

http://www.techdigest.tv/2008/02/mwc_2008_second.html, aufgerufen am 7.09.09 

SPIEGEL ONLINE GmbH, www.spiegel.de: Google baut antikes Rom in 3D nach, auf 

http://www.spiegel.de/netzwelt/tech/0,1518,590178,00.html, aufgerufen am 7.09.09 

Stadtplanungsamt Bamberg, www.stadtplanungsamt‐bamberg.de: Virtuelles Stadtmodell 

sorgt für Aufsehen, auf 

http://www.stadtplanungsamt.bamberg.de/index.php?option=com_content&view=article&i 

d=555:virtuelles‐stadtmodell‐sorgt‐fuer‐aufsehen&catid=76:archiv‐3d‐im‐ 

stadtplanungsamt&Itemid=100008, aufgerufen am 7.09.09 

Streich, B., Weisgerber, W.: Computergestützter Architekturmodellbau: CAAD 

– Grundlagen, Verfahren Beispiele, Basel, Boston, Berlin, 1996 

in Zeile, P.: Erstellung und Visualisierung von virtuellen 3DStadtmodellen aus kommunalen 

Geodaten am Beispiel des UNESCO Welterbes Bamberg, Kaiserslautern 2004 

Streich, B.: Computer in der Stadtplanung – oder: Von Irrtümern und vom Umgang mit 

Komplexität. In: Streich, B und Schmidt, T. (Hrsg.): Computergestützte Assistenzsysteme für 

die Stadtplanung. Stadtmanagement auf neuen Wegen. Band 3 der „Beiträge zu Computer‐ 

gestützten Planungs‐ und Entwurfsmethoden“. Kaiserslautern 1997

und Stadtplanung in der Wissensgesellschaft, Wiesbaden, 2005 

T 

6. Anhang 125 

Tamedia AG, http://newsnetz‐blog.ch/webflaneur/: mob65_1187185507.jpg, auf 

http://newsnetz‐blog.ch/webflaneur/files/images/2007/8/mob65_1187185507.jpg, aufgeru‐ 

fen am 7.09.09 

Taptu Ltd, Mobile Enzoklopädie Wapedia: Meilensteine der 3D Engines, auf 

http://wapedia.mobi/de/Grafik‐Engine, aufgerufen am 7.09.09 

und Erklärung Grafikengine, auf 

http://wapedia.mobi/de/Grafik‐Engine, aufgerufen am 7.09.09 

Trieb M. et al: Erhaltung und Gestaltung des Ortsbildes – Denkmalpflege, Ortsbildplanung 

und Baurecht, Kohlhammer Verlag, Stuttgart, 1988 

V 

ViewTec Inc., http://www.viewtec.net/: terrainview13.jpg, auf 

http://www.viewtec.net/uploads/images/terrainview13.jpg, aufgerufen am 7.09.09 

virtualcitySYSTEMS GmbH, http://www.virtualcitysystems.de: Screenshot der Anwenung 

„Building Reconstruction“,auf 

http://www.virtualcitysystems.de/4‐service/3d‐gebaeuderekonstruktion.html, aufgerufen 

am 7.09.09 

W 

Weblogs Inc., www.tuaw.com: Google Buys @Last, Developer of SketchUp, auf 

http://www.tuaw.com/2006/03/14/google‐buys‐last‐developer‐of‐sketchup/, aufgerufen 

am 7.09.09 

WEB‐SET Interactive GmbH, www.htmlopen.de: Was ist VRML?, auf 

http://www.htmlopen.de/programmierung/vrml/, aufgerufen am 7.09.09 

Wettels, P.: Erläuterungen zur Diplomarbeit, Kaiserslautern, 2004 

Wick Niklas, www.apfelnews.de: Apples iPhone konnte den Marktanteil im ersten Quartal 

verdoppeln, http://www.apfelnews.eu/2009/05/21/apples‐iphone‐konnte‐den‐marktanteil‐ 

im‐ersten‐quartal‐verdoppeln/, aufgerufen am 7.09.09

126 6. Anhang 

Wikimedia Foundation Inc., www.wikipedia.de: Artikel Baum, auf 

http://de.wikipedia.org/wiki/Baum, aufgerufen am 7.09.09 

und Artikel Inuyama, auf 

http://de.wikipedia.org/wiki/Inuyama, aufgerufen am 7.09.09 

Wikimedia Foundation, Inc:Trier_Stadtmodell.JPG, auf 

http://upload.wikimedia.org/wikipedia/de/2/21/Trier_Stadtmodell.JPG, aufgerufen am 

7.09.09 

Wohnbaugenossenschaft wagnis eG, http://www.wagnis.org: 

big_wagnis3_dsc_7281_architekturmodell_komplett.jpg, auf 

http://www.wagnis.org/assets/galleries/126/big_wagnis3_dsc_7281_architekturmodell_ko 

mplett.jpg, aufgerufen am 7.09.09 

X 

xfrog Inc., www.xfrogdownloads.com: Terragen 2 with XfrogPlants: Sidegrades and Mega‐ 

Bundle, auf http://www.xfrogdownloads.com/greenwebNew/products/productStart.htm, 


Y 

YOUin3D.com GmbH, www.berlinin3d.de: BERLINin3D: Virtuelles Berlin in Second Life, auf 

http://www.berlinin3d.com/, aufgerufen am 7.09.09 

Z 

Zeile, P.: Erstellung und Visualisierung von virtuellen 3DStadtmodellen aus kommunalen 

Geodaten am Beispiel des UNESCO Welterbes Bamberg, Kaiserslautern 2004

heruntergeladen werden - cpe - Universität Kaiserslautern

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?