Zeichenvorschriftskonforme Darstellung von ALK

Hochschule Vechta
Studiengang Umweltmonitoring
Diplomarbeit zum Thema:
Zeichenvorschriftskonforme Darstellung von ALK-
Daten im UMN Mapserver unter Verwendung von
Open-Source-Software
Erstgutachter: Prof. Dr. Martin Breunig
Zweitgutachter: Dr. Gunther Schmidt
Vorgelegt am 13. Juli 2006
von Dipl.-Geogr. Kai Behncke

Danksagung
Besonders gedankt sei an dieser Stelle den Betreuern dieser Diplomarbeit Prof. Dr. Martin
Breunig und Dr. Gunther Schmidt. Für Fragen hatten diese stets „ein offenes Ohr“ und
ihre Anregungen und Hinweise sorgten dafür, dass auftretende Schwierigkeiten schnell
bewältigt werden konnten.
Dank gebührt auch der netten Belegschaft der Intevation GmbH.
Hervorzuheben sind hier insbesondere Silke Reimer sowie Dr. Jan-Oliver Wagner, welche
bei der Einarbeitung in die Thematik dieser Diplomarbeit unterstützend zur Seite
standen. Auch soll an dieser Stelle Sascha Wilde, Frank Koormann, Bernhard Reiter,
Ludwig Reiter, Thomas Arendsen-Hein und Bernhard Herzog für viele qualitativ
hochwertige Tipps und Hinweise gedankt werden.
Zu Dank verpflichtet fühlt sich der Autor auch gegenüber Christian Aden von der
Universität Osnabrück sowie dem Systemadministrator des Institutes für Geoinformatik
und Fernerkundung Frank Klein, welche Server für die Veröffentlichung des technischen
Teils dieser Arbeit zur Verfügung stellten.
„Last but not least“ soll Kerstin Philipp für das Korrekturlesen dieser Arbeit gedankt
werden.
Vechta, im Juli 2006

Inhaltsverzeichnis
1. Einleitung 1
2. Hintergründe 6
2.1 Die Automatisierte Liegenschaftskarte 6
2.1.1 ALK-Datenbankkonzept 8
2.1.2 ALK-Objektsicht 10
2.1.3 ALK-Gestaltungsgrundlagen 12
2.1.3.1 Objektabbildungskatalog 12
2.1.3.2 Objektschlüsselkatalog 12
2.1.3.3 Zeichenvorschrift Automatisierung 13
2.1.4 Nutzen der ALK 14
2.2 Von ALK zu ALKIS – Motivation der ALKIS-Einführung 16
2.3 ALKIS – Das Amtliche Liegenschaftskataster-Informationssystem 17
2.3.1 ALKIS-Datenkonzept 19
2.3.2 ALKIS-Gestaltungsgrundlagen 21
2.3.2.1 Grunddatenbestand 21
2.3.2.2 ALKIS-Objektartenkatalog 22
2.3.2.3 ALKIS-Signaturenkatalog 22
2.4 Open Source/Freie Software im Unterschied zu proprietärer Software 25
2.4.1 Begrifflichkeiten und Konzepte 25
2.4.2 Freie Software/Open Source und Lizenzen 29
2.4.3 Freie Software/Open Source und proprietäre Software im Vergleich 30
2.4.3.1 Wirtschaftsfaktor 31
2.4.3.2 Entwicklerprozess 32
2.4.3.3 Leistung 33
2.4.3.4 Abhängigkeit 34
2.4.3.5 Wissensverbreitung 35
2.4.3.6 Kostenfaktor 36

2.4.4 Vergleich zweier Mapserver aus dem Freie Software/Open-Source-
Bereich sowie dem proprietären Sektor 38
2.4.4.1 UMN Mapserver 38
2.4.4.2 ArcIMS 40
2.5 Das Projekt FreeZVAUT 42
2.5.1 Projektstruktur 44
3. Methodik 46
3.1.Grundsätze kartographischer Darstellung 46
3.2 Systemumgebung 50
3.2.1 Betriebssystem 50
3.2.2 UMN Mapserver 51
3.2.2.1 Basisfunktionen des UMN Mapservers 54
3.2.2.1.1 Visualisierung 54
3.2.2.1.2 Navigation 54
3.2.2.1.3 Abfrageoption 54
3.2.2.2 Technische Basisdateien des UMN Mapservers 55
3.2.2.2.1 Mapfile 55
3.2.2.2.2 HTML-Template 55
3.2.2.2.3 Weitere Dateien 56
3.2.3 Apache Webserver 57
3.2.4 Fontforge 59
3.2.5 Edbsilon 59
3.2.6 Postgresql/PostGIS 60
3.2.7 SVN 61
3.2.8 Zusätzliche Komponenten für das Flurstücksinformationssystem 62
3.2.8.1 PHP 62
3.2.8.2 PHP/Mapscript 63
3.2.8.3 JavaScript 63
3.3 Datenmodellierung mit UML 64
4. Technische Realisierung 67

4.1 Umsetzung des FreeZVAUT-Projektes 67
4.1.1 Symbolerstellung 67
4.1.2 Flurstücksnummerierung 74
4.1.3 Begleitzeichen von Flur- bzw. Gemarkungsgrenzen 78
4.1.4 Aufnahmepunkte 81
4.1.5 Flächensignaturen 85
4.2 Technische Umsetzung des Flurstücksauskunftssystems 90
4.2.1 Attribute der Flurstücksflächen 91
4.2.2 Layerauswahl 93
4.2.3 Flurstücksauswahl 96
4.2.4 Navigation 98
4.2.5 Flächenabfrage 99
4.2.6 Datenanzeige 100
5. Diskussion und Ausblick 102
5.1 Diskussion und Ausblick von FreeZVAUT 102
5.1.1 Mapserverspezifische Schwierigkeiten 103
5.1.1.1 Größenangaben 103
5.1.1.2 Begleitzeichen von Flur- bzw. Gemarkungsgrenzen 103
5.1.1.3 Druck 107
5.1.2 Edbsilonspezifische Schwierigkeiten 107
5.1.2.1 Eigene Geometrie 107
5.1.2.2 Winkelangabe 109
5.1.2.3 Doppelte Polygongrenzen 110
5.2 Flurstücksinformationssystem 113
5.3 Umstellung von ALK zu ALKIS 114
6. Fazit 117
7. Literaturverzeichnis 118
8. Anhang 126

„There is no centre anywhere that could hope to
organize and oversee all this mutual thickening of ties. It
would be like trying to instruct a forest how to grow“
PGA bulletin five, Februar 2000, UK edition in:
Verso (2003): „We are everywhere“. London, New York
© Kai Behncke
Diese Arbeit unterliegt der GNU-GPL.

1. Einleitung
1. Einleitung
Im Jahre 2004 sammelte der Autor dieser Arbeit im Rahmen eines Studienprojektes die
ersten Erfahrungen mit dem UMN Mapserver.
Das hinter dieser Software stehende, offene Konzept übte eine große Faszination aus:
Theoretisch wird niemand von diesem Hochleistungsprodukt ausgeschlossen; Wissen und
Input sind für alle Anwender gleichermaßen zugänglich, sofern sie einigermaßen Englisch
sprechen.
Im September 2005 wurde ein dreimonatiges Praktikum bei der Firma Intevation
GmbH in Osnabrück begonnen, und es entwickelte sich ein gemeinsames Open-Source-
Projekt, welches sich FreeZVAUT nennt.
Dieses Projekt hat verschiedene Entstehungsmotivationen:
Die ZV-Aut (Zeichenvorschrift Automatisierung) ist die Zeichenvorschrift für die
Darstellung von ALK-Symbolen und Signaturen (siehe auch Kapitel 2.1.3.3). Um eine
rechtskonforme ALK (Automatisierte Liegenschaftskarte) zu erstellen, muss die ZV-Aut
berücksichtigt werden.
Die ALK hat eine hohe Bedeutung für räumliche Auskunftssysteme. Sie wird als
Auskunfts- oder auch als Planungsgrundlage für Wirtschaft und Verwaltung genutzt.
Ursprünglich lag die ALK als Papierprodukt vor. Im digitalen Hightechzeitalter liegt es
nahe, diese Karte auch im Inter- bzw. Intranet zu präsentieren.
DICKMANN schreibt allgemein zur Kartendarstellung im Internet: „Die Vorteile gegenüber
Papierkarten, aber auch gegenüber Offline-Bildschirmkarten sind offenkundig, betrachtet
man die technisch vorhandenen und theorethisch möglichen Potentiale internet-basierter
kartographischer Darstellungen. Zweifellos können der zeitlich und räumlich
unbeschränkte Zugang zu Webservern, die plattformübergreifende Datenverarbeitung, der
Einbindung multimedialer Komponenten (...) zu einer unkomplizierteren und vielfältigeren
Informationsübermittlung führen, als dieses früher der Fall war.” 1
1 Dickmann 2001, S.11 f.
1

Durch eine webbasierte Darstellung der ALK in Verbindung mit leicht zu
1. Einleitung
aktualisierenden Datenbanken können räumliche Daten mehr oder weniger einfach und
unkompliziert präsentiert und abgefragt werden.
Eine schnelle Präsentation in verschiedenen Maßstäben und auch die Darstellung
verschiedener Layer (und Daten) unterschiedlicher Fachanwendungen wird möglich.
Eine Zukunftsvision, welche langfristig durch das Projekt realisiert werden könnte (die
Betonung liegt auf “Vision” und “langfristig”), wäre eine bürgernahe, transparente
Darstellung von Geodaten zu den bundesweit vorliegenden Flurstücken für jedermann.
Dieses setzt natürlich einschränkend voraus, dass entsprechende Daten kommunal und
föderal umfassend zur Verfügung stehen und datenschutzzrechtlich freigegeben werden
können. Räumliche Informationen würden somit nicht, wie aktuell, primär
verwaltungsintern vorliegen, sondern der Allgemeinheit zur Verfügung stehen.
Die Auskunftsmöglichkeiten sind, sofern entsprechendes Datenmaterial vorliegt, schier
unbegrenzt:
Wem gehört das Flurstück xyz an der Musterstraße x bzw. wie lauten die Namen der
Nachbarn?
Welche Nutzungsform liegt in den Flächen im Planquadrat xy vor?
Welche Gebäudeflächen sind vom Wasserrohrbruch des Rohres mit der Kennzeichnung
xyz betroffen?
Wie viel ist diese und jene Fläche im neu entstehenden Gewerbegebiet wert und wer ist
der aktuelle Eigentümer?
Wie lange ist die Ackerfläche xyz noch verpachtet und was wird dort aktuell angebaut?
Um Fragen dieser Art zu beantworten und auch eine rechtskoforme Kartendarstellung
zu gewährleisten, sind als Grundlage (neben dem Vorhandensein entsprechender Daten
und dem Aufbau einer Oberfläche für eine Datenabfrage) erst einmal zwei Dinge nötig:
Zum einen sind die Darstellungsvorschriften der ZV-Aut für eine Anwendung im Web
2

1. Einleitung
umzusetzen, es müssen also eine Vielzahl von Symbolen und Signaturen erstellt werden.
Zum anderen muss innerhalb einer Mapserverarchitektur eine Anwendung erstellt
werden, welche Liegenschaftsdaten automatisiert als digitale Karte darstellt.
Um beides geht es im Projekt FreeZVAUT.
Gemäß des Prinzips „Wissen für alle, und zwar gleichberechtigt” soll diese Anwendung
frei zu verwenden sein. Jeder Bürger, jede Kommune, jeder Landkreis, jede Universität
muss gleichermaßen und ohne Exklusion die Möglichkeit haben, das aus dem FreeZVAUT
entstehende Produkt frei zu nutzen.
Im Rahmen des Projektes soll eine Systemarchitektur verwendet werden, welche keinerlei
Nutzungsbeschränkungen beinhaltet. Innerhalb des FreeZVAUT-Projektes werden aus
diesem Grund ausschließlich Freie/Open-Source-Produkte verwendet (siehe auch Kapitel
3.2).
Innerhalb dieser Einleitung soll somit auch ein gesellschaftlicher Aspekt als
Handlungsmotivation genannt werden.
In Zeiten, in welchen viele Kommunen und Landkreise wenig Geld haben, ist es nach
Auffassung des Autors wichtig, frei zugängliche und kostenlose Anwendungen zu
implementieren. Öffentliche Kassen werden dadurch entlastet, ohne dass, wenn das
Projekt entsprechend gestaltet wird, qualitative Einbußen entstehen. Hiermit wird auch
einer Monopolisierung bzw. Patentierung von (Software-)Wissen im wahrsten Sinne des
Wortes „ein Strich durch die Rechnung gemacht”.
Auch können eventuell eingesparte Gelder an anderer Stelle wieder gesellschaftlich
sinnvoll investiert werden.
Dass z.B. im Rahmen von Planung oder Verwaltung öffentliche, kostenlose
Geodatenanwendungen einen gesellschaftlichen Nutzen darstellen, dürfte unbestreitbar
sein.
Es geht mittels FreeZVAUT keineswegs darum, einen eventuell vorhandenen
wirtschaftlichen Markt „kaputtzumachen” (wie Kritiker von Open-Source-Software
oftmals irrtümlich behaupten).
3

1. Einleitung
Es geht darum, freien Input zu erstellen, welcher sowohl kostenlos aber auch im Rahmen
monetärer Dienstleistung verwendet werden darf.
In diesem Sinne wurde das Projekt FreeZVAUT unter der GNU GPL-Lizenz veröffentlicht
(siehe auch Kapitel 2.4.2).
Es ergibt sich somit der Titel der Diplomarbeit: „Zeichenvorschriftskonforme
Darstellung von ALK-Daten im UMN Mapserver unter Verwendung von Open-Source-
Software”.
In dieser Arbeit geht es primär darum, das Projekt FreeZVAUT und dessen technische
Realisierung darzustellen. Es soll erläutert werden, was mit diesem Projekt möglich ist,
aber auch, wo noch Begrenzungen und Hemmnisse festzustellen sind.
Gerade die Betonung der Schwierigkeiten ist ein wichtiger Punkt. Schließlich ist es im
Rahmen von Open-Source-Projekten möglich, Quellcode zu verändern und zu
verbessern, wofür zuvor natürlich Schwierigkeiten und Hemmnisse benannt und
analysiert werden müssen.
Ein weiterer wichtiger Punkt, wenn auch innerhalb dieser Diplomarbeit prioritär hinter
dem FreeZVAUT-Projekt liegend, ist die Erstellung, Vorstellung und Beschreibung eines
möglichen Flurstücksauskunftssystems unter Implementierung der Ergebnisse des
FreeZVAUT-Projektes.
Hiermit soll dem Leser praktisch verdeutlicht werden, welchen Nutzen ein Anwender von
einem Auskunftssystem haben kann. Es soll deutlich werden, was bei Vorhandensein
spezifischer Daten möglich ist.
Da die ALK mittelfristig auf ALKIS (Amtliches Liegenschaftskataster-
Informationssystem) umgestellt wird, soll auch beleuchtet werden, in welchem Maße sich
Gestaltungsgrundlagen und Anforderungen an die Darstellung von Symbolen und
Schraffuren ändern. Mit Blick auf die Zukunft wird erläutert, welche Auswirkungen die
Umstellung letztlich auf die Präsentation des Kartenwerkes im UMN Mapserver haben
wird.
4

Es ergeben sich neben dieser Einleitung folgende Kapitel:
1. Einleitung
In Kapitel 2 wird auf die verschiedene Hintergründe der ALK und ALKIS eingegangen.
Auch wird die Thematik der Freien Software/Open Source im Vergleich zu proprietärer
Software beleuchtet und in diesem beschreibenden Teil der Arbeit das FreeZVAUT-
Projekt ausführlich erläutert.
In Kapitel 3 (Methodik) wird auf Grundsätze kartographischer Darstellung, den Aufbau
einer Systemarchitektur sowie Datenmodellierung mittels der Sprache UML eingegangen.
Kapitel 4 widmet sich der technischen Realisierung des FreeZVAUT-Projektes sowie des
Auskunftssystems.
In Abschnitt 5 (Diskussion und Ausblick) werden, auch mit Blick auf die Zukunft,
erarbeitete Ergebnisse kommentiert und Besonderheiten hervorgehoben.
Kapitel 6 (Fazit) stellt schlussendlich das zusammenfassende Kapitel dieser Arbeit dar.
5

2. Hintergründe
2. Hintergründe
Um den wissenschaftlichen Anspruch zu untermauern und die Sinnhaftigkeit, den
gesellschaftlichen Nutzen aber auch die Herausforderungen der in der Einleitung
anvisierten Ziele besser zu verdeutlichen, ist es notwendig, dem Leser einige
Hintergründe darzulegen.
Nachfolgend sollen die Besonderheiten der ALK und ALKIS erläutert werden
(insbesondere die Gestaltungsgrundlagen sowie die Gründe, welche zu einem Umstieg
von ALK nach ALKIS führten). Auch soll der Leser einen Einblick in das hinter der ALK
und ALKIS liegende Datenkonzept bekommen.
Anschließend werden Charakteristika von Open-Source-Projekten bzw. proprietärer
Software benannt sowie Grundlagen und Besonderheiten des FreeZVAUT-Projektes
dargestellt.
2.1 Die Automatisierte Liegenschaftskarte
Die Entstehung der Automatisierten Liegenschaftskarte (ALK) basiert auf
Entscheidungen der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der
Bundesrepublik Deutschland (AdV) zu Beginn der 70er Jahre.
Ziel war es, die Führung des Liegenschaftskatasters zu automatisieren und dabei
gleichzeitig im Rahmen der staatlichen Aufgabe der Daseinsvorsorge, digitale Daten den
Nutzern des Katasters zur Verfügung zu stellen. Aus diesem Grund wurde im Jahre 1971
das Konzept „Automatisiertes Liegenschaftskataster" entwickelt, woraus dann die beiden
anwendungsbezogenen Sollkonzepte „Automatisiertes Liegenschaftsbuch (ALB, 1973)"
und „Automatisierte Liegenschaftskarte (ALK, 1975)" entstanden. 2
Die ALK ist als objektstrukturierter Vektordatenbestand der bildliche Teil des
Liegenschaftskatasters. In ihr werden Lage und Geometrie der Flurstücke und Gebäude
mit Nutzungsarten, Topografie und öffentlich-rechtlichen Festlegungen beschrieben und
dargestellt. 3
2 Stöppler 1987, S. 65; Seifert 2000, S.13; Grote/Seifert 2001, S.238
3 vgl. Grote/Seifert 2001, S.240
6

2. Hintergründe
Das Flurstück ist hierbei ein Teil der Erdoberfläche, welcher durch amtliche
Vermessung festgelegt und mit einer Flurstücksnummer belegt wird. Dargestellt werden
Gebäude und bauliche Anlagen, wenn sie dauerhaft errichtet und für die Beschreibung
des Grund und Bodens von Relevanz sind. 4
Die Realisierung der ALK liegt in der Verwaltungshoheit der einzelnen Bundesländer.
Dieses führt zu Unterschieden in der Darstellung von einzelnen Objekten. Auch ist der
Bearbeitungsstand der ALK in den einzelnen Föderationen sehr unterschiedlich. So gibt
es Bundesländer, in denen die ALK mittlerweile flächendeckend vorliegt (z.B. Hessen und
Rheinland-Pfalz) während sie in Thüringen lediglich für 47% der Landesfläche vorhanden
ist (Stand 25.5.2005). 5 Als Beispiel für einen ALK-Ausschnitt soll Abbildung 1 dienen.
Abbildung 1: Ausschnitt aus der Automatisierten Liegenschaftskarte
Quelle: http://www.lverma.nrw.de/produkte/liegenschaftsinformation/
katasterinfo/alk/ALK.htm# vom 17..5006
Mit der ALK erhält man eine aktuelle, maßstabsunabhängige und blattschnittfreie Be­
reitstellung der Grundrissdaten in analoger (nach Ausdruck) oder digitaler Form.
Sie weist mit dem Gauß-Krüger-Koordinatensystem einen einheitlichen Raumbezug auf
4 http://www.gll.niedersachsen.de/master/C10540068_N8679277_L20_D0_I7746208.html vom
18.5.2006
5 http://www.adv-online.de/extdeu/broker.jsp?uMen=ea510328-46de-1afa-6d78-79f08a07b51a
vom 17.5.2006
7

2. Hintergründe
und gewährleistet durch ihre objektbezogene Datenstruktur eine gezielte Selektion und
Verknüpfung der Inhalte.
Das ALB schließlich enthält zusätzliche Daten in schriftlicher Form (Sachdaten wie
Nutzungsarten, Eigentumsverhältnisse, Flächengröße etc.). 6
2.1.1 ALK-Datenkonzept
Das ALK-Konzept beinhaltet einen Datenbank- und einen Verarbeitungsteil, welche
gegenseitig über das EDBS-Format kommunizieren können (siehe Abbildung 2).
Abbildung 2: Systemkonzeption der ALK
Quelle: Eigene Darstellung nach http://www.lverma-mv.de/lie_alk.htm vom 20.5.2006
Sämtliche Daten werden im Datenbankteil gespeichert.
In der Grundrissdatei werden die geometrischen und semantischen Informationen für die
Darstellung des Karteninhaltes abgelegt, also z.B. Objektkoordinaten, Geometrietyp,
Objektnummer, Objektnamen und Entstehungsdatum. 7
Grundrissobjekte gleichen Inhalts bilden Objektarten, die einzelnen Folien zugeordnet
werden (eine "Folie" bildet dabei eine Ordnungseinheit).
6 http://www.gis-tutor.de/theorie/daten/basisdat/basisdat.htm vom 21.5.2006
7 Stöppler 1987, S.75 f.; Beisch 1998, S.34 ff.
8

Folgende Folien sind z.B. in der ALK vorhanden:
etc.
● Folie 001: Flurstücke
● Folie 002: Flur- und Gemarkungsgrenzen
● Folie 003: Verwaltungsgrenzen
● Folie 011: Gebäude
● Folie 021: Nutzungsarten
2. Hintergründe
Grundrissobjekte können entsprechend ihrer geometrischen Ausprägung flächen-,
linien- oder punktförmig sein und aus verschiedenen Bestandteilen bestehen.
So gehören z.B. zum flächenförmigen Grundrissobjekt Flurstück die zugehörigen Flur­
stücksgrenzen mit deren Bezugspunkt als Objektkoordinate und dem Flurstückskennzei­
chen als Objektnamen.
In der Punktdatei werden Punkte der Grundlagenvermessung und des Liegenschafts­
katasters geführt, wie z.B. Gebäudepunkte oder Nutzungsgrenzpunkte. 8
Die Punktdatei hat vorwiegend katasterinterne Bedeutung. 9
In der Datei der Messungselemente sind Bestimmungsstücke zur Berechnung von
Lagekoordinaten und -höhen vorhanden.
Die Systemdateien enthalten Daten, welche die Datenbankverwaltung steuern. So
findet man hier z.B. Angaben zur Interpretation der EDBS-Sätze und zur Plausi-
bilitätsprüfung.
EDBS-Daten werden in Form sogenannter „Aufträge" übermittelt. Das Auftragsbuch im
Rahmen des Datenbankteils enthält die Auftragsdaten für die Dauer der Auftragsbe­
arbeitung. 10
Der Verarbeitungsteil (auch als GIAP (grafisch interaktiver Arbeitsplatz) bezeichnet)
enthält die fachlichen Verarbeitungsprogramme (z.B. SICAD oder ALK/GIAP). 11
Hier findet eine Kommunikation mit dem Sachbearbeiter statt; das bedeutet, es werden
8 Stöppler 1987, S.75
9 https://www.maklerinfo.biz/homepage-Dateien/include-Dateien/Wikipedia_Schnittstelle.php?Suchbegriff=EDBS
vom 20.5.2006
10 LGN 1987, S.1 f.
11 Pohlmann/Ridder 1995, S.251
9

2. Hintergründe
hier Aufträge zur Einrichtung, Fortführung und Benutzung des Datenbankteils erstellt.
Der Datenbankteil nimmt die Daten des Verarbeitungsteils entgegen, führt die Einrich­
tung, Fortführung und Benutzung der Dateien durch und stellt das Ergebnis dem
Verarbeitungsteil wiederum in Form der EDBS-Daten zur Verfügung. 12
In der Praxis beinhaltet dieses z.B. Schritte der Digitalisierung, Scan-Verfahren von
analog geführten Liegenschaftskarten sowie die photogrammetrische Auswertung von
Orthophotos. Weitere Schritte sind die Transformierung in ein einheitliches geodätisches
Bezugssystem, Randanpassung sowie Objektbildung. Die bei der Digitalisierung erfassten
Elemente der Liegenschaftskarte (Punkte, Linien, Texte und Symbole) werden
entsprechend ihrer fachlichen Bedeutung zu Grundrissobjekten zusammengefasst. 13
2.1.2 ALK-Objektsicht
Innerhalb der ALK ist zwischen einer elementargeometrischen Sicht sowie einer
Objektsicht zu unterscheiden.
Elementargeometrische Sicht bedeutet, dass die Karte bzw. ihre graphischen In­
formationen in die kleinsten möglichen Einheiten (Objektelemente) zerlegt werden.
Dabei kann es sich um punktförmige Einheiten (z.B. einen Grenzpunkt), linienförmige
Einheiten (z.B. eine Gebäudeseite), flächenförmige Einheiten (z.B. eine Gebäudefläche)
oder um textförmige Einheiten (z.B. Flurstücksnummern) handeln.
Eine Objektsicht beinhaltet die kleinstmögliche logische Einheit, die aus fachlicher
Sicht gebildet werden kann. So werden in der ALK also nicht die Grenzen oder Nummern
eines Flurstücks oder z.B. die Seite eines Gebäudes als einzelne Objekte gebildet, sondern
das gesamte Flurstück bzw. Gebäude mit seinen Grenzen und Texten. 14
12 LGN 1987, S.1
13 Pohlmann/Ridder 1995, S.251ff.; Derksen/Peick/Ulbricht 2001, S.31ff.
http://www.lvsn.smi.sachsen.de/produkte/liegen/alk/inhalt_re_alk.html vom 1.6.2006
14 Stöppler 1987, S.78; http://www.igip.de/ALK-Lexikon/index-alk-lexikon.html vom 22.5.2006
10

2. Hintergründe
Objektarten gleichen Inhalts werden dann, wie oben bereits erwähnt, einzelnen Folien
zugeordnet. Nachfolgende Abbildung verdeutlicht das ALK-Objektmodell.
Abbildung 3: ALK-Objektmodell
Quelle: Eigene Darstellung
Zur Verdeutlichung: Die Folie 001 (Flurstücke) z.B. stellt die Objektarten „Flurstück“ dar.
Die Objektart „Flurstück“ wiederum besteht aus verschiedenen Objektelementen (z.B.
Flurstücksgrenze, Flurstücksnummer etc.).
Es ist im Rahmen der ALK möglich, dass ein Plan produziert wird, ohne dass die
Objektteile „wissen“, dass sie zusammen gehören, also ohne dass eine Objektbildung
stattgefunden hat. Objekte werden erst nachträglich durch das jeweilige
Anwendungssystem aus den Geometrieelementen und ihren Fachbedeutungen gebildet. 15
Die Objektbildung (also die Zuordnung von Objektelementen zu einem Objekt) ist
Grundvoraussetzung für thematische Auswertungen oder Auskunftszwecke.
15 http://www.gis-tutor.de/theorie/daten/basisdat/basisdat.htm vom 22.5.2006
11

2.1.3 ALK-Gestaltungsgrundlagen
2. Hintergründe
Gestaltungsgrundlagen der ALK sind im OSKA (Objektschlüsselkatalog), im OBAK
(Objektabbildungskatalog) und in der ZV-Aut (Zeichenvorschrift Automatisierung)
festgelegt.
2.1.3.1 Objektabbildungskatalog
Der Objektabbildungskatalog legt die Regeln dafür fest, welche fachlichen
Informationen zu einzelnen Grundrissobjekten zusammenzufassen sind (Objektbildung)
und wie diese abgebildet werden sollen (Objektabbildung).
So ist hier beispielsweise statuiert, dass jeder besondere Bauteil am Gebäude als
eigenständiges Objekt zu definieren ist. Auch wird z.B. angegeben, welche Schriftzusätze
für Gebäude zu erfassen sind.
2.1.3.2 Objektschlüsselkatalog
Im Objektschlüsselkatalog (OSKA) sind die Objektarten sowie die Bestandteile der
Grundrissobjekte mit den zugehörigen Objektarten- und Folienschlüsseln festgelegt.
Festgelegt wird z.B, dass in Folie 011 (Gebäude) ein Kindergarten den Objektschlüssel
1165 besitzt. 16 Die Funktion, welche ein Objekt bzw. Objektbestandteil aufweist, wird
„Fachbedeutung" genannt (die Fachbedeutung des Gebäudes mit dem OS
(Objektschlüssel) 1165 lautet in diesem Falle also „Kindergarten").
Die Grundrissinformationen werden also durch einen dreistelligen Folienschlüssel und
einen vierstelligen Objektschlüssel verschlüsselt. Diese Verschlüsselung dient der
eindeutigen Identifizierung eines Objektes bzw. Objektbestandteiles.
Hierdurch wird die Möglichkeit des fachlichen und technischen Datenaustausches mit
fachspezifischen Informationssystemen (z.B. der Verwaltung) gegeben, also eine
Verknüpfung von Informationen gewährleistet. 17
16 Innenministerium NRW 2003, S.20
17 http://www.gismngt.de/update/alk.htm vom 23.5.2006
12

2.1.3.3 Zeichenvorschrift Automatisierung
2. Hintergründe
Die ZV-Aut ist die Zeichenvorschrift für die Darstellung der Elemente der Definitions- und
Ausgestaltungsgeometrie. 18 Innerhalb dieser Diplomarbeit stellt diese eine wesentliche
Arbeitsgrundlage des Autors dar und soll daher etwas ausführlicher erläutert werden.
In der ZV-Aut sind zu sämtlichen Objekten/Objektteilen Darstellungsangaben äußerst
präzise festgelegt. Es werden hier beispielsweise millimetergenaue Deklarationen für
Schrifthöhe, Schriftneigung oder Linienstärke vorgegeben (siehe Abbildung 4).
Die graphische Darstellung der Grundrissobjekte in der analogen/digitalen Ausgabe
richtet sich nach dieser Vorschrift.
Abbildung 4: U-Bahnhof-Symbol aus der ZV-Aut
Quelle: Eigene Darstellung nach Innenministerium NRW 2005, S.26
Abbildung 4 stellt ein Objekt (U-Bahnhof) aus der Folie 011 (Gebäude) dar.
Dieses Objekt trägt den Objektschlüssel 1194 und soll eine Linienbreite der Klasse 2 (0,18
mm) sowie einen Durchmesser von 7 mm aufweisen. Der Buchstabe soll 3,5 mm hoch
sein und die Schriftlage senkrecht. Als weiteres Beispiel soll ein Auszug aus der Folie 021
(tatsächliche Nutzung) dienen (siehe Abbildung 5 auf der folgenden Seite).
In Abbildung 5 wird explizit festgelegt, wie groß die Linienabstände in horizontaler bzw.
vertikaler Ausrichtung bei dem „Steinsymbol“ sein dürfen (5 bzw. 1 mm) und auch dass
die Beschriftung beim Objekt „Erz" 2,5 mm hoch und rechtsgeneigt sein muss.
Insgesamt finden sich in der ZV-AUT 21 Folien der Liegenschaftskarte mit über 600
expliziten Darstellungsvorschriften zu unterschiedlichen Objekten bzw. Objekt-
bestandteilen.
18 http://www.gis-tutor.de/theorie/daten/basisdat/basisdat.htm vom 23.5.2006
13

Abbildung 5: Auszug aus der ZV-Aut
Quelle: Eigene Darstellung nach Innenministerium NRW 2005, S.29
2. Hintergründe
Die Vorschriften der ZV-Aut sind die wesentliche Grundlage für eine rechtsverbindli­
che Erstellung der Automatisierten Liegenschaftskarte.
2.1.4 Nutzen der ALK
Die Daten der ALK bilden als Geobasisdaten eine Grundlage für raumbezogene
Informationssysteme in vielen Bereichen der Wirtschaft, Verwaltung, Planung sowie des
Umwelt- und Naturschutzes (siehe Abbildung 6 auf der folgenden Seite). 19
Der eigentliche Nutzen entsteht durch die Verknüpfung der Grundrissobjekte mit
bestimmten Fachdateien/Fachdaten. So würden in einem Energieversorgungsunterneh-
men (Gas, Strom, Wasser) beispielsweise zu jedem Gebäude zusätzliche Dateien zu den
jeweiligen Hausanschlüssen vorliegen.
19 Pohlmann/Ridder 1995, S.255 ff.
14

Abbildung 6: ALK-Verwendungsbereiche
2. Hintergründe
Quelle: Eigene Bearbeitung nach: http://www.adv-online.de/extdeu/broker.jsp?uMen=ea7769da-d319-fa6d-
7879-f08a07b51a69 vom 1.6.2006
15

2. Hintergründe
2.2 Von ALK zu ALKIS - Motivation der ALKIS-Einführung
ALKIS ist ein Konzept zur Integration von ALK und ALB in ein einheitliches
Datenmodell. Erstellt und dokumentiert wurde es von der AdV (Arbeitsgemeinschaft der
Vermessungsverwaltungen der Länder).
Der wesentliche Grund für die Einführung von ALKIS liegt in der veralteten
Datenstruktur von ALK und ALB, deren Konzepte aus den 70er Jahren stammen.
Da sich die Technik in rasantem Tempo weiter entwickelt und es mittlerweile auch
veränderte/gestiegene Anforderungen an die Datennutzung gibt, war es erforderlich, die
hinter ALK und ALB liegenden Datenkonzepte zu überdenken.
Folgende Mängel waren/sind festzustellen:
● In ALK und ALB gibt es noch eine getrennte und teilweise redundante
Datenhaltung, so dass z.B. eine Frage wie „Wie lauten die Eigentümer eines
Flurstückes und seiner Nachbargrundstücke?" nur mit viel Aufwand beantwortet
werden kann. Eine Integration der beiden Systeme wurde vielfach gefordert. Auch
ist der Pflegeaufwand für die veralteten Systeme sehr hoch. 20
● Ein großes Problem ist auch die länderübergreifende Datenausgabe im ALK-
System. Dort stellt der OBAK lediglich eine Empfehlung dar, welche
länderspezifische Gestaltungsmöglichkeiten lässt. Dieses führt zu sehr
inhomogenen Daten und damit verbundenen Schwierigkeiten, wenn Daten über
Ländergrenzen hinweg genutzt werden sollen. 21
● Die ursprüngliche Datenmodellierung entspricht keiner Norm und ist
international schwer verständlich. 22
● ALK- und ALB-Daten weisen keine Metadaten (z.B. zur Aktualität und
Genauigkeit) auf. 23 Durch die zusätzliche Speicherung dieser Daten aber würde
der Nutzer in die Lage versetzt, die fachliche Eignung der Daten für seine
20 Seifert 2000, S.14
21 Seifert 2004, S.31
22 Seifert 2000, S.14
23 http://www.lvermgeo.rlp.de/lv/aufgaben/ALKIS.html vom 5.6.2006
16

Anwendung zu beurteilen.
2. Hintergründe
● Ein weiteres Problem ist die Tatsache, dass die Verknüpfung von Fachdaten über
die Geometrie eines Objektes erfolgt. Bei homogenisierungsbedingten
Änderungen werden diese Verknüpfungen teilweise unterbrochen. 24
● Daten des Liegenschaftskatasters können bislang nicht ohne weiteres mit Daten
aus ATKIS (Amtlich Topographisch-Kartographisches Informationssystem)
verknüpft werden. 25
2.3 ALKIS – Das amtliche Liegenschaftskataster-
Informationssystem
Das neue Modell ALKIS berücksichtigt die modernen Anforderungen von vornherein
und löst somit die genannten Probleme. ALK und ALB werden zukünftig einheitlich
geführt und somit eine konsequente, objektbasierende Datenmodellierung realisiert. Als
Objekt zählt jeder „tatsächliche oder rechtliche Gegenstand der Wirklichkeit (...), der aus
fachlicher Sicht ein hinreichendes Eigenleben führt." 26
Die Modellierung der Datenstruktur sowie des Ausgabeformats folgt den Normen und
Standards der International Standardization Organisation (ISO) und des Open Geospatial
Konsortiums (OGC). 27
Diese systemunabhängige Modellierung von ALKIS ermöglicht die einfache Anbindung
beliebiger Fachanwendungen, wenn sie ebenfalls auf den internationalen Normen
basieren.
In ALKIS erhalten alle Objekte ein Lebenszeitintervall. Untergegangene Objekte
werden lediglich historisiert und weiterhin in der Datenbank geführt, so dass beliebige,
zurückliegende Situationen rekonstruiert werden können. 28 Sachdaten werden nicht mehr
über die Geometrie eines Objektes verknüpft, sondern über eine eindeutige Objektid,
24 Seifert 2000, S.14; Seifert 2004, S.27
25 http://www.hhk.de/produkte/gw/ALKIS.html vom 3.6.2006
26 Oswald/Rothberger 1998, S.14
27 http://www.lvermgeo.rlp.de/lv/aufgaben/ALKIS.html vom 3.6.2006
28 http://landesregierung.schleswigholstein.de/coremedia/generator/Aktueller_20Bestand/IM/
z__Katasteraemter/Information/Produkte/ALKIS.html vom 3.6.2006
17

welche auch bei Änderung des Objektes gleich bleibt. 29
2. Hintergründe
Die Daten in ALKIS werden zukünftig nicht mehr im inhomogenen Datenformat EDBS
ausgegeben, sondern im bundeseinheitlichen NAS-Format (Normierte Austausch-
schnittstelle). 30 Hierdurch wird ein länderübergreifender Austausch möglich.
Bei der Entwicklung dieser Schnittstelle wurden auch Wünsche und Konzepte der
Industrie berücksichtigt. Das NAS-Ausgabeformat realisiert nur ein Format unter weiteren
möglichen (wie z.B. auch DXF- oder Shapeformat). 31
Mit der Entwicklung von ALKIS wurde 1995 begonnen. 32 Im Juni 2000 entschied die
AdV spätestens ab 2005 ALKIS in ganz Deutschland zu implementieren. Die meisten
Bundesländer haben mit einer diesbezüglichen Realisierung auch schon begonnen, nach
unverbindlichen Hochrechnungen ist mit einer flächendeckenden Einführung jedoch
nicht vor 2007 zu rechnen. 33
Auch diese Schätzung ist jedoch mit Vorsicht zu genießen, da, wie oben geschildert, noch
nicht einmal in allen Bundesländern die ALK flächendeckend vorliegt.
Durch die integrierte Führung aller Daten des Liegenschaftskatasters ergeben sich
vielfältige Nutzungsmöglichkeiten sowohl im privaten als auch im öffentlichen Sektor.
Anwendungen liegen, genau wie im ALK-System, überall dort, wo rechtlich verbindliche,
aktuelle und genaue Geobasisdaten benötigt werden.
29 Seifert 2000, S.19
30 ebda, S.18; Seifert 2004, S.30
31 Seifert 2004, S.30
32 Oswald/Rothberger 1998, S.11
33 Seifert 2004, S.32
18

2.3.1 ALKIS-Datenkonzept
2. Hintergründe
Das objektorientierte Datenmodell des OBAK ist gegliedert nach 9 verschiedenen
Objektbereichen (siehe Abbildung 7). Diese enthalten auch interne Angaben zum
lesenden oder schreibenden Zugriff auf ALKIS-Daten (Bereich Nutzerprofile) oder zur
Überführung von ALK-Daten nach ALKIS (Bereich Migration).
Abbildung 7: ALKIS-Datenmodell
Quelle: Eigene Darstellung basierend auf dem Inhalt von AdV 2005a
Die Objektbereiche werden nach Objektartengruppen unterteilt, welche sich letztlich
in einzelne Objektarten aufgliedern. 34 Die Objektarten weisen Eigenschaften auf. Sind
dieses selbstbezogene Eigenschaften, so werden sie „Attribute" genannt. 35 Diese
enthalten bestimmte Werte.
34 AdV 2005a, S. III
35 Seifert 2000, S.14
19

2. Hintergründe
Sind die Eigenschaften der Objektarten fremdbezogen, so werden diese Relationen
genannt. 36 Objektarten können also auch Beziehungen zu anderen Objektarten aufweisen
(z.B. besitzt ein Gebäudeobjekt in der Regel eine Relation zu der Objektart
„Lagebezeichnung mit Hausnummer"). 37
Die Objektarten werden in verschiedene Objekttypen unterteilt, nämlich
„Raumbezogene Elementarobjekte“ (REO) (z.B. ein Flurstück, ein Gebäude), „Nicht
raumbezogene Elementarobjekte“ (NREO) (z.B. Sachdaten, Angaben zu Personen
(Eigentümer) und „Zusammengesetzte Objekte“ (ZUSO). 38 Letztere kommen in ALKIS
jedoch nur selten vor, zu nennen wären hier z.B. Gesamtgebäude, die aus einem Gebäude
und einem oder mehreren Bauteilen bestehen.
Dieses objektorientierte Datenmodell soll anhand eines Beispiels verdeutlicht werden:
Im Objektbereich „Tatsächliche Nutzung" existiert die Objektartengruppe „Vegetation".
Diese weist verschiedene Objektarten auf, unter anderem die Objektart „Landwirtschaft"
mit der Kennung 43001 (siehe Abbildung 8).
Abbildung 8: Beschreibung der Objektartengruppe Vegetation im ALKIS-
Objektartenkatalog
Quelle: Auszug aus AdV 2005a, S. 245
36 Seifert 2000, S.15
37 AdV 2005a, S.190
38 Oswald/Rothberger 1998, S.14
20

2. Hintergründe
Die Objektart „Landwirtschaft" wiederum weist unterschiedliche Attribute auf (z.B.
„Name" und „Vegetationsmerkmal"). Das Attribut „Vegetationsmerkmal" enthält
verschiedene mögliche, fest deklarierte Werte wie z.B. „Ackerland“, „Streuobstacker“,
„Hopfen“, „Spargel“ etc..
2.3.2 ALKIS-Gestaltungsgrundlagen
Wesentliche Grundlage für die Einheitlichkeit von Daten stellen rechtsverbindliche
Regelungen fest, welche im Rahmen von ALKIS von der AdV getroffen wurden.
2.3.2.1 Grunddatenbestand
Im sogenannten Grunddatenbestand wurde festgelegt, welche Daten von allen
Vermessungsverwaltungen der Länder bundeseinheitlich zu führen sind. 39
Alle Bundesländer müssen sich bei der Umsetzung von ALKIS an diesen Daten
orientieren. Der Grunddatenbestand stellt die Basis für ein länderübergreifend
einheitliches ALKIS dar und „ist sozusagen der kleinste gemeinsame Nenner der in
Deutschland geführten Daten im Liegenschaftskataster." 40
Mit diesem Datenbestand soll den rechtlichen, wirtschaftlichen und administrativen
Nutzeransprüchen an Geobasisdaten Genüge getragen werden. 41 Zu dem Datenbestand
gehören z.B. Flurstücke mit Attributen, Grenzpunkte, Grenzen (z.B. Kreis, Gemeinde,
Regierungsbezirk), Siedlungsflächen, Gebäude inkl. ihrer Funktion, Vegetationsflächen,
Gewässer, öffentlich-rechtliche Festlegungen sowie Angaben zu Personen (Eigentümer
von Flächen, Gebäuden etc.). 42
39 AdV 2005e, S. 9
40 Seifert 2000, S.21
41 AdV 2005e, S. 9
42 ebda, S.11 ff.
21

2.3.2.2 ALKIS-Objektartenkatalog
2. Hintergründe
Die Inhalte, Strukturen und Abbildungsvorschriften von ALKIS sind im
Objektartenkatalog sowie im Signaturenkatalog festgelegt. 43
Im Objektartenkatalog werden die in ALKIS zulässigen Grunddaten mit ihren
Eigenschaften beschrieben. 44 Zum Beispiel wird hier festgelegt, welche
Objektartengruppen (z.B. Gewässer, Siedlung, Verkehr, Vegetation) zu welchem
Objektbereich (z.B. Tatsächliche Nutzung) gehören und wie diese weiter unterteilt
werden.
2.3.2.3 ALKIS-Signaturenkatalog
Das Gegenstück zur ZV-Aut der ALK ist unter ALKIS der Signaturenkatalog.
„Der ALKIS Signaturenkatalog enthält die Vorgaben für die Präsentation von ALKIS-
Bestandsdaten (Präsentationsausgaben)." 45
Enthalten sind allgemeine Vorbemerkungen (Teil A), eine Signaturenbibliothek (Teil B;
enthält die vorkommenden Kartenzeichen gruppiert nach Fläche, Symbolen, Linien und
Schriften) sowie die Präsentation (Teil C; beschreibt die Regeln, nach denen die Objekte
präsentiert werden).
Ein Beispiel aus der Signaturenbibliothek (Teil B des Signaturenkatalogs) ist in Abbildung
9 auf der folgenden Seite zu sehen.
Wie dort zu erkennen ist, trägt das Symbol für „Wald“ z.B. die Signaturnummer 3457
und ist zusammengesetzt aus mehreren Einzelsymbolen.
Zu den Elementen finden sich präzise Angaben. Die Größe, Form und Lage der einzelnen
Elemente zueinander wird in einem kartesischen Koordinatensystem beschrieben (mit
Abszisse (x) und Ordinate (y)). Es finden sich Deklarationen zu der Form des
Linienabschlusses und zur Farbe des Objektes (angegeben werden der Farbgrundton
sowie die Euro-Skala-Farbanteile Cyan, Magenta, Yellow und Black in Prozent).
Auch werden Angaben zur Darstellungspriorität sowie zur Linienstärke festgelegt.
43 AdV 2005f S.10 ff.
44 ebda
45 AdV 2005b, S.3
22

Abbildung 9: Beispiel aus dem ALKIS -Signaturenkatalog (Teil B)
Quelle: AdV 2005c, S.200
2. Hintergründe
In der Präsentation (Teil C des Signaturenkatalogs) werden dann detaillierte Ab-
bildungsregeln präzisiert. Zum Beispiel wird festgelegt, dass eine Fläche, welche als
Streuobstacker ausgewiesen wird, mit der Linie der Signatur 2515 zu umranden ist und
außerdem die Signatur 3441 enthalten soll (siehe Abbildung 10). Auch finden sich
Angaben, wie weit einzelne Signaturelemente voneinander entfernt sein sollen (Angaben
erneut in 1/100 mm).
23

2. Hintergründe
Nicht zuletzt durch die äußerst detaillierte Form der Signaturenbibliothek sind die
Ausgabevorschriften in ALKIS wesentlich stringenter als in der ZV-Aut der ALK.
Abbildung 10: Beispiel für Darstellungsvorschrift im ALKIS-Signaturenkatalog (Teil
C)
Quelle: AdV 2005d: Seite 268
24

2.4 Open Source/Freie Software im Unterschied zu
proprietärer Software
2.4.1 Begrifflichkeiten und Konzepte
2. Hintergründe
In der Literatur werden die Begriffe „Open Source“ und „Freie Software“ vielfach
synonym verwandt. 46
Als Urheber Freier Software gilt allgemeinhin Richard Stallmann, welcher 1984 mit der
Entwicklung eines Betriebssystems basierend auf Freier Software begann. Der Name des
Betriebssystems lautet GNU, was für „Gnu is not Unix" steht.
Berichtet wird von einem Schlüsselerlebnis: Der Laserdrucker am Arbeitsplatz von
Richard Stallmann klemmte zuweilen. Stallmann wollte dieses Problem lösen und bat die
Firma XEROX um die Herausgabe des Quellcodes; allerdings erhielt er keine Erlaubnis,
diesen zu ändern. In Folge dessen überlegte er sich, wie man Kooperation und
Miteinander in diesem Sektor verbessern könnte. Als Basis dafür entstand ein
Betriebssystem basierend auf Freier Software. 47
Als juristische Körperschaft für GNU wurde im Jahre 1985 die FSF (Free Software
Foundation) gegründet. Laut dieser Institution definiert sich Freie Software durch die
Gewährleistung der folgenden vier Freiheiten: 48
● Freiheit der unbegrenzten Nutzung für jeden Zweck
● Freiheit des Studiums der Funktionsweise der Software für Anpassungen an
eigene Bedürfnisse
● Freiheit der Weitergabe der Software auch durch Kopie
● Freiheit der Veränderung der Software und der Weitergabe der Veränderungen
Um diese Freiheiten zu gewährleisten, muss selbstverständlich der Source Code offen
vorliegen.
Der Begriff „Freie Software" wurde und wird oft missverstanden. So wird gemutmaßt,
46 Z.B. CCGIS/terrestris 2004, S.10ff.; Möller 2005, S.62f.; Schönbuchner/Unterpaintner 2005, S.42;
http://de.wikipedia.org/wiki/Open-Source vom 25.5.2006
47 Feller 2002, S.32
48 http://www.fsf.org/licensing/essays/free-sw.html vom 24.4.2006
25

2. Hintergründe
diese Software sei per se unkommerziell, was so nicht stimmt. Ein freies Programm muss
auch für den kommerziellen Gebrauch, die kommerzielle Entwicklung und für die
kommerzielle Verteilung zur Verfügung stehen. Um das Konzept Freier Software zu
verstehen, ist an „frei" wie z.B. in freier Rede, nicht aber wie in „Freibier" zu denken. 49
Der Terminus „Open Source" entstand Anfang 1998 um Gerüchte und Missverständnisse,
die um Freie Software kursierten, auszuräumen. 50
Mit dem Begriff „Open“ sollte die Assoziation „umsonst“ vermieden und eher „offen
für alles“ verstanden werden. 51
Open Source stellte anfänglich nur die Offenlegung des Quellcodes in den
Vordergrund. Mit dem Begriff sollte ein Symbol, ein Dach, ein gemeinsamer Nenner für
alles dargestellt werden, was Freie Software charakterisiert. Es sollten klare, pragmatische
Ziele gesetzt werden, die auch und gerade für die Industrie erstrebenswert wären. Der
Begriff „Freie Software" wurde in den Vorstandsetagen und Aktionärsversammlungen von
Unternehmen oftmals mit großen Vorbehalten aufgenommen. „"Free" ist nicht nur
zweideutig („Freibier" und „Freie Rede"), sondern offensichtlich war es in The Land of the
Free zu einem unanständigen, „konfrontationellen", irgendwie kommunistisch klingenden
four-letter word geworden." 52
Die Open-Source-Initiative, Initiator des neuen Begriffes, nennt ganz eindeutig
pragmatische Gründe für die Einführung des Open-Source-Begriffes:
„The Open Source Initiative is a marketing program for free software. It's a pitch for "free
software" on solid pragmatic grounds rather than ideological tub-thumping. The winning
substance has not changed, the losing attitude and symbolism have." 53
Es geht hierbei eher um eine technische Herangehensweise, um die Hervorhebung der
pragmatischen Aspekte wie Nützlichkeit, Zuverlässigkeit und Effizienz der Software. 54
Idealistische Vorstellungen von Freiheit, Prinzipien und Community geraten hierbei
49 http://wiki.unixboard.de/index.php/Freie_Software vom 20.5.2006
50 Feller 2002, S.38; http://de.wikipedia.org/wiki/Open_Source vom 27.5.2006
51 Müller/Snoopy 1999, S.9
52 Grassmuck 2002, S.230
53 http://www.opensource.org/advocacy/faq.php vom 24.5.2006
54 Grassmuck 2002, S.231
26

jedoch in den Hintergrund.
2. Hintergründe
REITER bringt es auf den Punkt: „Aus der (..) Historie heraus beschränkt sich Open Source
auf die Betrachtung der Technik und Entwicklungsmethode. Freie Software geht weit
darüber hinaus und betrachtet kulturelle Effekte und die Auswirkungen auf die
Gesellschaft." 55
Tatsächlich hat die Einführung des Begriffes „Open Source" zwar dazu beigetragen,
dass auch Vertreter der Wirtschaft ihren Fokus stärker auf Freie Software setzen,
dennoch wurde mit diesem Begriff zusätzliche Verwirrung gestiftet. Ein offen gelegter
Quelltext garantiert noch längst nicht alle vier Freiheiten. 56
GRASSMUCK schreibt: „Der Versuch der OSI, das Warenzeichen „Open Source" als
Gütesiegel für Software durchzusetzen, deren Lizenz der Open Source-Definition genügt, ist
gescheitert. Heute führen viele Produkte das Label, die keine Modifikationsfreiheit
gewähren (...)." 57
So nennt die „PGP Corporation“ die aktuelle Version ihres Kryptografieprogramms PGP
z. B. „Open Source“, da der Quellcode betrachtet werden kann. Weitergabe und
Veränderung dieses Quellcodes sind aber verboten. 58
Die Einführung des Open-Source-Begriffes hat durch seine teilweise beliebige
Verwendung partiell zu einer Unterwanderung der eigentlichen Prinzipien Freier Software
geführt. Man kann davon sprechen, dass die Grundsätze Freier Software
teilweise „verwässert“ wurden.
Obwohl in der Literatur beide Begriffe oftmals synonym verwandt werden, wird
dennoch vielfach eine Spaltung der beiden Gruppen explizit hervorgehoben 59
und eine bewußte, ideologisch geprägte Verwendung der jeweiligen Begrifflichkeiten
benannt. Aus diesem Widerspruch wird deutlich, dass eine klare semantische Zuordnung
oder aber Abgrenzung dieser Begriffe nicht ganz einfach ist.
55 Reiter 2004, S.85
56 ebda; Grassmuck 2002, S.231
57 Grassmuck 2002, S.231; ähnlich auch Feller 2002, S.63
58 http://de.wikipedia.org/wiki/Open-Source vom 18.5.2006
59 Grassmuck 2002, S.232; Williams 2002, S.155 ff.
27

2. Hintergründe
Der Unklarheit und Verwässerung des Open-Source-Begriffes soll an dieser Stelle jedoch
ausdrücklich ein Riegel vorgeschoben werden. Wenn im Folgenden von Open-Source-
Software gesprochen wird, dann ist explizit Software gemeint, deren Lizenzen auch
definitiv unter die Open-Source-Definition der OSI (Open-Source-Initiative) fallen.
Das bedeutet nach der OSI-Definition im Wesentlichen Folgendes: 60
● Die Lizenz darf niemanden in Verkauf oder Weitergabe der Software
einschränken.
● Der Programmcode liegt in einer für den Menschen lesbaren und
verständlichen Form (Quellcode) vor, darf aber auch als Binärcode
weitergegeben werden.
● Für Open-Source-Software darf es keine Nutzungsbeschränkungen geben.
● Die Lizenz muss die Veränderung des Programms, der auf dem Programm
basierende Werke sowie deren Verbreitung unter den gleichen
Lizenzbedingungen gestatten.
● Es darf keine Einschränkung für bestimmte Anwendungsbereiche geben, auch
darf die Lizenz, unter welcher die Software veröffentlicht wird, keine
Personen oder Gruppen diskriminieren.
Sofern unter Open Source auch tatsächlich Produkte verstanden werden, welche unter
die OSI-Definition fallen, sind diese den Produkten Freier Software recht ähnlich.
MÖLLER hebt hervor: „So fallen die meisten Software-Lizenzen unter beide Definitionen
oder unter keine von beiden.“ 61
Diese Meinung vertritt auch WICHMANN, 62 so schreibt er: „Für praktische Zwecke
beschreiben die Begriffe fast das gleiche, so gut wie alle von der maßgeblichen Open-
Source-Initiative bestätigten Open Source-Lizenzen sind auch als Lizenzen für Freie
60 http://www.opensource.org/docs/definition.php vom 22.5.2006
61 Möller 2005, S.62
62 Wichmann 2005, S.5
28

Software anerkannt.“ 63
2. Hintergründe
Aufgrund dieser Ähnlichkeit und der oftmals verwendeten Synonymität 64 werden auch in
dieser Diplomarbeit die Begriffe „Open Source“ und „Freie Software“ einheitlich
verwandt.
Proprietäre Software im Gegensatz dazu stellt Software dar, welche ursprünglich dem
Produzenten gehört.
„Proprietär beschreibt den Zustand, bei dem ein Individuum oder eine Firma die exklusiven
Rechte an einer Software hält und anderen gleichzeitig Zugang zum Quelltext, das Recht
die Software zu kopieren, verändern oder zu studieren verbietet.“ 65
Dem Nutzer ist es in der Regel durch eine monetäre Gegenleistung erlaubt, einzelne,
individuelle oder temporäre Nutzungsrechte zu bekommen. Änderungen oder
Anpassungen dieser Software sind oftmals schlichtweg nicht möglich, da der Quellcode
nicht einsehbar geschweige denn veränderlich ist.
2.4.2 Freie Software/Open Source und Lizenzen
Auch wenn Software kostenlos ist und die genannten Freiheiten garantiert, so kann sie
durchaus eine Lizenz beinhalten.
Eine sehr häufig im Zusammenhang mit Open-Source-Software genannte Lizenz ist die
GNU General Public License (GNU GPL). Diese wurde von Richard Stallmann gemeinsam
mit einem Rechtsprofessor entwickelt. Die GNU GPL stellt explizit sicher, dass Software,
welche unter dieser Lizenz veröffentlicht wird, auch frei bleibt.
Verändert ein Nutzer ein Programm, welches unter der GNU GPL veröffentlicht wurde,
so muss auch dieses Programm wieder unter der GNU GPL veröffentlicht werden. Genau
diese Eigenschaft macht diese Lizenz relativ ungeeignet für kommerzielle Software, d.h.,
wenn der Quellcode in irgendeiner Form geschützt werden soll, stellt die GNU GPL
automatisch ein Veto dar.
63 Wichmann 2005, S.7
64 z.B. in CCGIS/terestris 2004; auch in: Schönbucher/Unterpaintner 2005
65 http://de.wikipedia.org/wiki/Propriet%C3%A4re_Software vom 27.5.2006
29

2. Hintergründe
Eine weitere Lizenz, wie z.B. die GNU Lesser General Public License (GNU LGPL) schützt
diese Freiheit relativ gesehen schwächer.
Die Software darf als Baustein für proprietäre Software verwendet werden. Dieser
Baustein bliebt frei, das Gesamtprodukt nicht unbedingt. 66
2.4.3 Freie Software/Open Source und proprietäre Software im
Vergleich
Die Prinzipien von Freier Software/Open Source und proprietärer Software können kaum
unterschiedlicher sein. GRASSMUCK schreibt:
„Mit der freien und der proprietären Software stehen sich zwei grundlegend verschiedene
Auffassungen über das Wissen gegenüber. Hier der Quelltext als ein in geschlossenen
Gruppen, unter Vertraulichkeitsverpflichtung gefertigtes Masterprodukt, das in
geschlossener, binärer Form vermarktet und mit Hilfe von Urheberrechten, Patenten,
Markenschutz und Kopierschutzmaßnahmen vor Lektüre, Weitergabe und Veränderung
geschützt wird. Dort der Quelltext als in einer offenen, nicht gewinnorientierten
Zusammenarbeit betriebener Prozess, bei dem eine ablauffähige Version immer nur eine
Momentaufnahme darstellt, zu deren Studium, Weitergabe und Modifikation die Lizenzen
der freien Software ausdrücklich ermutigen. Hier eine Ware, bei dem Konsumenten vom
Produzenten verkauft wird, dort ein kollektives Wissen, das allen zur Verfügung steht. Hier
konventionelle Wirtschaftspraktiken, die tendenziell immer auf Verdrängung und
Marktbeherrschung abzielen. Dort ein freier Wettbewerb um Dienstleistungen mit gleichen
Zugangschancen zu den Märkten." 67
Bezogen auf verschiedene Bereiche sollen die Unterschiede zwischen diesen
grundverschiedenen Softwareparadigmen nun hervorgehoben werden.
66 Reiter 2004, S.86
67 Grassmuck 2002, S.235
30

2.4.3.1 Wirtschaftsfaktor
2. Hintergründe
Die Entwicklung proprietärer Software schafft eine Vielzahl von Arbeitsplätzen.
Programmierer, Marketingspezialisten, Juristen und zahlreiches weiteres Personal arbeiten
für Firmen, welche Software entwickeln, deren Quellcode nicht der Öffentlichkeit
zugänglich ist.
Freie Software kann ebenfalls als gesellschaftlicher Wirtschaftsfaktor gesehen werden.
Gezahlt wird jedoch üblicherweise für eine Dienstleistung wie z.B. Entwicklung, Schulung
und Support und nicht für den direkten Zugang zu dem Produkt selber.
Eine Vielzahl von Freien Softwareprodukten wird für Geld entwickelt, sei es um eine
Software an bestimmte Anforderungen zu adaptieren oder um ein eigenes, neues
Produkt zu entwickeln.
Das Vorurteil, Freie Software würde fast ausschließlich von Freizeitprogrammieren
entwickelt, wird dadurch obsolet, dass annähernd 40% der bestehenden Freien Software
von Entwicklern im Hauptberuf entwickelt wird. 68
Nach einer Studie des Investment-Dienstleisters WR Hambrecht + Co wurde das mögliche
Marktpotential von mit Freier Software zu verdienenden Einnahmen auf 12 Milliarden US
Dollar geschätzt; gar wird hier von einem möglichen lawinenartigen Anwachsen des
diesbezüglichen Softwaremarktes gesprochen. 69
Dennoch ist festzuhalten, dass zum jetzigen Zeitpunkt proprietäre Software im
Vergleich stärker genutzt und somit auch einen größeren Wirtschaftsfaktor als Freie
Software darstellt, die Unterschiede werden jedoch spürbar geringer. Laut des „FLOSS-
Berichtes“ (Free/Libre and Open-Source-Software: Survey and Study) aus dem Jahre 2002
wurde von 44,4% aller befragten öffentlichen und privaten Institutionen Open-Source-
Software bereits verwendet oder aber diese Verwendung geplant. 70
68 Feller 2002, S.144; Reiter 2004, S.88
69 Grassmuck 2002, S.338
70 Möller 2005, S.95
31

2.4.3.2 Entwicklerprozess
2. Hintergründe
Bezogen auf den Entwicklerprozess weist Freie Software einige Vorzüge im Vergleich
zu proprietärer Software auf. Hier kann bezogen auf viele Projekte von einer Kultur der
Kooperation gesprochen werden. In der Regel haben eine Vielzahl von Menschen Zugriff
auf den sich entwickelnden Quelltext, auf Mailinglisten, Foren und projektrelevante
Entscheidungen. Freie Software bietet eine gute Möglichkeit, dass ein Produkt im Dialog
entsteht und vielfältige Erfahrungen einfließen. 71
„Freie Software fördert eine pragmatische Querkommunikation zwischen den Beteiligten.
So kann der erfahrene Benutzer u.U. direkt in einem Forum mit dem Entwickler Kontakt
aufnehmen, ohne einen Umweg über die Marketingabteilung machen zu müssen.“ 72
Proprietäre Software wird aus verständlichen Gründen in der Regel „geschlossen"
entwickelt. Der Nachteil hiervon ist, dass das technische Knowhow von den Fähigkeiten
der beauftragten Softwareentwickler abhängig ist, der Wissenspool ist also per se
begrenzt.
Anzumerken ist, dass mittlerweile auch einige proprietäre Hersteller die Vorteile und das
Image einer offenen Entwicklung nutzen. Als Beispiele sind Microsofts "Shared
Source"-Programm und ATT (AT&T Public License) zu nennen. 73
2.4.3.3 Leistung
Kaum eine Software leistet zu 100% das, was ihre Anwender sich wünschen. Durch
Freie Softwareprodukte ist es möglich, dass Anwender die Leistung durch Veränderungen
im Quellcode an ihre Bedürfnisse anpassen, was natürlich ein gewisses technisches Know-
how voraussetzt. 74 Fehler können eigenständig oder in Gemeinschaft mit anderen
Nutzern behoben werden, die Software wird dadurch komplexer und leistungsfähiger
während proprietäre Software allein von dem Engagement der sie produzierenden Firma
bzw. einem kapitalschweren Auftraggeber abhängt.
„Modifikationen an proprietärer Software sind technisch nur schwer möglich und
71 Christl/Trakas 2004, S.75; Müller/Snoopy 1999, S.11
72 Reiter 2004, S.89
73 ebda., S.87
74 Christl/Trakas 2004, S.77
32

lizenrechtlich nicht erlaubt." 75
2. Hintergründe
Softwareprodukte enthalten immer auch Fehler, welche nach einer Motte, die 1945
einen Hardwarekurzschluss verursachte, als „Bug“ bezeichnet werden. Einer
Informatikerfaustregel steckt in jedem Programm pro 100 Zeilen ein Bug.
Anbieter proprietärer Software haben natürlich große Schwierigkeiten, Bugs in ihren
Programmen zuzugeben. Freie Software/Open Source hingegen kann sich ohne weiteres
diesem Problem stellen. Die Tatsache, dass in einem gemeinsamen Entwicklerprozess eine
Vielzahl von Anwendern Fehler öffentlich machen können (z.B. über Foren, Mailinglisten)
und gemeinsam die Fehler beseitigt werden können, führt zu größerer Stabilität und
auch einem schnelleren Beseitigen von Defiziten. 76
Tatsächlich weisen viele Open-Source-Produkte einen Performanzvorteil im Vergleich zu
proprietärer Software auf. 77
Im Gegensatz dazu steht auf „proprietäre Seite" die althergebrachte Methode, die
Fehlerbeschreibungen der Nutzer nachzuvollziehen, den Fehler zu suchen, und die
Korrektur wiederum vom Nutzer testen zu lassen. 78
„Wenn Sie einen Fehler melden, sind Sie der Gnade und dem Zeitplan des Sachbearbeiters
für die Fehlermeldung ausgeliefert - wenn Sie überhaupt eine Antwort erhalten." 79 Schon
aus dieser kurzen Beschreibung wird ersichtlich, welche der beiden Methoden die
effizientere ist.
Zu dem Leistungsspektrum einer Software gehören nicht allein die technischen
Komponenten des Programms sondern auch die Betreuung durch Support.
Kommerzielle Firmen bieten in der Regel Supportverträge für ihre Softwareprodukte an.
Für eine Vielzahl von Freien Softwareprodukten gibt es jedoch mittlerweile auch
Unternehmen, welche gegen Entgelt Unterstützung und Beratung offerieren.
Der Support durch Mailinglisten, Foren oder in Literatur und Internet verfügbaren
75 Grassmuck 2002, S.235
76 ebda., S.243
77 Wichmann 2005, S.53
78 Müller/Snoopy 1999, S.11
79 Bowen/Coar 2000, S.34
33

2. Hintergründe
Anleitungen hängt wesentlich von der Anzahl der Nutzer eines Programmes ab. Freie
Software hat hier den Vorteil, dass sie keine Nutzer ausschließt, per se allen zur
Verfügung steht und sogar zur Unterstützung ermuntert.
Kritisch anzumerken ist jedoch, dass die qualitative Spanne bei Freier Software
aufgrund der Vielfalt weit größer als bei proprietären Produkten ist, so schreibt z.B.
REITER: „Es gibt mehr Spitzenprodukte und mehr Schrott." 80
2.4.3.4 Abhängigkeit
Software impliziert immer eine gewisse Abhängigkeit von den Entwicklern des
jeweiligen Produktes. Bei Freier Software jedoch ist es möglich, selber in das Produkt
„einzusteigen" und diese Abhängigkeit zu verringern oder gänzlich aufzulösen. Die
Option auf das Erlernen und Entwickeln Freier Software ist viel leichter und eher gegeben
als bei proprietärer Software.
WICHMANN hebt hervor: „Ein wesentlicher strategischer Aspekt von Open-Source-
Software ist eine größere Unabhängigkeit der Nutzer von den Softwareanbietern(...).“ 81
Bei kommerziellen Softwareprodukten kann man schon einmal direkt von der
produzierenden Firma abhängig sein, was bei einer Monopolisierung tiefgreifende
Konsequenzen haben kann. Ein gutes Beispiel stellt folgende Anekdote dar:
Um seine eigene, recht spezielle Schrift auch in der digitalen Welt zu bewahren, stellte
Island 1998 eine Bitte an Microsoft, eine Schnittstelle für Isländisch zu implementieren. Es
war sogar bereit für diese Arbeit zu zahlen. Microsoft sah den Markt als zu klein an und
lehnte ab. Der Zugang zum Quellcode war nicht vorhanden, auch hätte es keine
rechtliche Möglichkeit gegeben, ihn zu verändern, so gesehen bestand eine völlige
Abhängigkeit von Microsoft. Die Folge dieses Verhaltens war übrigens, dass ein Projekt
zur Unterstützung von Isländisch in GNU/Linux gestartet wurde und öffentliche
Verwaltung und viele Isländer komplett auf das freie Betriebssystem migrierten. 82
80 Reiter 2004, S.89
81 Wichmann 2005, S.54
82 Grassmuck 2002, S.318
34

2.4.3.5 Wissensverbreitung
2. Hintergründe
Die Freilegung des Quellcodes und die Möglichkeit, ein Programm individuell zu
verbessern, motiviert Menschen, sich mit der Software(programmier)thematik
auseinander zu setzen und sich weiterzubilden. Wissen ist ein gesellschaftliches Gut einer
Gemeinschaft. Hinter Freier Software steckt auch die Idee, dass Wissen multipliziert wird
durch die Verbreitung von Wissen.
Computer werden immer mehr zu einer Kulturtechnik. Über sie bestimmt sich, wer
Zugang zum Wissen der Gesellschaft hat. Anwender und Entwickler haben in diesem
Sinne gleichermaßen eine hohe Verantwortung. Es geht darum, Wissen zu lehren,
weiterzuverbreiten und zu entwickeln.
Freie Software/Open Source wird dieser Verantwortung gerecht, proprietäre Software
hingegen scheitert an diesem Anspruch zumindest partiell.
Freie Software schließt niemanden aus; die Möglichkeit, selbstverwaltet und autonom
Programme zu gestalten, wird gefördert.
Dadurch, dass niemand „direkt" verantwortlich für ein Programm ist (wie z.B. ESRI für
ArcIMS) bilden sich Gemeinschaften, welche sich mit der Anwendung und Entwicklung
eines Projektes auseinandersetzen. Ein Beispiel dafür ist die Mailingliste der Seite
„http://www.umn-mapserver.de“ oder aber das Forum auf „http://www.umn-mapserver-
community.de“.
Natürlich gibt es auch sehr sinnvolle Anwenderforen für proprietäre Software,
allerdings setzen diese voraus, dass das jeweilige Programm zuvor kostenpflichtig
erworben wurde. Teile der Gesellschaft werden nicht zuletzt in einer Zeit hoher
Arbeitslosigkeit und Hartz IV von diesen Produkten schlichtweg ausgegrenzt.
Freie Software/ Open Source fördert also eigenverantwortliches Arbeiten, natürlichen
Wissenstransfer und direkte Kommunikation. Faktoren, von denen jede Gesellschaft
profitieren kann. „Freie Software sorgt für faire (...) Spielregeln." 83
83 Reiter 2004. S.87
35

2.4.3.6 Kostenfaktor
2. Hintergründe
Letztlich ist Freie Software kostensparender als proprietäre Software (siehe Abbildung
11).
Abbildung 11: Gesamtbetriebskostenvergleich im Laufe der Zeit. Vergleich zwischen
Freier Software/Open Source und proprietärer Software
Quelle: Reiter 2004, S.89
Beim Ankauf bzw. der Anschaffung ist sie in der Regel günstiger, 84 kann dann
allerdings durch Schulung- und Anpassungsbedarf recht kostenintensiv sein. Mittel- bis
langfristig lassen sich die Kosten allerdings deutlich senken, nicht zuletzt auch durch rege
Entwickler- und Anwendergemeinschaften, welche bestimmte Änderungen entwickeln.
Auch an dieser Stelle soll ein anschauliches Beispiel den Unterschied der Kosten
zwischen Freier und proprietärer Software verdeutlichen:
Ende 1998 machte die mexikanische Regierung Pläne öffentlich, welche beinhalteten, in
den folgenden Jahren GNU/Linux an 140.000 Schulen im ganzen Land mit nahezu 20
Millionen Schülern einzuführen. Das Projekt beinhaltete Web- und Emailzugang,
Textverarbeitung, Tabellenkalkulation und den Zugang zu einer digitalen Bibliothek.
Die Projektleitung begründete ihre Entscheidung für GNU/Linux auch mit den deutlich
geringeren Kosten im Vergleich zu proprietärer Software. Die Kosten für kommerzielle
84 Wichmann 2005, S.34 ff.
36

2. Hintergründe
Lösungen wären nicht finanzierbar gewesen. „Eine Microsoft-Lösung hätte das Land 124
Millionen Dollar gekostet." 85
Abbildung 12: Vergleich zwischen Freier Software/OS und proprietärer Software
Bereich Freie Software/OS Proprietäre Software
Entwicklerprozess + 0
Leistung + +
Geringe Abhängigkeit + -
Kostenfaktor;
Wirtschaftlichkeit des
Produktes
Schaffung von
Arbeitsplätzen,
gesellschaftlicher
Wirtschaftsfaktor
+ 0
0 +
Wissensverbreitung + 0
Quelle: Eigene Darstellung
Zusammenfassend werden in einer Übersicht (Abbildung 12) Freie Software/Open Source
und proprietäre Software gegenübergestellt. Diese werden von „-“ (negativ) über „0“
(neutral) bis „+“ (positiv) bewertet. Nach Auffassung des Autors ist als Gesamtresultat
Freie Software/Open Source gegenüber proprietärer Software vorzuziehen, wodurch nun
deutlich wird, warum im FreeZVAUT-Projekt ausschließlich Freie Software/Open Source
verwendet wird.
85 Grassmuck 2002, S.323
37

2. Hintergründe
2.4.4 Vergleich zweier Mapserver aus dem Freie Software/Open-
Source-Bereich sowie dem proprietären Sektor
Nachfolgend sollen nun als Beispiel für Software aus dem Bereich der
Geoanwendungen der UMN Mapserver und als proprietäres Gegenstück ArcIMS
verglichen werden.
2.4.4.1 UMN Mapserver
Der UMN Mapserver ist ein interaktiver Mapserver. Dieser dient der individuellen,
unmittelbaren und interaktiven Erstellung und Visualisierung von Geoinformationen in
Form von Karten über das Internet. 86
Das Programm ist äußerst flexibel. Der Mapserver lässt sich für die meisten UNIX/Linux-,
Microsoft Windows- und auch Macintosh-Betriebssysteme kompilieren, 87 und kann in
verschiedene Webserver integriert werden.
Der UMN Mapserver zeichnet sich durch hohe Stabilität und Geschwindigkeit aus und
ist mit geringem Aufwand konfigurierbar. 88
Die notwendigen Standardfunktionen wie Navigation oder Abfragen sind gewährleistet
und können durch Programmiersprachen und Tools ausgebaut werden.
Die technische Anwendung ist nicht zuletzt aufgrund verschiedener Anleitungen im
Internet sowie verfügbarer Literatur relativ einfach; die Installation gestaltet sich mit
überschaubarem Aufwand.
Die Software ist kostenlos. Das Programm kann in Form von Quellcode oder
Binärpaketen aus dem Internet geladen werden. 89
Hinter dem UMN Mapserver steht eine große Entwicklergemeinde; dieses bedeutet,
dass der Mapserver einer stetigen Verbesserung und Weiterentwicklung unterliegt.
Die Folge ist ein zeitgemäßes und aktuelles Programm.
Zwischen der Version 3.5.0 (freigegeben am 28.12.2002) und der Version 4.6.0
86 Schönbuchner/Unterpaintner 2005, S.43 nach Fürpaß 2001
87 Frick 2004, S.147; http://www.umn-mapserver.de vom 23.5.2006
88 Schönbuchner/Unterpaintner/ 2005, S.46; http://www.umn-mapserver.de vom 23.5.2006
89 http://mapserver.gis.umn.edu/download/current vom 23.5.2006
38

2. Hintergründe
(veröffentlicht am 14.6.2005) wurden 10 (Beta-)Versionen veröffentlicht. Über 200
Verbesserungen (z.B. Integration neuer Bibliotheken für die Integration zusätzlicher
Datenformate, verbesserte Skalierungsanwendung, zusätzliche Mapscriptfunktionen etc.)
wurden in dieser Zeit integriert. 90
Mittlerweile gibt es diverse Anleitungen zur Anwendung des UMN Mapservers im
Internet. Auch der Autor dieser Diplomarbeit betreibt eine Homepage (http://www.umn-
mapserver-community.de), in welcher ein Forum integriert ist und von Zeit zu Zeit
Anleitungsskripte veröffentlicht werden.
Auf der Mailingliste von „http://www.umn-mapserver.de“ sind mittlerweile über 1000
User eingetragen. 91 Eine große Fülle von auftretenden Fragen werden über die
Mailingliste und das Forum beantwortet.
Die Zahl der Anwender des UMN Mapservers ist in den letzten Jahren stark gestiegen,
so heißt es in dem offenen Brief der Mapserver Foundation:
„In wenigen Jahren hat sich die Verbreitung von Mapserver verzehnfacht." 92
Mit der Anzahl der Nutzer steigt auch die Anzahl der Hilfestellungen, wodurch eine
Anwendung des Programmes stetig vereinfacht wird. Auch verbessert eine wachsende
Anwenderzahl durch die umfangreiche Anwendung immer auch die Qualität einer
Software. 93
Mittlerweile gibt es diverse Firmen, welche kommerziellen Support für den Mapserver
anbieten. 94
Der UMN Mapserver befolgt die Standards des OGC und kann auch als WMS (Web
Mapping Server) bzw. WFS (Web Feature Server) eingesetzt werden.
90 siehe HISTORY.TXT im Quellcode des UMN Mapserver-Hauptverzeichnisses
91 Schönbuchner/Unterpaintner 2005, S. 45
92 http://mapserverfoundation.org/open_letter_de.pdf vom 12.11.2005
93 Christl 2004, S.78
94 z.B. Intevation GmbH, CCGIS, MapMedia etc.
39

2.4.4.2 ArcIMS
2. Hintergründe
ArcIMS ist eine proprietäre Mapserverlösung, welche von der ESRI Geoinformatik
GmbH vertrieben wird. Auch ArcIMS ist ein interaktives System, in welches zahlreiche
GIS-Komponenten integriert werden können. Es existieren verschiedene Anbin-
dungsmöglichkeiten, welche über eine Internetvisualisierung hinausgehen, allerdings aber
auf die ESRI-Produktpalette beschränkt bleiben. 95
Die zu visualisierenden Geodaten können über Schnittstellen durch ArcGIS-Desktop-
Produkte, ArcPad und auch drahtlose Geräte wie WAP-Handys oder PDA-Geräte
visualisiert werden. 96 ArcIMS verfügt sowohl über Server als auch über
Clientkomponenten (z.B. Java Viewer, HTML-Viewer).
Die Serverarchitektur wird durch Abbildung 13 verdeutlicht.
Abbildung 13: Serverarchitektur des ArcIMS
Quelle: http://www.gwdg.de/forschung/publikationen/gwdg-nr/GN0311/gn0311_04.html vom 20.5.2006
Eine einzelne Lizenz kostet ca. 7500 US Dollar. 97
ArcIMS kann, genau wie der UMN Mapserver, als OGC-konformer WMS bzw. WFS
95 Projektgruppe Studienprojekt Wesermarsch 2005, S.82
96 http://www.esri-germany.de/products/arcims/index.html vom 20.5.2006
97 Projektgruppe Studienprojekt Wesermarsch 2005, S.82
40

2. Hintergründe
eingesetzt werden. In dem Produkt sind alle Standardgisfunktionalitäten (Zoom, Panning,
Abfragen) integriert. Diese können vielfältig erweitert werden.
So steht auf der Homepage des ESRI-Projektes:
„Zudem können kundenspezifische und erweiterte Dienste und GIS Funktionen eingebaut
werden." 98
ArcIMS kann eine sehr hohe Anzahl an Serveranfragen beantworten, das
Leistungsspektrum ist als sehr hoch anzusehen. Eine besonders attraktive Funktion bietet
das Programm an, indem es ermöglicht, geografische Daten, welche als Download
angefordert werden, direkt als Shapefile auszuliefen. 99
Die Dokumentation zu ArcIMS ist als gut zu bezeichnen. 100
ArcIMS kann auf Windows und Unixsystemen implementiert werden. 101 Macintosh bleibt
allerdings außen vor.
Eine dem UMN Mapserver vergleichbare Entwickler- bzw. Anwendergemeinschaft gibt
es allerdings nicht, in diesem Sinne ist die kostenlose Unterstützung „von außen" also als
deutlich schlechter anzusehen. Allerdings gibt es auch hier verschiedene Firmen, welche
kommerzielle Schulungen zu diesem Produkt anbieten. 102
Bei dem ArcIMS liegt der Quellcode nicht offen vor und kann/darf nicht ohne
weiteres verändert werden, was Modifikationen des Programmes ungleich schwerer
macht.
In diesem Sinne muss von einer Abhängigkeit von den Entwicklern des Programmes
gesprochen werden.
Aus Sicht des Autors sprechen im Vergleich der beiden Produkte insbesondere der
Kostenfaktor, die regen Anwender- und Entwicklergemeinschaften als auch die
Unabhängigkeit vom Anbieter für einen Einsatz des UMN Mapservers.
98 Projektgruppe Studienprojekt Wesermarsch 2005, S. 82.
99 http://www.esri-germany.de/products/arcims/index.html vom 20.5.2006
100 Projektgruppe Studienprodukt Wesermarsch 2005, S.82
101 ebda.
102 z.B. die Firmen conTerra; Alta4 Geoinformatik AG; Giscon etc.
41

2.5 Das Projekt FreeZVAUT
2. Hintergründe
Indirekte Vorläufer des Projektes stellen Daten dar, welche von der Firma CCGIS aus
Bonn im Rahmen eines Open-Source-Projektes veröffentlicht wurden. 103 Es handelt sich
hier um Teildaten aus dem Mapbender-Projekt, welche für ein bestimmtes Gebiet eine
ZV-Aut-konforme Darstellung der Liegenschaftskarte gewährleisten sollen. Diese Daten
wurden innerhalb des FreeZVAUT-Projektes teilweise übernommen, erweitert und
modifiziert.
Offiziell wurde das Projekt FreeZVAUT am 24. Januar 2006 bekannt gegeben. 104
Die Vorarbeiten zu diesem Zeitpunkt liefen aber schon seit September 2005.
Initiiert wurde es vom einem der Geschäftsführer der Intevation GmbH, Dr. Jan-Oliver
Wagner, der Intevationmitarbeiterin Silke Reimer sowie dem Autoren dieser
Diplomarbeit.
Mit FreeZVAUT geht es darum, mittels Freier Software/Open Source ALK-Daten ZV-
Aut-konform im UMN Mapserver darzustellen. Datenquelle sind EDBS-Daten, welche
durch den EDBS-Konverter Edbsilon in ein für den UMN Mapserver lesbares Format
umgewandelt werden (zunächst wurde im FreeZVAUT-Projekt mit Shapefiles gearbeitet;
im Laufe der Diplomarbeit fiel dann aber aufgrund der besseren Performanz die
Entscheidung, die Daten in eine PostgreSQL/PostGIS-Datenbank einzulesen).
Als Zeichenvorschrift wird die ZV-Aut aus Nordrhein-Westfalen verwendet. Die
Entscheidung hierfür wurde gefällt, da diese auch schon im Projekt von CCGIS die
Grundlage der Symbolerstellung war und außerdem frei im Internet zu erhalten ist. 105
Generell gestaltet es sich sehr schwierig, ALK-Testdaten kostenlos zu erhalten. Nach
einigen Verhandlungen wurden solche freundlicherweise von der LG (Landesvermessung
und Geobasisinformation) Brandenburg zur Verfügung gestellt. Die Erlaubniserklärung ist
auf der Internetseite
103 siehe: http://sourceforge.net/project/showfiles.php?group_id=88554 vom 18.3.2006
104 http://intevation.de/pipermail/mapserver-de/2006-January/001946.html vom 24.1.2006
105 http://www.lverma.nrw.de/produkte/druckschriften/verwaltungsvorschriften/images/zvaut/TC
AUT_NRW.zip vom 28.5.2006
42

2. Hintergründe
„https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/data/alk-vektor-testdaten-
lgb-brandenburg/lizenz-lgb.pdf?rev=34&root=freezvaut&view=log“ einzusehen.
Sie erlaubt die Nutzung der Daten im Rahmen des Projektes.
Die Nutzung der Daten aus Brandenburg unter Verwendung der ZV-Aut aus NRW ist,
obwohl es sich um zwei unterschiedliche Bundesländer handelt, als unbedenklich
anzusehen, da letztlich für alle in den Testdaten vorkommenden Objekte auch eine
Angabe in der Zeichenvorschrift zu finden ist.
Zu erwähnen ist natürlich, dass die Anzahl der ALK-Objekte in dem Testdatensatz sehr
begrenzt ist. Damit auch bei umfangreicheren ALK-Daten eine Umsetzung gewährleistet
ist, werden im Rahmen des Projektes für alle in der ZV-Aut genannten Objekte bzw.
Objektelemente Signaturen und Symbole erstellt. Diese werden in einzelnen TrueType-
Fonts abgespeichert. 106
Über den UMN Mapserver soll dann die ZV-Aut-konforme Darstellung der ALK-Elemente
gewährleistet werden. Um dieses Prinzip zu verdeutlichen werden im weiteren Verlaufe
dieser Arbeit einige Beispiele dargestellt.
Zwar soll, wie in Kapitel 2.2 ausgeführt, mittelfristig ALK durch ALKIS abgelöst werden,
da die endgültige Realisierung aber noch mehrere Jahre dauern wird, macht ein Projekt
wie FreeZVAUT auch aktuell Sinn. 107
Betont werden soll jedoch ausdrücklich, dass es im Rahmen einer Diplomarbeit
schlichtweg unmöglich ist, ein exorbitant umfassendes Projekt wie dieses komplett und
abschließend umzusetzen.
Die hinter FreeZVAUT stehenden Motive wurden bereits in Kapitel 1 ausführlich
dargestellt.
106 Ein Font ist dabei ein Zeichensatz, welcher Buchstaben, Zahlen oder auch Symbole erhalten
kann.
107 http://intevation.de/pipermail/mapserver-de/2006-January/001946.html vom 26.1.2006
43

2.5.1 Projektstruktur
2. Hintergründe
Die offizielle Projektseite ist unter: „http://wald.intevation.org/projects/freezvaut“
einzusehen (siehe Abbildung 14).
Abbildung 14: FreeZVAUT-Projektseite
Quelle: http://freezvaut.wald.intevation.org vom 20.5.2006
Innerhalb des Projektes gibt es zwei Mailinglisten, über welche im Wesentlichen die
Kommunikation der Projektmitarbeiter stattfindet.
Die Developer-Liste (deren Archiv ist unter
„http://lists.wald.intevation.org/pi-permail/freezvaut-devel“ einsehbar), sowie die
Freezvaut-Commits-Liste. Letztere dient dazu, eine Nachricht an die eingetragenen
Mitglieder zu senden, sofern neue bzw. veränderte Dateien in das Projekt eingebracht
werden.
Natürlich kann über die Homepage auch Zugriff auf den Verwaltungsbereich der im
Rahmen des Projektes erstellten Dateien (das sogenannte „repository“ (siehe auch Kapitel
3.2.7)) erlangt werden.
44

2. Hintergründe
Der Verwaltungsbereich gliedert sich in die Ordner „branches“ (als „branch“ wird ein
eventuell entwickelter Nebenzweig eines Projektes bezeichnet; dieses können z.B.
spezielle Entwicklerversionen sein), „tags“ (hier werden Versionen des Projektes
veröffentlicht) und „trunk“ (Hauptbaum eines Projektes). Im „trunk“-Verzeichnis befindet
sich immer die aktuellste Entwicklungsversion. Entwicklungsarbeit findet somit in diesem
Ordner statt. Zur besseren Übersicht wird dem geneigten Leser empfohlen, einmal einen
Blick in das „trunk“-Verzeichnis von FreeZVAUT zu werfen
(https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/?root=freezvaut).
Hier finden sich unter anderem Angaben zur Lizenz von FreeZVAUT, eine
Projektbeschreibung sowie mit den Ordnern „docs“, „fonts“ und „mapserver“ die
wesentlichen Inhalte des Projektes. Im „docs“-Verzeichnis befindet sich eine vom Autoren
dieser Arbeit mittels des Programmes LateX geschriebene Anleitung zur Erstellung von
Symbolen und Signaturen mittels fontforge.
Im „fonts“-Ordner liegen die erstellten TrueTypeFonts zu den einzelnen Folien (hierauf
wird im späteren Teil der Arbeit genauer eingegangen).
Der Ordner „mapserver“ enthält das erstelle Mapfile sowie das notwendige Symbolfile.
Auch wurden hier umfangreiche Dokumentationen zu den Besonderheiten der
einzelnen Folien und zu dem für die Umsetzung in FreeZVAUT notwendigen Datenmodell
eingestellt.
45

3. Methodik
3. Methodik
Zu den wesentlichen Methodiken und Konzepten, auf welchen diese Arbeit beruht,
gehören die Grundsätze der kartographischen Darstellung von Signaturen, der Aufbau
einer Systemarchitektur sowie die Beschreibung des verwendeten Datenmodells mit UML
(Unified modeling language).
3.1 Grundsätze kartographischer Darstellung
Eine Karte ist ein verebnetes, maßstabsgebundenes, generalisiertes und inhaltlich
begrenztes Modell räumlicher Information. 108
Prinzipiell werden in einer Karte drei Ebenen unterschieden: 109
● Graphische Grundelemente (unterste Ebene) (Punkt-, Linien- und
Flächenelemente sowie alphanumerische Zeichen)
● Kartenfeld und Kartenrandangaben (zweite Ebene) (z.B. Kartenbeschriftung,
Legende, Maßstab etc.)
● Zusammenspiel der Kartenfeld- und Kartenrandangaben zur Karte (dritte
Ebene)
Wie schon erwähnt geht es in dieser Diplomarbeit zentral um die Darstellung der
Grundelemente der ALK, in diesem Sinne also um die Gestaltung der untersten Ebene.
In der Literatur wird erwähnt, dass Anwender von computerkartographischer Software
zuweilen dem Irrglauben unterliegen, man könne Kartographie auf den technischen
Aspekt reduzieren: „Das einzige Problem bei der Kartenerstellung scheint die Bedienung
der Software zu sein. Alles im Rechner ist gespeichert, auch nach einigen Eingaben mit
Tastatur oder Maus stellen sich die schönsten Ergebnisse auf Knopfdruck ein. Die Karten
entstehen quasi automatisch." 110
108 Wilhelmy 2002, S.16
109 Olbrich/Quick/Schweikart 2002, S.71
110 ebda., S.19
46

3. Methodik
Diesem Irrglauben darf man sich keineswegs hingeben. Kartenentwurf und
Kartengestaltung, auch auf der Ebene der graphischen Grundelemente, sind nach wie vor
arbeitsintensive Prozesse, die einiges an gestalterischen Fähigkeiten verlangen.
Kartographische Regeln besitzen auch für die Kartographie im Internet ihre Bedeutung.
Bei der Umsetzung der ZV-Aut sind aufgrund der äußerst stringenten Vorgaben im
gestalterischen Sinne allerdings keinerlei individuelle Freiheiten gegeben.
Die kartographischen Regeln sind durch die ZV-Aut explizit vorgegeben.
Es stellt sich natürlich dennoch die Frage, ob die Vorgaben wesentlichen Dar-
stellungsgrundsätzen von Symbolen und Signaturen in der Kartographie entsprechen.
WILHELMY unterteilt beim Karteninhalt allgemein in Linien-, Grund- und
Flächensignaturen. 111
Punkthafte Signaturen (als Bestandteil von Grundsignaturen) lassen sich grob in drei
Kategorien aufteilen: 112
● Bildhafte Signaturen
● Geometrische Signaturen
● Buchstaben/Ziffern
Die bildhaften Signaturen weisen in ihrer optischen Form einen direkten Bezug zum
dargestellten Objekt auf, während geometrische Signaturen abstrakt dargestellt werden.
Buchstaben oder Ziffern lassen durch die Wahl ihrer Abkürzungen eine direkte
Assoziation zu einem Element zu. Die Verwendung alphanumerischer Zeichen ist für die
digitale Kartographie von wesentlicher Bedeutung. Kann eine Software auf vorgefertigte
Schriften zurückgreifen, so ist dieses von Vorteil. Muss sie hingegen alphanumerische
Zeichen aus Linien oder Punkten erzeugen, so hat dieses negative Auswirkungen auf das
Erscheinungsbild der Karte. 113
111 Wilhelmy 2002, S.99
112 Olbrich/Quick/Schweikart 2002, S.37
113 ebda., S.73
47

3. Methodik
Im Rahmen des Mapservers und der Darstellung von alphanumerischen Zeichen aus der
ZV-Aut können vorgefertigte Schriften integriert werden.
Objekte können im Bereich der Liniensignaturen durch die Breite des farbigen
Striches, die Anzahl der Striche nebeneinander oder in einen bestimmten Absatz gesetzte
Schwarz-Weiß-Felder erstellt werden. 114
Die Flächensignaturen schließlich werden durch flächig angeordnete Lokalsignaturen 115
oder aber Schraffuren und Raster eingesetzt. 116
Die Punkt-, Linien- und Flächenelemente können nach KRAAK und ORMELING in sechs
verschiedene Gestaltungsvariablen unterteilt werden: Größe, Helligkeit, Muster, Farbe,
Richtung und Form (siehe Abbildung 15).
Abbildung 15: Gestaltungsvariablen von Punkt-, Linien- und Flächenelementen
Quelle: Kraak/Ormeling 1996, Plate 1
114 Wilhelmy 2002, S.99.f.
115 Olbrich/Quick/Schweikart, 2002, S.38
116 Wilhelmy 2002, S.98
48

3. Methodik
Abgesehen von der Farbe (die Kartenzeichen der ALK-Standardfolien werden generell
schwarz dargestellt 117 ) finden diese Gestaltungsgrundlagen auch in der ZV-Aut
Verwendung.
Es ist allerdings zu bedenken, dass die Übertragung von Karten und kartenverwandter
Darstellungen über das Internet neue Formen der graphischen Gestaltungstechnik
erfordert. 118
Vor allem die Bildschirmauflösung schränkt die Gestaltung von Karten ein. Graphische
Elemente und Schrift müssen sich der physischen Vorgabe der Bildschirmauflösung, also
der Anzahl darstellbarer Pixel, anpassen. 119
"The size of a square (the resolution) will define how well a raster structure can represent
geographic reality." 120
Fragen der Detailfülle erhalten hierdurch eine besondere Bedeutung.
Ein weiterer Unterschied zu herkömmlichen Karten auf Papier ist die Tatsache, dass
auf einem Bildschirm ein größerer Kontrast zwischen schwarzer Schrift und weißem
Hintergrund besteht. 121
DICKMANN schreibt, dass Punkte innerhalb einer rasterbasierten Karte im Web
mindestens 2 mm Durchmesser besitzen und Linien eine Strichbreite von 0,35 mm nicht
unterschreiten sollten. Auch sollten schräge und gebogene Grundlinien bei
Beschriftungen vermieden werden. 122
Diesen Anforderungen wird die ZV-Aut nicht immer gerecht, da diverse
Begrenzungslinien eine Breite von 0,18 mm aufweisen, der Durchmesser einiger
Punktsymbole bei 1,5 mm liegt und Schriften auch Schrägstellungen aufweisen.
OLBRICH hingegen setzt die Größenangaben nicht ganz so hoch an. So wird geschrieben,
dass bei Darstellungen in Web Kreise mit einem Durchmesser kleiner als 0,15 mm kaum
noch wahrzunehmen sind und Linien eine Stärke von mehr als 0,1 mm haben sollten. 123 In
117 Innenministerium NRW 2005, S.5
118 Dickmann 2001, S.158
119 Olbrich/Quick/Schweikart 2002, S.181
120 Kraak/Ormeling 1996, S.73
121 Dickmann 2001, S.163
122 ebda., S.164 f.
123 Olbrich/Quick/Schweikart 2002, S.75
49

3. Methodik
diesem Sinne erfüllt die ZV-Aut auch die Gestaltungsgrundsätze von webbasierten
Kartenanwendungen in den meisten Punkten.
3.2 Systemumgebung
Der Aufbau der Systemarchitektur als methodischer Baustein stellt eine wichtige
Grundlage für zu erarbeitende Ergebnisse dar. Nachfolgend sollen die einzelnen
Systemkomponenten sowie deren Zusammenspiel beschrieben werden. Hauptaugenmerk
dabei soll ergänzend zu den Ausführungen aus Kapitel 2.4.4.1 auf den UMN Mapserver
gelegt werden, da dieser mit seinen Funktionen und Anwendungen der zentrale Baustein
der Anwendung ist.
Zu betonen ist auch, dass es bestimmte Systemkomponenten gibt, welche für die
Grundlagen von FreeZVAUT notwendig sind, und weitere Komponenten (z.B. PHP und
PHP/Mapscript), welche für die Realisierung des Flurstücksauskunftssystems benötigt
werden.
3.2.1 Betriebssystem
Als Betriebssystem wurde Suse 9.3 professional gewählt.
Suse Linux hat sich mittlerweile bei vielen Anwendern über Jahre bewährt. Die erste
SUSE-Linux-Distribution wurde im Mai 1996 mit der Versionsnummer 4.2 veröffentlicht. 124
„Suse-Linux ist dank der hohen Aktualität, der riesigen Anzahl vorkonfigurierter Pakete,
der umfassenden Handbücher und der hervorragenden Wartung die in Europa und in
Deutschland am weitesten verbreitete Distribution." 125
Das Betriebssystem ist sehr anwenderfreundlich und leicht zu installieren.
Zu seinen Vorzügen gehört insbesondere ein zentrales Installations-, Konfigurations- und
Administrationsprogramm (YaST-Yet another Setup Tool) sowie ein umfangreiches
Angebot an Programmen und Datenpaketen. Insbesondere letzteres wusste der Autor
124 http://de.wikipedia.org/wiki/Suse_Linux vom 29.5.2006
125 Kofler 2005, S.46
50

3. Methodik
dieser Arbeit im Rahmen des Systemaufbaus besonders zu schätzen. Eine Vielzahl von zu
installierenden Bibliotheken und Programmen müssen nicht erst mühsam im Internet
gesucht werden sondern befinden sich auf der Installations-DVD. 126
Als zusätzliche Unterstützung gibt es diverse Handbücher. 127
Die Suse-Distribution kann kostenlos aus dem Internet geladen ober aber auch
käuflich erworben werden. Der Kauf beinhaltet Support sowie ein umfangreiches
Handbuch; im Rahmen dieser Diplomarbeit wurde das Betriebssystem käuflich erworben,
um unter Umständen direkten Support in Anspruch nehmen zu können.
Zusätzlich zu dem Support, welchen die Firma Novell als Verkäufer dieser Linux-
Distribution anbietet, gibt es noch zahlreiche Foren und Hilfsportale im Internet. 128
Die Anwendergemeinschaft ist als sehr groß zu bezeichnen.
3.2.2 UMN Mapserver
Bereits in Kapitel 2.4.4.1 wurden einige Aspekte des UMN Mapservers geschildert und
begründet, warum eine Entscheidung für dieses Produkt getroffen wurde.
Nachfolgend sollen noch einige Punkte vertieft und hinzugefügt werden.
Das Projekt des UMN Mapservers wurde Mitte der 90er Jahre von der University of
Minnesota (UMN) in Zusammenarbeit mit der NASA und dem Minnesota Department of
Natural Resources 129 ins Leben gerufen. Derzeit wird MapServer vom TerraSIP Projekt
beherbergt, einem durch die NASA finanzierten Projekt zwischen der UMN und dem
Consortium of Land Management Interests. 130
Der UMN Mapserver ist kein eigenständiges GIS sondern ein Programm, welches
Karten ausgibt.
Mittels verschiedenen Erweiterungen und Aufsätzen ist es aber möglich, typische GIS-
Funktionen wie z.B. Flächenberechnungen oder die Erstellung von Puffern zu
implementieren. Außerdem besitzt der Mapserver mit der Mapscriptbibliothek eine
126 Kofler 2005, S.1243
127 z.B. Novell Inc. 2005
128 z.B. http://forums.suselinuxsupport.de; http://www.linux-club.de; http://www.linuxforen.de;
129 Schüngel 2004, S.23
130 http://mapserver.gis.umn.edu vom 2.6.2006
51

3. Methodik
Programmierschnittstelle (Application Programming Interface, API) für Sprachen wie Perl,
Java, Python oder PHP, wodurch eine Vielzahl von Funktionalitäten erzeugt werden
können. 131
Der Mapserver unterstützt die Standards des OGC und ist somit in der Lage, als WMS-
Server/Client zu fungieren.
Durch diesen Standard wird eine große Interoperabilität geschaffen, das heißt, dass
Karten aus verschiedenen Anwendungen (z.B. auch aus Deegree oder ArcIMS)
implementiert werden können.
Wenn also der Mapserver als WMS fungiert, dann können Anwender im Web die Karten,
Layer und Geodaten bei sich implementieren. Dieses hat unter anderem den Vorteil, dass
man die Rechenarbeit für eine fertige Karte auf mehrere Server verteilen kann. 132
Auch wurde mittlerweile die Funktionalität als WFS integriert, es werden nun auch
Anfragen auf der Karte zugrunde liegenden Daten beantwortet.
Die wahrscheinlich bedeutendsten Faktoren des UMN Mapservers sind die weltweite
Anwendergemeinschaft 133 und die hohe Performanz des Produktes. Zahlreiche private
und staatliche Institutionen haben gute Erfahrungen mit dieser Software gemacht. 134
In seiner Standardfunktion wird der Mapserver an einen Webserver gekoppelt und
über eine URL im Browser aufgerufen.
Abbildung 16 stellt dar, wie eine Kartenanfrage an den Mapserver gestellt wird.
131 Fischer 2003, S.5 und S. 137
132 ebda, S.6
133 Lindenbeck/Schulz 2004, S.423; http://www.umn-mapserver.de vom 27.5.2006
134 Schönbuchner/Unterpaintner 2005, S.43
52

Abbildung 16: Mapserverarchitektur
Quelle: CCGIS/terrestris 2004, S.41
3. Methodik
Ein Nutzer an einem Webbrowser stellt über das HTTP-Protokoll eine Anfrage an den
Webserver. Der Webserver stellt dann über das Common Gateway Interface (CGI) 135 eine
Kartenanfrage an den Mapserver. Über das CGI werden vom Webserver benutzer-
spezifische Daten übermittelt. 136 Diese Technik eignet sich sehr gut, um interaktive Karten
durch den Nutzer zu generieren. 137 Die übergebenden Parameter werden vom Mapserver
verarbeitet. An den Webserver wird anschließend eine Karte als Rasterbild
zurückgegeben (über das HTTP-Protokoll) und letztlich im Webbrowser dargestellt. 138
Die vom Mapserver verarbeiteten Geodaten können im Raster- oder Vektorformat
vorliegen. Auch ist es möglich, dass diese in einer Datenbank gespeichert werden. Ein
häufiges Modell ist die Speicherung in einer PostgreSQL/PostGIS-Datenbank (siehe auch
Kapitel 3.2.6).
Im Rahmen dieser Diplomarbeit wurde der Mapserver in der Version 4.6.0 verwendet.
135 CGI ist eine Standardschnittstelle zwischen einem Webserver und einem externen
Programm (hier dem UMN Mapserver)
136 Autorenteam von Sun Microsystems 2002, S.370
137 Olbrich/Quick/Schweikart 2002, S.183
138 CCGIS/terrestris 2004, S.42; Schönbuchner/Unterpaintner 2005, S.47
53

3.2.2.1 Basisfunktionen des UMN Mapservers
3.2.2.1.1 Visualisierung
Zu den Basisfunktionen des Mapservers gehört das Visualisieren von Geodaten.
3. Methodik
Eine Fülle von Formate können hierbei integriert werden. Der UMN Mapserver kann an
Vektordaten z.B. ESRI Shapefiles oder Daten im ArcSDE-, DGN- oder TAB-Format
einbinden. 139 Rasterdaten können beispielsweise im TIFF/GeoTIFF, GIF, PNG oder EPPL7-
Format integriert werden. 140
Die Visualisierung der Daten kann maßstabsabhängig geschehen.
Daten können gesondert als Symbole und auch mit Textunterstützung dargestellt
werden. Im UMN Mapserver ist ein Algorithmus implemetiert, welcher der
Kollisionsverhinderung der Schriftelemente dient.
Der gewünschte Kartenausschnitt wird letztlich visualisiert und als Rasterbild ausgegeben.
Unterstützt werden mehrere 1000 Kartenbezugssysteme. 141
Zur Visualisierungsunterstützung können auch Legenden implementiert werden.
3.2.2.1.2 Navigation
Der UMN Mapserver gewährleistet ein Hinein- und Herauszoomen in einer Karte,
das Verschieben des Kartenausschnittes sowie eine thematische Navigation, da frei
entschieden werden kann, welche Layer ein- bzw. auszuschalten sind. Auch wird die
Navigation durch eine interaktive Übersichtskarte und das Einbinden einer Maßstabsleiste
unterstützt.
3.2.2.1.3 Abfrageoption
Zu einzelnen Geoobjekten können Abfragen durchgeführt werden. Vorhandene
Attribute können in dafür erstellen HTML-Dateien ausgegeben werden.
Auch ist es möglich, abgefragte Objekte in einer eigens dafür erstellen Karte farblich
oder durch bestimmte Symbole gesondert darzustellen.
139 http://mapserver.gis.umn.edu/docs/howto/ogr_howto/#what-data-formats-are-supported
vom 18.5.2006; auch: Schönbuchner/Unterpaintner 2005, S.52
140 http://mapserver.gis.umn.edu/docs/howto/raster_data/#supported-formats vom 19.5.2006
141 Projektgruppe Studienprojekt Wesermarsch 2005, S.85
54

3.2.2.2 Technische Basisdateien des UMN Mapservers
3.2.2.2.1 Mapfile
3. Methodik
Zentrale Konfigurationsdatei ist das sogenannte Mapfile, in welchem die Ausgabe der
Karte determiniert wird; es kann quasi als „Herz" der Anwendung bezeichnet werden. 142
Hierbei handelt es sich um eine ASCII-Datei mit der Endung „.map".
Das Mapfile gliedert sich in mehrere Blöcke. Im ersten Block werden globale
Einstellungen zur Ausdehnung der Karte, der verwendeten Maßeinheit, den
Datenquellen, der Ausgabedatei, dem angewandten Projektionssystem sowie der
Legende, Maßstabsleiste und Übersichtskarte festgelegt.
In den weiteren Abschnitten werden Einstellungen zu den visualisierenden Geodaten
angegeben. So wird z.B. festgelegt, welche Layer darzustellen und wie bestimmte
Geodaten zu visualisieren sind (Angaben zu Farbe, Symbol und Schrift). 143
Die im Mapfile dargestellten Objekte werden hierarchisch präsentiert. Innerhalb eines
Mapobjektes werden Layerobjekte dargestellt, welche wiederum Klassenobjekte
enthalten können. 144
3.2.2.2.2 HTML-Template
Das Template ist eine HTML-Datei, in welcher die Ausgabeparamter des Mapservers
dargestellt werden. Diese wird in einem Ausgabebrowser dargestellt. Der eigentliche
Kartenausschnitt, Übersichtskarte, Legende und Maßstabsleiste werden als Bilddateien in
das HTML-File eingefügt, welches „als eine Art Lochmaske fungiert." 145
Über Formulare und eine Definition von CGI-Variablen findet eine Kommunikation mit
dem Nutzer statt.
So können z.B. bestimmte Checkboxes oder Radiobuttons angeklickt werden und somit
verschiedene Parameter übergeben werden; auch kann der Nutzer im Template Abfragen
stellen oder innerhalb der Karte Navigationsfunktionen durchführen.
142 Behncke 2005, S.4; Fischer 2003, S.9
143 Siehe auch: Projektgruppe Studienprojekt Wesermarsch 2005, S.85
144 Schüngel 2004, S.24
145 CCGIS/terrestris 2004, S.47
55

3. Methodik
Durch das Verhalten des Nutzers auf der Ebene des Templates werden also Parameter via
HTTP-Schnittstelle über den Webserver an den Mapserver übergeben, ausgewertet und
zurückgeliefert
Das Template kann durch webfähige Sprachen wie Java Script oder PHP erweitert
werden.
3.2.2.2.3 Weitere Dateien
Eine weitere relevante Datei ist die Symboldatei, in welcher Symbole oder die
Darstellung von Linien definiert werden kann. Für die ZV-Aut-konforme Darstellung von
ALK-Daten ist diese eine ganz entscheidende Datei.
In der Fontdatei wird dann festgelegt, welche TrueType-Schriften anzuwenden sind.
Dass diese Fonts nicht nur Buchstaben sondern auch komplexe Symbole enthalten
können, wird im weiteren Teil der Arbeit deutlich.
Das Mapfile beinhaltet einen Verweis auf die Symbol- und Fontdatei und integriert diese
somit in die Anwendung.
Abbildung 17 auf der folgenden Seite stellt das Zusammenspiel der Dateien einer
typischen Mapserveranwendung dar.
56

Abbildung 17: Zusammenspiel der technischen Dateien im UMN Mapserver
Quelle: Eigene Darstellung
3.2.3 Apache Webserver
3. Methodik
Anwendungen im Inter- bzw. Intranet basieren auf einem Client/Server-Konzept. Der
Client (in der Regel ein Browser) fordert Daten vom Server an. Der Webserver stellt einen
Dienst zur Verfügung, der die Anfragen der Clients bearbeitet und entsprechende
Dokumente an den Client zurückliefert. 146 Ein Webserver stellt zum Beispiel Webseiten
oder Bilder zur Verfügung; die Kommunikation läuft dabei über das HTTP-Protokoll. 147 Als
Webserver, an welchen der Mapserver gekoppelt ist, wurde der Apache Webserver
ausgewählt.
146 Autorenteam von Sun Microssystems 2002, S.11
147 Schüngel 2004, S.24
57

Abbildung 18 : Logo des Apache Webservers
Quelle: http://www.apache.org
3. Methodik
Der Apache Server ist ein Produkt der Apache Software Foundation und der
meistverbreitete Webserver im Internet. Ungefähr 60% aller weltweit benutzen Webserver
werden mit dem Apache betrieben. 148 Laut offizieller Apache-FAQ wurde der Name aus
Respekt vor dem nordamerikanischen Indianerstamm der Apachen gewählt, andere
Quellen sagen aus, dass es sich bei diesem Namen um ein Wortspiel der Apache-
Entwickler handelt und letztlich aus dem Ausdruck „a patchy server" entsprungen ist, was
soviel wie zusammengeflickter Server bedeutet. 149
Der Grund für seine enorm hohe Verbreitung liegt in seiner Leistungsfähigkeit, Stabilität
und der Verfügbarkeit für eine Vielzahl von unterschiedlichen Betriebssystemen und
Plattformen. 150
Der Apache-Webserver ist modular aufgebaut. Durch entsprechende Module kann er
beispielsweise die Kommunikation zwischen Browser und Webserver verschlüsseln oder
als Proxy-Server eingesetzt werden.
Vorhanden sind vielfältige Konfigurationsmöglichkeiten; 151 der Server kann vollständig
eigenen Bedürfnissen angepasst werden, indem man eigene Module schreibt. 152
Der Apache HTTP Server ist, wie alle Produkte der Apache Software Foundation,
kostenlos als Open Source unter der Apache-Lizenz verfügbar. 153
In dieser Arbeit wurde die Version 1.3.34 verwendet.
148 Aulds 2001, S.15; Autorenteam von Sun Microssystems 2002, S.15; Bowen/Coar 2000, S.30
149 Roßbach 1999, S.15; http://de.wikipedia.org/wiki/Apache_HTTP_Server vom 27.5.2006
150 Autorenteam von Sun Microssystems 2002, S.15
151 ebda, S.16; Aulds 2001, S.45
152 Aulds 2001, S.42
153 ebda., S.35; http://de.wikipedia.org/wiki/Apache_HTTP_Server;
http://www.apache.org/licenses vom 24.5.2006
58

3.2.4 Fontforge
3. Methodik
Fontforge ist ein Open-Source-Schrift- und Symbolerstellungsprogramm, mittels
welchem sich eine Fülle von Fonts erstellen lassen (z.B. im Postscript- oder TrueType-
Format).
Installierbar ist es sowohl auf Macintosh, Windows als auch auf Unix/Linux -Plattformen.
Veröffentlicht wurde es unter der "Revised BSD License" und stellt daher Freie Software
im eigentlichen Sinne dar. 154
Mittels dieses Programmes wurde eine Vielzahl von Vorgaben aus der ZV-Aut
umgesetzt, es stellt also das Schlüsselprogramm für die Erstellung der ALK-Symbole bzw.
Signaturen dar.
3.2.5 Edbsilon
Edbsilon ist ein Konverter für Daten im EDBS-Format. Die EDBS-Dateien werden
eingelesen und als SQL-Kommandos zum Eintrag in eine Geodatenbank ausgegeben oder
direkt in das Shape-Format umgewandelt.
Edbsilon ist Freie Software unter der GNU General Public License (GNU GPL) und kann
daher von jedem beliebig kopiert, angepasst, erweitert sowie weiter gegeben werden,
solange die Weitergabe ebenfalls unter der GNU GPL erfolgt.
Das Programm wurde von Silke Reimer und Ludwig Reiter, Mitarbeiter der Intevation
GmbH, in der Programmiersprache „Python“ geschrieben. Es läuft auf verschiedenen
Plattformen, insbesondere sowohl unter Windows als auch auf GNU/Linux-basierten
Systemen. 155
154 http://fontforge.sourceforge.net vom 22.5.2006
155 http://edbsilon.intevation.org vom 24.5.2006
59

3.2.6 PostgreSQL/PostGIS
3. Methodik
PostgreSQL ist ein zuverlässiges und hochperformantes Datenbanksystem, welches sehr
gut mit PHP kooperiert. 156 Es gilt als äußerst stabil und sehr flexibel. 157
Mittels eines bestimmten SQL-Dialektes können äußerst komplexe Daten-
bankanwendungen erstellt werden. Innerhalb dieses Datenbanksystems wurde zusätzlich
mit verschiedenen PostgreSQL-Verwaltungstools wie z.B. psql, phppgadmin oder
pgadmin3 gearbeitet.
PostgreSQL ist unter der BSD-Lizenz verfügbar.
Eine Besonderheit von PostgreSQL ist die Implementierung räumlicher SQL-Abfragen bzw.
räumlicher Funktionen durch die PostGIS-Bibliothek. 158
„PostGIS bezeichnet die räumliche Erweiterung zur Speicherung und Verwaltung von
Geodaten in der Open Source-Serverdatenbank PostgreSQL.“ 159
Hierdurch wird es z.B. möglich, Shapedateien gesammelt in einer Datenbank zu
verwalten, was nicht nur eine bessere Übersicht sondern auch eine höhere Performanz
bei bestimmten Abfragen gewährleistet. 160 Auch können hierdurch z.B.
Flächenberechnungen, Flächenverschneidungen oder aber in Kombination mit PHP
z.B. automatisiert Koordinaten von bestimmten Flurstücken ausgegeben werden.
Nach Ansicht des Autors eröffnet eine PostgreSQL/PostGIS-Anbindung des Mapservers in
Kombination mit PHP und PHP/Mapscript jene Möglichkeiten, welche aus einem
ursprünglich „nur“ kartenproduzierenden System nahezu ein Geoinformationssystem
machen.
Abbildung 19 gibt ergänzend und zusammenfassend zu den obigen Ausführungen einen
Überblick über die verwendeten Systemkomponenten.
156 Boenigk 2002, S. V
157 Geschwinde/Schönigk 2002, S.16 f.
158 Fischer 2003, S.77
159 CCGIS/terrestris 2004, S.50
160 Fischer 2003, S.123
60

Abbildung 19: Systemkomponenten im Rahmen des FreeZVAUT-Projektes
Quelle: Eigene Darstellung
3.2.7 SVN
3. Methodik
Das Programm SVN ist keine direkte Systemkomponente sondern dient der effizienten
Verwaltung der im Rahmen des Projektes entstehenden Dateien.
Sämtliche erstellen Daten (z.B. Mapfile, Symbolfile, TrueType-Fonts etc.) werden mit
SVN administriert. Die Abkürzung „SVN" steht für Subversion. SVN ist ein mächtiges
Versionsverwaltungstool, welches von vielen Softwareherstellern eingesetzt wird. Mit
diesem Programm können während der Erstellung einer Software durch mehrere
Entwickler Dateien und Verzeichnisse verwaltet werden. Daten werden in dem
sogenannten „repository" gespeichert, welches jede Änderung innerhalb der Dateien
registriert. Dieses ermöglicht das genaue Rückverfolgen der Entstehung einer Datei und
gibt Aufschluss darüber, welcher Code wann veröffentlicht (bezogen auf SVN sagt man
auch „eingecheckt") wurde. Werden neue Dateien eingecheckt, so erhalten diese auch
61

3. Methodik
Angaben zur sogenannten „Revision“ (womit eine numerische Angabe zur Überarbeitung
der vorhandenen Dateien gemeint ist), zum Autor sowie Kommentare zum Inhalt der
Dateien.
Insbesondere für die Fehlersuche innerhalb eines Projektes ist SVN sehr hilfreich. Auch
gewährleistet das Programm, dass von einem Entwickler getätigte Änderungen oder
Erweiterungen innerhalb eines Projektes nicht ohne weiteres durch einen anderen
Entwickler überschrieben und somit rückgängig gemacht werden können.
Durch die klare Struktur von SVN ist es möglich, dass Menschen an unterschiedlichen
Computern gleichzeitig an der Erstellung eines Programmes arbeiten. 161
3.2.8 Zusätzliche Komponenten für das Flurstücksinformationssystem
Für das Flurstücksinformationssystem werden Komponenten benötigt, die im Rahmen
des eigentlichen FreeZVAUT-Projektes nicht notwendig sind; insbesondere um im Web
eine Interaktivität mit dem Nutzer zu gewährleisten.
Auch die nachfolgenden Komponenten stellen Open-Source-Software dar.
3.2.8.1 PHP
PHP 162 ist eine serverorientierte Skriptsprache, welche insbesondere für
Webanwendungen konzipiert ist. Das bedeutet, dass Anweisungen nicht clientseitig, also
nicht auf den Rechnern des Users ablaufen, sondern direkt auf dem Server ausgeführt
und die Ergebnisse im Browser angezeigt werden. 163
PHP ist keine Programmiersprache im eigentlichen Sinne sondern eine sogenannte
„Scripting Language“, das bedeutet: „PHP wird nur „aktiv“, wenn ein Ergebnis eingetreten
ist, z.B., wenn eine Website (...) aufgerufen wird oder wenn auf einer Website ein Formular
von einem User ausgefüllt und dieses Formular abgeschickt wurde.“ 164
PHP ist eine optimale Sprache, um in Kombination zu HTML dynamische Webseiten zu
161 http://svnbook.red-bean.com/nightly/en/svn-book.html vom 22.5.2006
162 Ursprünglich stand diese Abkürzung einmal für „Personal Homepage“, aktuell wird das Kürzel
aber als Synonym für „PHP: Hypertext Preprocessor“ angesehen.
163 Hahne 2003, S.23 ff.
164 Möller/Peyton 2004, S.12
62

erstellen, auf denen Interaktionen mit dem User gewährleistet werden sollen.
3. Methodik
Auch stellt PHP eine sehr geeignete Sprache dar, um mit verschiedenen Datenbanken zu
kommunizieren.
PHP ist als Quellcode oder als Binärpaket über die Seite „http://www.php.net“ zu
beziehen.
3.2.8.2 PHP/Mapscript
In Kapitel 3.2.2 wurde bereits erwähnt, dass die Funktionen des Mapservers durch
verschiedene Sprache erweitert werden können. Eine dieser Sprachen nennt sich
PHP/Mapscript. Durch die Einbindung der entsprechenden Bibliothek können die
interaktiven Möglichkeiten des Users in der Kartenanwendung beträchtlich erhöht
werden.
Einträge im Mapfile werden durch PHP/Mapscript als Objekte behandelt.
Der User kann über einfache Formulare diese Objekte im Mapfile verändern und
hierdurch die Komplexität der Anwendung erhöhen. Es ist nun beispielsweise möglich,
auf speziell ausgewählte Punkte zu zoomen, bestimmte Filter für die Anzeige von Daten
zu setzen oder Daten zu bestimmten Flächen anzeigen zu lassen.
3.2.8.3 JavaScript
JavaScript ist eine Sprache, welche dazu dient, statische HTML-Seiten so zu erweitern,
dass sich Elemente bewegen oder Objekte verändern und eine Interaktion mit dem
Anwender möglich wird. Im Gegensatz zu PHP ist sie nicht serverorientiert
sondern wird direkt zur Laufzeit interpretiert. 165
165 Rotter 2002, S.15 f.
63

3.3 Datenmodellierung mit UML
3. Methodik
In diesem Kapitel sollen nun die im Rahmen von FreeZVAUT verwendeten Daten der
LG Brandenburg mittels der Modellierungssprache UML beschrieben werden.
Die Unified modeling language (UML) ist eine Sprache und Notation zur Spezifikation,
Konstruktion, Visualisierung und Dokumentation von Modellen. 166
Sie dient unter anderem der Visualisierung von Softwareartefakten. 167
Durch ihr eindeutiges Vokabular und die eindeutig festgelegten Regeln, wie die einzelnen
Wörter des Vokabulares zusammengefügt werden, ermöglicht sie eine eindeutige
Interpretation eines mit dieser Sprache erstellen Modells. 168
Die im Rahmen dieses Kapitels erstellen UML-Diagramme wurden mittels des
Programmes „ArgoUML“ erstellt, welches explizit Freie Software ist und auf Java basiert.
Im Rahmen der verwendeten Testdaten gibt es insgesamt 9 Klassen, von denen
insgesamt 5 zu 2 abstrakten Oberklassen gezählt werden können (siehe Abbildung 20 auf
der folgenden Seite).
Eine Klasse enthält dabei die Beschreibung der Struktur und des Verhaltens von
Objekten, die sie erzeugt oder die mit ihr erzeugt werden können. 169
Die abstrakten Klassen repräsentieren einen Allgemeinbegriff, einen Oberbegriff für eine
Menge konkreter Begriffe. 170
In diesem Falle treten die abstrakten Klassen „Gebäude“ (mit den Assoziationen
„Hausnummer“ und „Gebäudefläche“) sowie „Tatsächliche Nutzung“ (mit den
Assoziationen „Nutzungssymbol“, „Nutzungsfläche“ und „Beschriftung“) auf.
166 Oestereich 1999, S.203
167 Booch/Rumbaugh/Jacobson 2006, S.38
168 ebda. S.38 f.
169 Oestereich 1999, S.232
170 ebda., S. 228
64

3. Methodik
Abbildung 20: UML-Klassendiagramm der verwendeten Daten der LG Brandenburg
Quelle: Eigene Darstellung
Objekte schließlich sind im laufenden System konkret vorhandene und agierende
Einheiten. Diese enthalten durch Attribute repräsentierte Informationen, welche
individuell für jedes Objekt bestehen. 171
Ein Beispiel für ein Objekt stellt Abbildung 21 dar.
Abbildung 21: Beispiel für ein UML-Objekt
Quelle: Eigene Darstellung
171 Oestereich 1999, S.231
65

Die Klassen (und somit auch die Objekte) haben Beziehungen zueinander.
3. Methodik
Beispielsweise wird in Abbildung 20 deutlich, dass ein oder mehrere Flurstücke ein Teil
einer Gemarkung sind, bzw. dass Gebäude zu einem Flurstück gehören.
66

4. Technische Realisierung
4.1 Umsetzung des FreeZVAUT-Projektes
4. Technische Realisierung
Innerhalb dieses Kapitels nun soll auf das besondere technische Vorgehen innerhalb
von FreeZVAUT eingegangen werden.
Im Wesentlichen geht es darum, TrueType-Fonts für ZV-Aut-konforme Symbole und
Signaturen zu erstellen und diese über zu erarbeitende Parameter im Map- bzw.
Symbolfile im UMN Mapserver einzubinden.
Bezogen auf einige Elemente sollen beispielhaft Hinweise für ein Datenmodell gegeben
werden, in welches Attribute von verschiedenen Folien einzulesen sind. Auf dieses
Datenmodell in der PostgreSQL-Datenbank wird letztlich aus dem Mapfile heraus
zugegriffen.
Selbstverständlich kann im Rahmen dieser Arbeit nicht auf sämtliche technischen
Feinheiten eingegangen werden; es sollen aber die typischen und wichtigsten
Handlungsweisen aufgezeigt werden.
Beispielhaft wird auch Code dargestellt; um diesen von dem beschreibenden Text
abzugrenzen wird dieser in blau präsentiert.
4.1.1 Symbolerstellung
Anhand des Laufkrans (OS 3923) (siehe Abbildung 22) der Folie 082 soll die typische
Vorgehensweise für eine ZV-Aut-konforme Symbolerstellung dargestellt werden.
Abbildung 22: Auszug aus der Folie 082 (Ergänzungstopographie) der ZV-Aut
Quelle: Innenministerium NRW 2005, S.101
67

4. Technische Realisierung
Im UMN Mapserver wird die Ausgabegröße eines Symbols über den SIZE-Parameter im
Mapfile terminiert. Die SIZE-Größe wird in der Regel in Pixeln angegeben. Standardmäßig
werden die Rasterkarten bei 72 dpi (dots per inch) dargestellt.
Ein inch weist eine Länge von 2,54 cm auf. Rechnet man also 72 (pixel) / 2,54 cm so
erhält man einen Wert von 28,3464566..... Pixeln/cm.
Wenn man also im Mapfile einem Symbol die Größe von einem 1 cm geben möchte,
so müsste strenggenommen die SIZE-Angabe bei 28,3464566929.... liegen
(für 0,5 cm: 14,17322834645....; für 0,2 cm: 5,6692913386....; etc.). Allerdings werden die
SIZE-Angaben im Mapfile immer automatisch als Integerwerte übernommen. Es macht
also keinen Unterschied, ob man einem Objekt beispielsweise den SIZE-Wert
5,6692913386.... oder 5 zuweist. Dieses ist auch nur logisch, da sich Pixel schließlich nur
als ganze Pixel darstellen lassen. In diesem Sinne werden die errechneten Werte vom
Autoren dieser Arbeit auf- bzw. abgerundet.
Die Ausgabegröße eines Objektes wird also über den SIZE-Parameter im Mapfile
festgelegt.
Es bleibt aber noch die Frage zu klären, in welcher Größe ein Symbol in Fontforge
erstellt werden muss, bzw. mit welchen Einheiten hier gearbeitet wird.
In einem Erstellungsprogramm für Fonts gibt es zur Erstellung eines Symbols ein
Koordinatensystem, welches auch „em-square“ genannt wird (siehe Abbildung 23). In
diesem ist festzulegen, wie viele Abstufungen sich dort befinden. Für die Erstellung von
TrueType-Fonts ist per Definition festgesetzt, dass das Koordinatensystem einen Wert von
2048 Einheiten (auch „em-units“ genannt) besitzt. 172
In einem weiteren Dokument zur Symbolerstellung für eine ZV-Aut-konforme
Darstellung ist zu lesen, dass einem Objekt für einen Druck von z.B. 8 mm der SIZE-Wert
von 22.6771653543...zuzuschreiben ist 173 (hier wurde nicht berücksichtigt, dass keine
172 http://fontforge.sourceforge.net/fontinfo.html#PS-General vom 5.6.2006
173 http://sourceforge.net/project/showfiles.php?group_id=88554&package_id=110215 vom
18.5.2006
68

4. Technische Realisierung
Teilpixel dargestellt werden können) und das Objekt im ”Fontcreator“ (einem
proprietären Fonterstellungsprogramm) eine Ausdehung von 741,36 em-units hat (hier
wurde mit einem Koordinatensystem von 1000 em-units gearbeitet).
Abbildung 23: em-square in Fontforge
Quelle: Eigene Darstellung
Da in Fontforge in einem em-square von 2048 Einheiten in horizontaler und vertikaler
Richtung gearbeitet wird, müssen diese Werte hochskaliert werden. 741,36 em-units
entsprechen dann 1518,30 Einheiten.
Dieser Wert wurde selbstverständlich in Bezug auf viele unterschiedliche Symbole und
Signaturen überprüft. Es wurde penibel genau kontrolliert, ob er tatsächlich die Basis für
eine korrekte Visualisierung der Objekte darstellt. In Bezug auf die Ausgabegröße ist es
zwar irrelevant, ob ein Objekt 741,36 Einheiten in einem em-square von 1000 groß ist
oder aber 1518,3 em-units in einem Koordinatensystem von 2048; es sollen hier jedoch
die von Fontforge vorgeschriebenen Konventionen befolgt werden.
69

4. Technische Realisierung
Der Laufkran nun besteht aus 5 Segmenten, welche laut ZV-Aut jeweils 4 mm breit
sein sollen (siehe Abbildung 22 auf Seite 67).
Diese 4 mm werden bei diesem Symbol als Definitionsgröße genommen.
Die Breite eines Segmentes liegt in dem Fonterstellungsprogramm also bei 1518,30
Einheiten. In der ZV-Aut steht geschrieben, dass die Liniendicke bei Klasse 2 liegen soll
(0, 18 mm).
Wenn das 4 mm lange Segment 1518,3 em-units lang ist, so muss die 0,18 mm breite
Linie insgesamt 68,3 em-units breit sein. Es muss also bei der Erstellung eines Symbols
darauf geachtet werden, dass die Größenrelationen stimmen. 174
Mittels unterschiedlicher Zeichenfunktionen können dann in Fontforge Symbole erstellt
werden. Abbildung 24 zeigt, wie das fertig erstellte Symbol in Fontforge aussieht.
Abbildung 24: Symbol „Laufkran“ in FontForge erstellt
Quelle: Eigene Darstellung
Das Symbol schließlich wird innerhalb eines TrueType-Fonts abgespeichert.
Innerhalb des FreeZVAUT-Projektes wird so vorgegangen, dass jeweils alle Symbole zu
174 Wichtig ist festzuhalten: Eine Abweichung von ca. 15 em-units ist so gering, dass sie
letztlich keine Auswirkungen auf die Darstellung der Symbole, weder im Browser
noch auf einer hochauflösenden Druckkarte hat. Dennoch sollte man hier natürlich
aus prinzipiellen Gründen so genau wie möglich arbeiten.
70

4. Technische Realisierung
einer Folie in einem namentlich entsprechenden Font abgespeichert werden.
Abbildung 25 stellt verschiedene Symbole aus dem Font „zvaut-folie082.ttf“ dar.
Abbildung 25: Symbole aus dem TrueType-Font „zvaut-folie082.ttf“
Quelle: Eigene Darstellung
Der Laufkran innerhalb dieser Abbildung steht übrigens an der dritten Position von
links in der zweiten Reihe von oben.
Im Mapfile werden dann mögliche Elemente über einen Layer und verschiedene
Klassen dargestellt.
In den einzelnen Klassen wird geprüft, ob der für das Symbol notwendige Objektschlüssel
in der Datenbank vorliegt. Ist dieses der Fall, so wird das entsprechende Symbol
präsentiert.
Wichtig ist zu betonen: Das Mapfile sorgt letztlich dafür, dass auf Basis der
konvertierten EDBS-Daten eine automatisierte Darstellung des ALK-Ausschnittes
präsentiert wird.
Nachfolgend soll der relevante Code (für den Laufkran) aus dem Mapfile dargestellt
werden:
71

LAYER
NAME 'folie082_symbole/signaturen'
TYPE POINT
STATUS DEFAULT
MINSCALE 0
MAXSCALE 4000
CONNECTIONTYPE postgis
CONNECTION 'user=postgres dbname=zvaut host=localhost port=5432'
DATA 'the_geom from f082_p'
CLASSITEM 'objart'
SYMBOLSCALE 1000
CLASS
NAME "Laufkran"
EXPRESSION /3923/
STYLE
SYMBOL "Laufkran"
SIZE 11
COLOR 0 0 0
END
END
END
...
Sämtliche Symbole werden im Symbolfile definiert.
Der Eintrag für den Laufkran beispielsweise sieht wie folgt aus:
...
#OS 3923
SYMBOL
NAME „Laufkran“
TYPE TRUETYPE
FONT „zvaut-folie082“
ANTIALIAS TRUE
CHARACTER „2“
END
...
4. Technische Realisierung
Objektschlüssel, nach welchem in der
Datenbank gefiltert wird.
Benennung des Symbols, welches aus
dem Symbolfile aktiviert wird.
Größenangabe des Symbols
Verweis auf das Font, in welchem
das Symbol „Laufkran“ liegt.
Zeichen, unter welchem das Symbol
„Laufkran“ im Font „zvaut-folie082.ttf“
abgespeichert ist.
Es wird hier der Name des Symbols, der Symboltyp und eine Angabe zum Aliasing
festgelegt. Auch wird angegeben, in welchem TrueType-Font das Symbol zu finden ist.
Abbildung 26 stellt dar, wie das Symbol dann im UMN Mapserver aussieht.
72

4. Technische Realisierung
Abbildung 26: Symbol „Laufkran“ (OS 3923 aus Folie 082) im UMN Mapserver
Quelle: Eigene Darstellung
Misst man dieses Symbol nach, so wird man feststellen, dass es genau die in der ZV-
Aut geforderte Größe aufweist.
Noch einmal zur Verdeutlichung: In der Regel gibt es für jedes Symbol eine feste
Ausgabegröße in Millimetern. Dieses Ausdehnung des Symbols wird in Fontforge mit
1518,30 em-units belegt; völlig unabhängig davon, welche Größe das Symbol in der
Ausgabe haben soll.
Die Ausgabegröße auf der Karte wird dann über den SIZE-Parameter im Mapfile
bestimmt. Würde man also z.B. ein Dreieck mit einer Höhe von 5 Millimetern darstellen
wollen, so würde diese Höhe in Fontforge mit 1518,30 em-units belegt werden und das
Symbol im Mapfile eine Größe von 14 erhalten (14.173....Pixel= 5 mm).
Im Mapfile wird festgelegt, unter welchen Bedingungen ein bestimmtes Symbol
gezeichnet wird.
Das Symbol selber ist im Symbolfile definiert. Hier wird festgelegt, auf welchen TrueType-
Font zugegriffen wird.
73

4. Technische Realisierung
Bei sehr großen Symbolen oder Signaturanhäufungen kann die Anzahl der em-units in
Fontforge übrigens auch verkleinert werden, sofern der SIZE-Parameter im Mapfile in der
selben Relation vergrößert wird. Man könnte also auch ein Symbol in Fontforge mit
759,15 em-units (genau die Hälfte des Wertes 1518,3) darstellen und im Mapfile mit dem
SIZE-Wert 28 belegen. Es wäre dann genau so groß wie ein Symbol mit der SIZE-Größe 14
und der Ausdehnung von 1518,3 em-units.
4.1.2 Flurstücksnummerierung
Ein relativ kompliziertes Darstellungsunterfangen liegt in der Umsetzung der
Flurstücksnummern.
Zu unterscheiden ist zwischen der Darstellung der Flurstücksnummern mit dem OS 0233
und den Flurstücksnummern in besonderer Darstellung (siehe Abbildung 27).
Abbildung 27: Darstellungsvorschriften für Flurstücksnummern aus der ZV-Aut
Quelle: Innenministerium NRW 2005, S.10
Laut ZV-Aut sollen Schriften weitgehend DIN 6776, Schriftform B entsprechen. 175
Schriften dieser Norm sind allerdings proprietär. Im FreeZVAUT-Projekt werden keinerlei
proprietäre Elemente angewendet. Schriften und Schriftableitungen werden vom Typ
„freesans“ eingebunden, da diese explizit „frei“ sind und unter die GNU-GPL fallen. Von
ihrem Erscheinungsbild ähneln diese aber dem in der ZV-Aut geforderten Schrift sehr
stark, sind allerdings ganz geringfügig kleiner. Bei einer vorgeschriebenen Darstellung
175 Innenministerium NRW 2005, S.6
74

4. Technische Realisierung
einer Flurstücksnummer in Form eines Bruchstriches tritt das Problem auf, dass Zähler
und Nenner untereinander platziert werden müssen, wobei der Nenner möglichst in der
Mitte unterhalb des Zählers liegen sollte. Zwischen den Werten ist ein Bruchstrich zu
platzieren, dessen Länge von dem Zähler abhängig ist.
Zusätzlich schwierig wird die Darstellung dadurch, dass Flurstücksnummern einen
alphanumerischen Zusatz erhalten können (wenn sie z.B. in ein Umlegungsverfahren
einbezogen sind etc.).
Innerhalb von FreeZVAUT konnte hierfür eine Lösung entwickelt werden:
Im Code des Mapfiles ist es möglich, mittels des WRAP-Befehls Eingabewerte
untereinander zu platzieren. Dieses hat den großen Vorteil, dass Zähler und Nenner
nicht als unabhängige Elemente dargestellt werden müssen. Als Trennwert dient in
diesem Beispiel der Backslash (/).
Nachfolgend soll der relevante Code aus dem Mapfile dargestellt werden:
...
CLASSITEM 'objart'
Legt die Tabellenspalte fest, in welcher der
LABELITEM 'zn'
Eintrag für die Flurstücksnummern steht.
CLASS
EXPRESSION ([objart]=0233 or [objart]=0239)
NAME 'flurstuecksnummer'
LABEL
TYPE TRUETYPE
FONT 'freesansoblique'
FORCE TRUE
PARTIALS TRUE
POSITION cl
SIZE 7
BACKGROUNDCOLOR 255 255 255
...
OFFSET 0 0
COLOR 0 0 0
WRAP '/'
END
END
Legt das Trennzeichen fest, durch welches
der Eintrag in der Datenbank bei der Ausgabe
als Bruch dargestellt wird.
Damit der Nenner auch wirklich mittig unter dem Zähler angeordnet wird, bedient
man sich eines kleinen Tricks. Der Eintrag in der Datenbank muss dahingehend
automatisiert werden, dass bei einem dreistelligen Zähler nach dem WRAP-Trennstrich (/)
zwei Leerzeichen gesetzt werden, also z.B. in dieser Form: „245/ 1“. Ist der Zähler
75

zweistellig, so wird ein Leerzeichen nach dem Trennstrich gesetzt.
4. Technische Realisierung
Durch die Leerzeichen wird der Nenner dann an der richtigen Stelle positioniert.
Die Länge des zu setzenden Bruchstriches bestimmt sich nach der Größe des Zählers.
Über Auswahlbedingungen im Mapfile wird entschieden, wann der Bruchstrich mit
welcher Länge gezeichnet wird (siehe folgenden Code).
...
CLASS
EXPRESSION (([nenner_]>0 and [zaehler_]>99)
and ([objart]= 0233 or [objart]= 0239))
NAME 'trenner_flurstueck_lang'
MAXSCALE 4000
MINSCALE 0
TEXT '___'
LABEL
...
END
END
...
CLASS
EXPRESSION (([nenner_]>0 and [zaehler_]>10
and [zaehler_]

4. Technische Realisierung
das notwendige Datenmodell (hier im Datenbankverwaltungstool phpPgAdmin
(Abbildung 28):
Abbildung 28: Datenstruktur für die Darstellung von Flurstücksnummern in
phpPgAdmin
Quelle: Eigene Darstellung
Abbildung 29 zeigt, wie die Flurstücksnummern im Mapserver präsentiert werden.
Abbildung 29: Darstellung der Flurstücksnummern im UMN Mapserver
Quelle: Eigene Darstellung
77

4.1.3 Begleitzeichen von Flur- bzw. Gemarkungsgrenzen
4. Technische Realisierung
Innerhalb der ZV-Aut sind auch Angaben zu Linien bzw. linienbegleitenden Signaturen
vorzufinden.
Die Vorschrift für das Begleitzeichen der Flurgrenze (OS 0232 der Folie 001) z.B. sagt aus,
dass die Linie eine Breite der Klasse 5 (0,5 mm) haben soll. Der lange Teil der Signatur
soll 4 mm lang sein, die Punkte 0,5 mm lang und dazwischen soll ein Abstand von 1 mm
sein (Abbildung 30).
Abbildung 30: ZV-Aut-Vorschriften für Begleitzeichen der Folie 001
Quelle: Innenministerium NRW 2005, S.13
Der Mindestabstand des Begleitzeichens von der eigentlichen Grenzlinie soll bei 0.3
mm liegen. Über den Abstand, welche die Signaturen voneinander haben sollen, sagt die
ZV-Aut nichts aus. 176
176 Innenministerium NRW 2005, S.13
78

4. Technische Realisierung
Es gibt im UMN Mapserver verschiedene Möglichkeiten linienbegleitende Signaturen
zu erstellen, welche allerdings leider auch verschiedene Begrenzungen aufweisen und
Probleme mit sich bringen (hierauf soll in Kapitel 5.1.1.2 eingegangen werden).
In diesem Falle wird die linienbegleitende Signatur durch ein TrueType-Symbol erstellt.
Der 4 mm lange Teil des Zeichens erhält in Fontforge die Ausdehnung von 1518,3 em-
units. Der 1 mm lange Zwischenbereich weist dann einen Wert von 379,5 em-units auf
und der 0.5 mm lange Zwischenstrich liegt bei 189.75 em-units (Abbildung 31).
Um einen Abstand der Signatur zu der Linie herzustellen, setzt man einfach einen
einzelnen Punkt horizontal in der jeweiligen Entfernung vom Symbol. Dieser Punkt ist so
klein, dass er bei der Ausgabe nicht erscheint, der Abstand aufgrund seiner Größe aber
schon.
Abbildung 31: Linienbegleitsignatur von OS 0232 „Flurgrenze“ in Fontforg
Quelle: Eigene Darstellung
79

4. Technische Realisierung
Das Symbol wird dann wie folgt durch eine Definition im Symbolfile eingebunden:
SYMBOL
NAME 'flurgrenze_begleitzeichen'
TYPE TRUETYPE
FILLED TRUE
ANTIALIAS TRUE
FONT 'zvaut-folie002'
CHARACTER '!'
GAP 300
END
Mittels des GAP-Parameters wird der Abstand zwischen den Begleitzeichen eingestellt.
Das Ergebnis in der Ausgabe lässt sich sehen (Abbildung 32, Begleitsignatur in rot
dargestellt).
Abbildung 32: Flurgrenzenbegleitsignatur im UMN Mapserver
Quelle: Eigene Darstellung
80

4.1.4 Aufnahmepunkte
4. Technische Realisierung
Aufnahmepunkte unterliegen einer relativ schwierigen Darstellungsvorschrift.
Die ZV-Aut sagt aus, dass ein Punkt mit einer Linienbreite von 0,18 mm und einem
Durchmesser von 2,5 mm dargestellt werden soll. Zugleich soll eine senkrechte Beschrif-
tung vorliegen, welche einfach unterstrichen ist und 3 mm rechts sowie 1,25 mm
unterhalb des Aufnahmepunktes liegt (Abbildung 33).
Abbildung 33: Darstellungsvorschrift für den Aufnahmepunkt (OS 0122, Folie 051)
der ZV-Aut
Quelle: Innenministerium NRW 2005, S.47
Damit der Punkt intransparent ist (es ist nämlich durchaus möglich, dass ein
Aufnahmepunkt z.B. auf einer Grenzlinie liegt, und diese sollte von dem Punkt überdeckt
werden) erstellt man das Symbol aus zwei Zeichen. Einmal verwendet man eine einfache
Umrisslinie (Abbildung 34) und einmal einen Hintergrundkreis (Abbildung 35).
81

4. Technische Realisierung
Abbildung 34: Umriss des Aufnahmepunktes (OS 0122, Folie 051) in Fontforge
Quelle: Eigene Darstellung
Abbildung 35: Hintergrundkreis des Aufnahmepunktes (OS 0122, Folie 051) in
Fontforge
Quelle: Eigene Darstellung
Die Tatsache, dass das Hintergrundsymbol scheinbar ein Loch aufweist, soll den
Betrachter nicht irritieren. Innerhalb Fontforges ist es möglich, durch die Richtung der
Linien zu definieren, ob ein Umriss ausgefüllt werden soll oder nicht. Die Größe der
Symbole im em-square liegt, wie nicht anders zu erwarten, bei 1518,30 em-units.
82

4. Technische Realisierung
Hintergrundkreis und Umriss werden dann über das Mapfile eingebunden. Wichtig ist
es zugleich die Beschriftung des Punktes zu integrieren.
Im Mapserver kann es zu Problemen kommen, wenn einzelne, unterschiedliche
Elemente eines Objektes skaliert werden sollen, also z.B. das Punktsymbol, dessen
Nummer und der Bruchstrich, welcher unterhalb der Nummerierung gesetzt wird.
Werden die Elemente unabhängig voneinander erstellt, dann verändern sich beim
Skalieren die Abstände der Elemente oftmals in einem Maße, welches nicht erwünscht ist.
In diesem Sinne ist es also dringend anzustreben, so viele Elemente wie möglich zu
verbinden und möglichst als „einzelnes“ Element darzustellen. In diesem Fall werden die
Punktnummer und der Bruchstrich in einem Darstellungselement integriert.
Dafür wird ein eigener Font erstellt, in welchem unter jeder Zahl automatisch ein
Unterstrich vorzufinden ist (siehe Abbildung 36). Der Punkt wird in einer solchen Länge
gezeichnet, dass auch bei einer Darstellung einer zwei- oder dreistelligen Nummer keine
Bruchstrichunterbrechung stattfindet.
Abbildung 36: Zahl mit automatisch integriertem Unterstrich in Fontforge
Quelle: Eigene Darstellung
Der Eintrag im Mapfile sieht dann aus wie folgt:
83

CLASS
EXPRESSION /0123/
NAME 'aufnahmepunkt_1.verdichtungsstufe'
STYLE
SYMBOL 'hintergrund_aufnahmepunkt'
SIZE 7
COLOR 255 255 255
END
STYLE
SYMBOL 'aufnahmepunkt_1_verdichtung'
SIZE 7
COLOR 0 0 0
END
LABEL
TYPE TRUETYPE
FONT 'freesansunderline1'
SIZE 5
COLOR 255 0 0
FORCE TRUE
POSITION cr
BACKGROUNDCOLOR 255 255 255
OFFSET 9 4
END
END
....
4. Technische Realisierung
Das Datenmodell, welches die Abfrage gewährleistet, ist denkbar einfach. Die
Darstellung ist natürlich vom Objektschlüssel (hier „objart“ genannt) abhängig. Die
Punktnummer, welche im Mapfile über das Label ausgewählt wird, hat eine eigene Spalte
(Abbildung 37).
Abbildung 37: Datenmodell für die Darstellung von Aufnahmepunkten (Folie 051)
Quelle: Eigene Darstellung
Name des für dieses Objekt
erstellten Fonts.
84

4.1.5 Flächensignaturen
4. Technische Realisierung
In Folie 021 der ALK werden Angaben zur tatsächlichen Nutzung eines Flurstückes
getätigt (siehe Abbildung 38).
Abbildung 38: Vorgaben für Flächensignaturen aus der ZV-Aut
Quelle: Innenministerium NRW 2005, S.33
Würde man diese „Signaturwolken“ nun generell darstellen, so würde dieses zu
Schwierigkeiten führen. Tatsache ist, dass diese Signaturen für bestimmte Polygone
einfach zu groß sind, Grenzen überlappen und keine eindeutige Information
gewährleisten würden (siehe Abbildung 39).
Abbildung 39: Flurstücke überlappende Flächensignaturen im UMN Mapserver
Quelle: Eigene Darstellung
In der ZV-Aut steht allerdings explizit, dass sich die Ausgestaltung der
Flächensignaturen nach Größe und Gestalt des Flurstückes richtet. „Ausnahmsweise kann
85

4. Technische Realisierung
die Darstellung auf ein oder mehrere Signaturelemente beschränkt werden. Bei
Splissflurstücken kann die Darstellung der tatsächlichen Nutzung entfallen.“ 177
Hier wurde nun so verfahren, dass für die relativ großflächigen „Signaturwolken“
Signaturen erstellt wurden, welche auch auf deutlich kleineren Flächen unbedenklich
eingesetzt werden können. Verschiedene Elemente aus den Signaturen wurden entfernt
und die verbleibenden Elemente näher zusammengerückt. Dieses ist dennoch ZV-Aut-
konform. Die Zeichensyntax und damit die Aussagekraft bleibt bestehen.
Das Symbol für die Streuobstwiese beispielsweise sieht nach der „Komprimierung“
folgendermaßen aus (siehe Abbildung 40):
Abbdildung 40:„Einzelsymbol“ für Streuobstwiese (OS 6220, Folie 021) in Fontforge
Quelle: Eigene Darstellung
Um nun allerdings die Flächensignaturen (als „Signaturwolke“ oder „verkleinerte
Signatur“) automatisiert setzen zu können, bedarf es in dem Datenmodell einer Angabe,
welche indirekt eine Aussage über die Flächenbreite des Polygons besitzt.
Wichtig: Es geht hier nicht um die reine Fläche sondern eher darum, wie breit das
Polygon ist. In diesem Sinne ist das Verhältnis der Fläche zu dem Umfang des Polygons
177 Innenministerium NRW 2005, S.29
86

4. Technische Realisierung
ausschlaggebend. Wenn also Fläche/Umfang einen bestimmten Wert unterschreitet, dann
sollte das kleinere Symbol gezeichnet werden.
Hierfür konnte eine Lösung entwickelt werden. PostGIS stellt zahlreiche Funktionen
zur Verfügung, welche zur Analyse der Geomtrie dienen.
Mit den Funktionen area(the_geom) und perimeter(the_geom) werden Fläche und
Umfang der Flurstücke gemessen. Mit der Funktion contains (the_geom, the_geom)
kann ermittelt werden, ob eine Geometrie innerhalb einer anderen liegt.
In der Tabelle „f021_p_punktsignaturen“ der Datenbank nun gibt es keine Angaben zu
der Flurstückgröße bzw. zu ihrem Umfang (diese Daten liegen in der Tabelle der
Flurstücksflächen (hier: „f001_f“)). Da jedoch die Punktkoordinate der Flächensignaturen
innerhalb der Flurstückspolygone liegt, kann man mittels einfacher SQL-Befehle diese
Fläche bzw. diesen Umfang ermitteln. Zunächst werden zwei Spalten „flurstuecksflaeche“
und „flurstuecksumfang“ erstellt.
Dann wird die Fläche folgendermaßen ermittelt bzw. in die Tabelle übernommen:
UPDATE f021_signatur_p SET flurstuecksflaeche= area (f001_the_geom) FROM
f001_f WHERE contains (f001_f.the_geom,f021_signatur_p.the_geom);
Der Umfang wird wie folgt in die Tabelle geschrieben:
UPDATE f021_signatur_p SET flurstuecksumfang= perimeter(f001_f.the_geom) FROM
f001_f WHERE contains (f001_f.the_geom,f021_signatur_p.the_geom);
Aus diesen beiden Werten wird dann ganz einfach ein Faktor erstellt: Die Fläche wird
durch den Umfang geteilt.
Einen Auszug aus dem Datenmodell stellt Abbildung 41 dar:
87

4. Technische Realisierung
Abbildung 41: Datenstruktur zur Darstellung der tatsächlichen Nutzung (Folie 021)
Quelle: Eigene Darstellung
Der Faktor „factor“ sagt letztlich aus, wie „breit“ die Flächen sind. Je größer der Faktor,
desto eher würde eine „Signaturwolke“ in das Flurstück passen, ohne die Grenzen zu
überlappen.
Im Mapfile wird dann festgelegt, dass unterhalb eines bestimmten Faktorwertes
Einzelsignaturen dargestellt werden, bzw., wenn dieser Faktor überschritten wird,
„Signaturwolken“.
Nachfolgend der relevante Code für die Einzelsignaturen auf den „kleineren Flächen“:
....
LAYER
NAME 'nutzungsarten_kleine_flaechen'
TYPE ANNOTATION
STATUS DEFAULT
CONNECTIONTYPE postgis
CONNECTION 'user=postgres dbname=zvaut host=localhost port=5432'
DATA 'the_geom from f021_signatur_p'
FILTER "factor

4. Technische Realisierung
Abbildung 42: ZV-Aut-konforme Darstellung von Flächensignaturen im UMN
Mapserver
Quelle: Eigene Darstellung
Mittels der auf den Seiten 67-88 dargestellten Techniken lassen sich eine immense
Vielzahl von Symbolen problemlos erstellen.
Bei einem Blick ins Repository auf
„https://wald.intevation.org/plugins/scmsvn/viewcvs.php/?root=freezvaut“
ist zu erkennen, dass neben dem äußerst komplexen Map- und Symbolfile (4800 bzw.
2000 Zeilen) insgesamt 13 TrueType-Fonts erstellt wurden.
Diese enthalten ca. 170 Symbole (ca. 90 % aller benötigten Objekte) sowie die für die
ZV-Aut notwendigen Beschriftungen. Dennoch gibt es auch verschiedene Signaturen in
der ZV-Aut, welche nicht ohne weiteres oder aber nur mit Schwierigkeiten dargestellt
werden können. Auf diese Punkte wird in Kapitel 5 eingegangen.
Nachfolgend soll zunächst die technische Umsetzung des Auskunftssystems erläutert
werden.
89

4. Technische Realisierung
4.2 Technische Umsetzung des Flurstücksauskunftssystems
Für das Auskunftssystem wurden die Ergebnisse des FreeZVAUT-Projektes in eine
entsprechende Oberfläche eingebunden (siehe Abbildung 43). Das Auskunftssystem
wurde mittels HTML, PHP, PHP/Mapscript, Javascript sowie Postgresql/PostGIS umgesetzt.
Betrachtet werden kann es auf einem Server der Universität Osnabrück unter:
http://131.173.78.240/diplomarbeit_freezvaut/startskript.phtml
Zunächst einmal ist es möglich, mittels dieser Anwendung einzelne Flurstücksfolien
an- bzw. auszuschalten und sich einzelne Flurstücke, ausgewählt nach ihrer Nummer, in
der Karte anzeigen zu lassen.
Abbildung 43: Oberfläche des Flurstücksauskunftyssystems
Quelle: Eigene Darstellung
In der Karte selber kann man navigieren, hinein- und herauszoomen (mit einem
verstellbaren Zoomfaktor) und die Karte auf die Gesamtausdehnung setzen.
90

Auch können anhand von Attributen Flurstücke ausgewählt werden.
4. Technische Realisierung
Gefiltert werden kann nach Flurstücksgröße, Grundstückspreis, dem aktuellen Eigentümer
sowie dem Status der Fläche im (fiktiven) Flächennutzungsplan.
Flurstücke können angeklickt und deren Daten angezeigt werden.
Innerhalb der Anwendung wird dynamisch der aktuelle Kartenmaßstab, eine
Maßstabsleiste sowie eine Legende zu ausgewählten Flurstücken präsentiert.
Eine dynamische Referenzkarte stellt dar, wo sich der Kartenausschnitt in der Hauptkarte
gerade befindet.
Schlussendlich ist aus juristischen Gründen ein Link zum Impressum und zur Datenlizenz
beigefügt.
4.2.1 Attribute der Flurstücksflächen
An dieser Stelle soll darauf hingewiesen werden, dass an die zur Verfügung stehenden
Daten aus Brandenburg teilweise per Zufallsgenerator fiktive Daten angehängt wurden.
So haben die Flurstücke auch die Attribute Eigentümer, eine fiktive Deklaration aus
einem Flächennutzungsplan und einen Kaufpreis. Letzterer errechnet sich aus fiktiven m²-
Preisen, der Flächengröße sowie der Größe des eventuell vorhandenen Gebäudes.
Da es hierbei nur um eine beispielhafte Anwendung geht, spielt es an dieser Stelle keine
Rolle, ob nun fiktive oder aber reale Attribute eingesetzt werden.
Die Flächengröße der Flurstücke sowie der Gebäude wurde mittels PostGIS-Funktionen
ermittelt.
Die Ermittlung der Gebäudeflächen pro Flurstück war eine hoch interessante Aufgabe.
Die Gebäude werden innerhalb einer eigenen Folie (Folie 011) und somit auch einer
eigenen Datentabelle („f011_f“) dargestellt; Flurstücke werden, wie bereits erwähnt, in
der Datenbank in der Tabelle „f001_f“ gespeichert. Damit nun aber das Attribut
„Gebäudefläche“ in die Tabelle „f001_f“ übernommen werden kann, muss eine
Verschneidung der Flurstücksgeometrien mit den Geometrien der Gebäude stattfinden,
wobei die verschnittenen Flächen gruppiert nach Flurstück addiert werden.
Hierfür wurde zunächst mittels folgendem Befehl eine eigene, neue Tabelle angelegt:
91

4. Technische Realisierung
CREATE TABLE neue_tabelle as SELECT sum(area(intersection
(f001_f.the_geom,f011_f.the_geom)))
AS intersection_geom, f001_f.zn FROM f001_f,f011_f Where f001_f.the_geom &&
f011_f.the_geom AND intersects(f001_f.the_geom,f011_f.the_geom)Group by f001_f.zn
Anschließend wurden diese Werte dann in die Tabelle „f001_f“ überführt.
Abbildung 44 stellt einen Auszug aus der Tabelle dar.
Zu den einzelnen Flurstücken werden hier die realen Attribute „flurstuecksflaeche“ und
„gebauedeflaeche“ sowie der fiktive Grundstückswert dargestellt.
Abbildung 44: Auszug aus der Flurstückstabelle „f001_f“
Quelle: Eigene Darstellung
92

4.2.2 Layerauswahl
4. Technische Realisierung
In einem Auskunftssystem zu Flurstücken macht es Sinn, dem Nutzer die Aktivierung
bzw. Deaktivierung von einzelnen Folien zu gewährleisten, da sich die ALK schließlich
additiv aus diesen Folien zusammensetzt.
Der Anwender kann somit entscheiden, mit welcher Komplexitität er sich die Karte
anschauen möchte. In Abbildung 45 sind beispielsweise lediglich die Flurstücke (Folie
001) sowie die Beschriftungen (Folie 081) aktiviert.
Abbildung 45: Verschiedene Layer deaktivert
Quelle: Eigene Darstellung
Technisch wird diese Anwendung über ein simples PHP-Skript in Verbindung mit
PHP/Mapscript realisiert. Auszugsweise soll erklärt werden, welche Mechanismen hier
ablaufen:
93

4. Technische Realisierung
Über die Checkboxes kann ausgewählt werden, welcher Layer aktivert bzw. dekativert
werden soll. Je nachdem, welche Layervariablen übergeben werden, werden diese in
einem String gespeichert, welcher als Variable „$layers“ genannt wird:
if ($_POST['layer']) {
$layers= join(" ",$_POST['layer']); }
else {
$layers=""; }
Anschließend wird geprüft, welche Layervariablen übergeben wurden.
Zu unterscheiden ist zwischen Layern, welche nur aus einem Element bestehen (z.B.
Straßenbeschriftungen) und Layern, welche aufgrund ihrer Komplexität gruppiert werden
müssen. Der Layer der Folie 001 z.B. setzt sich letztlich aus mehreren Einzellayern
zusammen (Flurstückgsgrenzen, Flurstücksnummern, Attribute zu Flurstücksnummern
etc.).
Nachfolgend soll kurz der Code für zu aktivierende Gruppenlayer erläuert werden.
Dieser setzt sich zusammen aus PHP sowie PHP/Mapscript-Befehlen:
$layerwerteklickgruppe=array("/f001/","/f002/","/f011_gebauede/","/f021_nutzungsart/"
);
$layerausmapfileindexbygoup=array("folie001","folie002","gebauede","nutzungsarten");
for ($y=0;$ygetLayersIndexByGroup ($layerausmapfileindexbygoup[$y]);
$layernamen= join(" ",$go);
$zahl= count ($go);
for ($i=0;$igetlayer($go[$i]);
$derlayer->set('status',MS_ON);
$layerausmapfileindexbygoup[$y]= "CHECKED"; }}}
Hierbei wird mit zwei Arrays gearbeitet.
Für den Fall, dass z.B. die Folie 001 aktiviert werden soll, würde der Eintrag „f001“ in der
Variable „$layers“ vorliegen. Anschließend wird durch die Zeile
Variable, welche aktivierte Layernamen enthält
$go = $map ->getLayersIndexByGroup ($layerausmapfileindexbygoup[$y]);
94

4. Technische Realisierung
festgesetzt, dass dieser Layer aus Einzellayern zusammengesetzt wird, welche im Mapfile
unter dem Eintrag GROUP 'folie001' gruppiert werden.
Durch den Befehl
$zahl= count ($go);
wird gezählt, wie viele Einzellayer vorliegen. Dieser Wert wird in eine Schleife gesetzt:
for ($i=0;$igetlayer($go[$i]);
$derlayer->set('status',MS_ON);
$layerausmapfileindexbygoup[$y]= "CHECKED";
}
Die Schleife sorgt dafür, dass die relevanten Layer auf den Status MS_ON gesetzt und
somit aktiviert werden. Zugleich wird in der Checkbox des Gesamtlayers nun ein Häkchen
gesetzt wird.
4.2.3 Flurstücksauswahl
Eine einzelne Flurstücksauswahl macht Sinn, damit sich ein Nutzer in einer Anwendung
mit vielen Flurstücksflächen schnell und einfach eine gewünschte Fläche anzeigen lassen
kann.
Mittels PHP und der Anbindung an die Postgresql-Datenbank wird die Anzahl der
vorhandenen Flurstücke ermittelt.
Die vorhandenen Flurstücksnummern werden durch einen in eine PHP-Funktion
integrierten SQL-Befehl ausgewählt:
$abfrage= pg_query ("SELECT zaehler_,zn,attribut from f001_f order by zaehler_");
Es wird dann ermittelt, wie viele Einträge in der Datenbank vorliegen. Entsprechend
dieser Anzahl werden diese dann durch eine Schleife in einem HTML-Select-Bereich
dargestellt.
Der Befehl „echo "Nummer: ".$zn.' '.$attribut;“ gibt letztlich den String zu dem Zähler
und dem Nenner sowie das eventuell vorhandene Flurstücksattribut aus.
Nachdem man ein Flurstück ausgewählt hat und die Auswahl mittels des
95

4. Technische Realisierung
„Start“-Buttons bestätigt wurde, wird dieses in der Anwendung in einem leichten grün
dargestellt. Auch wird automatisch das Flurstück zentriert in der Karte dargestellt (siehe
Abbildung 46). Sofern gewünscht werden auch bestimmte Daten des Flurstücks
angezeigt.
Abbildung 46: Flurstück ausgewählt nach seiner Nummer
Quelle: Eigene Darstellung
Der Code, welcher für die zentrierte Darstellung einer Fläche in der Karte
verantwortlich ist, lautet wie folgt:
$einzelflurstueckselektiert->setExpression('(\'[zn]\'eq\''.$_POST["flstk"].'\')');
$flurnumber= $_POST["flstk"];
if (isset($HTTP_POST_VARS["einzeldarstellung"])) {
$conn = pg_connect ("host=localhost port=5432
dbname=zvaut user=postgres");
$abfrage= pg_query ("SELECT
96

4. Technische Realisierung
xmin(the_geom),ymin(the_geom),xmax(the_geom),ymax(the_geom) from f001_f WHERE
zn='$flurnumber'");
$resultat= pg_fetch_array($abfrage, 0);
$my_extent->setextent($resultat[0],$resultat[1],$resultat[2],$resultat[3]);
$my_point->setXY(260,260);
$map->zoompoint(-2,$my_point,$map->width,$map->height,$my_extent);
Es wird eine sogenannte „Expression“ gesetzt, welche im Mapfile dafür sorgt, dass
innerhalb eines separat angelegten Layers nur jene Fläche mit einem leichten grün
markiert wird, deren Flurstücknummer dem in der Auswahlliste entspricht:
$einzelflurstueckselektiert->setExpression('(\'[zn]\'eq\''.$_POST["flstk"].'\')');
Dann werden über eine Abfrage und PostGIS-Funktionen die Koordinaten ermittelt,
welche um das Flurstück liegen (minimaler Rechts- und Hochwert sowie maximaler
Rechts- und Hochwert) und in einem Array gespeichert:
$abfrage= pg_query ("SELECT
xmin(the_geom),ymin(the_geom),xmax(the_geom),ymax(the_geom) from f001_f WHERE
zn='$flurnumber'");
$resultat= pg_fetch_array($abfrage, 0);
Basierend auf diesen Werten wird dann der entsprechende Ausschnitt in der Karte
gesetzt:
$my_extent->setextent($resultat[0],$resultat[1],$resultat[2],$resultat[3]);
$my_point->setXY(225,225);
$map->zoompoint(-2,$my_point,$map->width,$map->height,$my_extent);
97

4.2.4 Navigation
4. Technische Realisierung
Eine leistungsfähige Navigation gehört zu den Standardfunktionen in einer
Kartenanwendung.
Die Navigationsleiste in dem Auskunftssystem wird in Abbildung 47 dargestellt.
Abbildung 47: Navigationsleiste in dem Flurstücksauskunftssystem
Quelle: Eigene Darstellung
Das Panning in der Karte wird dadurch gewährleistet, dass man durch einen Klick in
die Karte Pixelkoordinanten an die Variable „kartenklick“ übergibt:

4.2.5 Flächenabfrage
4. Technische Realisierung
Innerhalb des Auskunftssystems kann der Nutzer verschiedene Attribute auswählen
und sich somit Flurstücke mit bestimmten Eigenschaften aussuchen.
Stellen wir uns nun jemanden vor, welcher in dem Ort investieren und ein Unternehmen
gründen möchte. Hierfür ist ein Flurstück in einem Gewerbegebiet gesucht, welches eine
Mindestfläche von 500 m² aufweisen soll. Das Flurstück darf maximal 500.000 Euro wert
sein, da es ansonsten für den Käufer unerschwinglich wird.
Nach der Auswahl dieser Attribute werden die entsprechenden Flurstücke in einem
leichten rot angezeigt (Abbildung 48). Der interessierte Nutzer weiß nun, welche Flächen
für ihn von Interesse sind.
Abbildung 48: Nach Attributen ausgewählte Flurstücke
Quelle: Eigene Darstellung
99

4. Technische Realisierung
Die Flurstücksauswahl geschieht über eine komplexe Filterfunktion innerhalb von
PHP/Mapscript:
$flurstuecksflaechenselektiertlayer->setExpression('([the_area]>='.$faktor1.'AND
[gesamtpreis]'.$faktor2.' AND \'[eigentuemer]\'eq\''.$faktor3.'\'AND
\'[deklaration]\'eq\''.$faktor4.'\')');
Wird diese Filterbedingung erfüllt, so werden in einem separaten Layer die
entsprechenden Polygone angezeigt.
4.2.6 Datenanzeige
Unabhängig davon, ob Flurstücke bereits nach Attribut oder Nummer ausgewählt
wurden, kann sich der Nutzer detaillierte Informationen zu einzelnen Flächen anzeigen
lassen. Hierfür muss die Datenanzeige aktiviert und auf ein einzelnes Flurstück geklickt
werden.
Anschließend werden Angaben zur Größe des Flurstückes bzw. zu eventuell vorhandener
Gebäudefläche übermittelt. Man erfährt, wer der momentane Eigentümer ist, den Status
im Flächennutzungsplan und den (fiktiven) monetären Wert der Fläche (siehe Abbildung
49).
Hierbei wird zunächst ermittelt, in welchem Flurstück der angeklickte Punkt liegt.
Für eine diesbezügliche Attributabfrage müssen Realkoordinaten vorliegen. Über eine
erstellte Funktion werden also zunächst die übergebenen Pixelkoordinaten der Karte in
Realkoordinaten umgerechnet.
Dann wird ermittelt, welches Flurstück die übertragenen Realkoordinaten beinhaltet.
Anschließend werden die entsprechenden Attribute ganz simpel aus der Datenbank
gelesen und in der Anwendung präsentiert.
100

Abbildung 49: Datenanzeige zu einem einzelnen Flurstück
Quelle: Eigene Darstellung
4. Technische Realisierung
101

5. Diskussion und Ausblick
5.1 Diskussion und Ausblick von FreeZVAUT
5. Diskussion und Ausblick
Nach Auffassung des Autors können ALK-Daten im UMN Mapserver zwar nicht zu
100% den Anforderungen der ZV-Aut entsprechend umgesetzt werden, die Vorschriften
werden jedoch zu einem großem Teil erfüllt (zu annähernd 90%).
Dieser Punkt wurde auch schon in der Developerliste des FreeZVAUT-Projektes in
Ansätzen diskutiert.
In der ersten Ankündigungsversion des FreeZVAUT-Projektes war noch zu lesen:
„Nein, 100% ZVAut-konform ist es immer noch nicht, und wird es auch nie sein.“ 178
Dieser Formulierung wurde teilweise widersprochen, da die Firma CCGIS bezogen auf den
Datenbestand des Oberbergischen Kreises und deren ALK-Auskunftssystem immerhin die
Genehmigung „Amtliche Karte“ erhalten hat. Eine rechtskonforme Darstellung ist also
durchaus möglich. 179 Dennoch ist es faktisch und technisch richtig, dass eine 100%
vorschriftskonforme Ausgabe mit dem UMN Mapserver nicht gewährleistet werden kann.
Zu bedenken ist, dass die ZV-AUT Vorgaben für ein analoges Kartenwerk beinhaltet und
nicht für eine Kartenanwendung im Web.
„Die ZV-Aut ist nun mal eine Papier-kartographische und nicht auf digitale Belange
optimierte Zeichenvorschrift, die deshalb auch mit ein paar technischen Einschränkungen
rechtskonform sein kann, auch wenn sie nicht 100% zeichenkonform ist.“ 180
Nachfolgend sollen nun verschiedene Schwierigkeiten des FreeZVAUT-Projektes sowie
des Auskunftssystems erläutert werden.
178 http://lists.wald.intevation.org/pipermail/freezvaut-devel/2005-December/000025.html vom
1.6.2006
179 http://lists.wald.intevation.org/pipermail/freezvaut-devel/2006-January/000030.html vom
1.6.2006
180 http://lists.wald.intevation.org/pipermail/freezvaut-devel/2006-January/000030.html vom
24.5.2006
102

5.1.1 Mapserverspezifische Schwierigkeiten
5.1.1.1 Größenangaben
5. Diskussion und Ausblick
Wie schon angesprochen, stellt der Mapserver seine Rasterkarten in 72 dpi zur
Verfügung.
In der ZV-Aut gibt es präzise Vorschriften zu Linienunterteilungen. So werden hier z.B.
folgende Vorgaben festgelegt: 181
● Klasse 5 (0,5 mm)
● Klasse 4 (0,35 mm)
● Klasse 3 (0,25 mm)
● Klasse 2 (0,18 mm)
Die Tatsache, dass SIZE-Angaben, welche sich auf die Linienbreite beziehen, nur in
Integerwerten angegeben werden können, macht eine so genaue Linienunterteilung
unmöglich. Bei der Darstellung der Klassen 2, 3 und 4 gibt es keine Unterschiede, da
diese alle mit der Größe „SIZE 1“ gezeichnet werden. Auch ist anzumerken, dass durch
das manuell durchgeführte Auf- und Abrunden der SIZE-Werte (siehe Seite 68) zwar die
größtmögliche Genauigkeit erreicht wird, die Werte jedoch nicht im absoluten Sinne ZV-
Aut konform sind. Die Abweichungen sind jedoch marginal.
5.1.1.2 Begleitzeichen von Flur- bzw. Gemarkungsgrenzen
Innerhalb von Kapitel 4.1.3 wurde bereits beispielhaft auf Vorschriften der
linienbegleitenden Signaturen eingegangen und auch erwähnt, dass es verschiedene
Möglichkeiten zur diesbezüglichen Erstellung gibt.
In der Symboldatei ist es möglich, Liniensignaturen zu erstellen, welche mit bestimmten
Unterbrechungen gezeichnet werden. Der Standardweg würde wie folgt aussehen:
181 Innenministerium NRW 2005, S.6
103

SYMBOL
NAME 'flurgrenze_begleitzeichen'
TYPE VECTOR
POINTS
0 1
1 1
1 0
0 0
END
STYLE
11
3
1
3
1
56
END
...
5. Diskussion und Ausblick
Dieser Code würde bedeuten, dass eine Linie von 4 mm gezeichnet wird, dann 1 mm
nicht, dann wird ein Zeichen der Länge 0,5 mm erstellt, dann 1 mm lang nicht etc..
Schlussendlich wird der Abstand zwischen den einzelnen Zeichen auf 2 cm (SIZE 56)
gesetzt. Auf diese Art könnte man vermeintlich bequem eine Signatur nach der
Zeichenvorschrift erstellen.
Leider gibt es dabei doch einige Schwierigkeiten.
Um einen Abstand eines Zeichens/einer Signatur von einer Linie einzustellen, verwendet
man den sogenannten OFFSET-Parameter im Mapfile:
END
CLASS
NAME 'flurgrenze_bgleitzeichen'
EXPRESSION /0232/
STYLE
SYMBOL 'flurgrenze_begleitzeichen'
COLOR 0 0 0
OFFSET 3 3
OFFSET-Parameter
SIZE 3
END
104

5. Diskussion und Ausblick
Der Wert von 3 3 sagt aus, dass eine linienbegleitende Signatur jeweils 3 Pixel in x- bzw.
y-Richtung verschoben wird. Allerdings orientieren sich die x- und y-Paramater beim
OFFSET leider nicht an der Linie sondern am Kartenbild. Das bedeutet, dass alle Zeichen
wiederholt in die gleiche Richtung verschoben werden, egal in welche Richtung die Linie
verläuft. Es ergbit sich eine Verschiebung derart wie in Abbildung 50, und das wäre
natürlich nicht ZV-Aut-konform (die schwarze Linie kennzeichnet hier ein
Ausgangsobjekt, die gestrichelte rote Linie eine linienbegleitende Signatur).
Abbildung 50: Linienbegleitende Signatur mit Orientierung am Kartenbild
Quelle: Eigene Darstellung
Um einen gleichmäßigen Abstand zu einer Linie zu erzeugen, kann man im Mapfile z.B.
OFFSET 3 -99 angeben. Das Begleitzeichen wird dann immer im selben Abstand um ein
Polygon (z.B. ein Flurstück) gesetzt (siehe Abbildung 51 auf der folgenden Seite).
105

5. Diskussion und Ausblick
Abbildung 51: Linienbegleitende Signatur mit Orientierung an der Linie
Quelle: Eigene Darstellung
Dennoch gibt es auch hier Schwierigkeiten. Zum einen werden Linienmuster auf Linien
mit vielen Ecken und Kurven im UMN Mapserver sehr unregelmäßig dargestellt, und (und
das ist das Hauptproblem!) Abstände und Längen der Linienabschnite werden nicht
mitskaliert. Verändert man also durch Zoomen den Maßstab, so bleiben die
Linienabschnitte immer gleich und nur die Breite der Linie verändert sich.
Das Muster verändert sich scheinbar, und das ist in einer ALK-Webgis-Anwendung
natürlich sehr ungünstig und muss daher vermieden werden.
Die relativ umständliche Lösung liegt daher in der Erstellung einer liniengegleitenden
Signatur im Rahmen eines TrueType-Symbols wie in Kapitel 4.1.3 geschildert.
Bedauerlich ist auch, dass man bei linienbegleitenden TrueType-Zeichen keinen
OFFSET-Paramter anwenden kann, und dass es somit nicht möglich ist, diese Zeichen
gleichmäßig gegeneinander versetzt zu zeichnen, was für verschiedene Symbole
interessant wäre.
106

5.1.1.3 Druck
5. Diskussion und Ausblick
Durch die relativ geringe Auflösung, in welcher Rasterkarten per se am Bildschirm
ausgegeben werden, ist die Darstellungsqualität a priori begrenzt; dieser Begrenzung
muss man sich bewußt sein. Da eine Fülle von millimetergenauen Angaben in der ZV-Aut
zu finden sind, kann eine Druckausgabe nur in wesentlich höherer Auflösung stattfinden.
Das Ziel sollte es nun sein, Karten des Mapservers nicht in 72 dpi sondern
automatisiert in einer höheren Ausgabe darzustellen.
Ein in der Praxis sehr häufiges Vorgehen liegt darin, dass ein eigenes Mapfile sowie ein
Symbolfile für den Druck geschrieben wird. In diesem sind sämtliche ursprünglichen SIZE-
Werte mit 4 multipliziert.
In der Ausgabe der Karte dann wird die Karte im HTML-Code auf ein Viertel reduziert,
die Auflösung liegt dann bei 288 dpi.
Ein Beispiel: Eine Ursprungskarte hat eine Ausdehnung von 500 x 500 Pixeln und Linien
mit einer SIZE-Angabe von 2. In dem für den Druck geschriebenen Mapfile hat die Karte
eine Ausdehnung von 2000 x 2000 Pixeln und die Linie einen SIZE-Wert von 8 Pixeln.
In der HTML-Ausgabe wird die Karte dann über Parameter zu Breite und Höhe
(width=“500“ height=“500“) gestaucht und erhält somit eine höhere Auflösung.
Innerhalb des FREEZVAUT-repository finden sich auch ein Map- bzw. Symbolfile für den
Druck vor.
Dennoch wäre es weniger umständlich, wenn es ein Skript gäbe, was je nach
gewünschter Auflösung die Umrechung der Größenangaben in den relevanten Dateien
vollzieht. Dieses gilt es langfristig zu entwickeln.
Der Druck der Karte ist also etwas, was in der Zukunft noch optimiert werden könnte.
5.1.2 Edbsilonspezifische Schwierigkeiten
5.1.2.1 Eigene Geometrie
Ein Problem in Edbsilon ist im Augenblick noch die Tatsache, dass Flurstücksnummern
nach deren Überführung aus einem EDBS-Satz keine eigene Geometrie, also keine
107

5. Diskussion und Ausblick
Punktkoordinaten, aufweisen. Nach Auffassung des Autors ist dieses für eine ZV-Aut-
konforme Darstellung eminent wichtig.
Die Flurstücksnummern werden im Mapserver als Attribute von Polygonen dargestellt.
Die genannten Umstände bringen es mit sich, dass die Flurstücksnummern in der
Betrachtung „wandern“. Sie nehmen keine feste Position auf der Karte ein sondern
ordnen sich automatisch etwas in der Mitte des jeweiligen Polygons an. Dieses bezieht
sich leider immer auf die sichtbare Fläche eines Polygons. Selbst wenn also nur ein Teil
eines Flurstücks sichtbar ist, so ordnen sich diese Flurstücksnummern in diesem Falle
relativ mittig in dem sichtbaren Polygon an.
Abbildung 52 zeigt, dass diese Anordnung im Mapserver zudem uneinheitlich
stattfindet. Im rotumrandeten Bereich erkennt man, dass sich die Flurstücksnummern
einmal eher links und einmal eher rechts im Polygonteil befinden. So lange für
Flurstücksnummern keine Punktgeometrie vorliegt kann es, insbesondere bei kleineren
Maßstäben, zu sehr unschönen Überlappungen von anderen Objekten kommen - und
dieses ist nicht ZV-Aut konform.
Abbildung 52: Überlappende Darstellung von Flurstücksnummern
Quelle: Eigene Darstellung
Die Koordinaten der Flurstücke sind in EDBS-Datensätzen vorhanden. Ein in der Zukunft
umzusetzender Punkt wäre es also, diese bei der Konvertierung durch Edbsilon zu
übernehmen.
108

5.1.2.2 Winkelangabe
Ein Problem ist bislang noch die Winkelangabe bei Hausnummern.
5. Diskussion und Ausblick
Zwar wird nach Konvertierung der EDBS-Daten durch Edbsilon auch eine Spalte mit einer
Winkelangabe erstellt. Der Winkel der Hausnummern entspricht jedoch bislang noch
nicht den Anforderungen der ZV-Aut. Hier ist nämlich zu lesen, dass eine Hausnummer
„mit dem Fuß oder dem Kopf stets nach der Straßenseite so anzubringen (ist), dass sie in
Blickrichtung der Abzissenachse des GK-Koordinatensystems lesbar ist. 182
Es muss also eine Orientierung an den Begrenzungen der Straßengeometrien erfolgen.
Diese Begrenzungen werden durch Objekte der Folien 081 dargestellt.
Das Problem der Winkelangabe tritt auch bei den Gebäudeschraffuren auf. Hier ist in
der ZV-Aut zu lesen, dass Wohngebäude „unter einem Winkel von 50 gon zu der längsten
Gebäudeseite und - von der Ordinatenachse des Gauß-Krüger-Koordinatensystems aus
gesehen – nach rechts oben steigend schraffiert“ werden. Alle anderen Gebäude werden
rechtwinklig zur längsten Gebäudeseite schraffiert. 183
Eine Winkelmessung muss sich also jeweils an den längsten Gebäudeseiten orientieren.
Dieses gilt es noch in Edbsilon zu entwickeln.
182 Innenministerium NRW 2005, S.21
183 ebda., S.18
109

5.1.2.3 Doppelte Polygongrenzen
5. Diskussion und Ausblick
Bislang liegen nach der Konvertierung durch Edbsilon noch doppelte Polygongrenzen,
z.B. bei Flurstücken, vor. Dieses führt dazu, dass im Falle von Linienbegleitsignaturen
diese, wie in Abbildung 53, doppelt gezeichnet werden.
Abbildung 53: Doppelte Begleitsignatur an Polygongrenzen
Quelle: Eigene Darstellung
Zwar ist es möglich, die Symbole an einer Polygongrenze einheitlich auszurichten und
durch den GAP-Parameter in der Symboldatei den Abstand der Signaturen voneinander
so hoch zu setzen, dass eine „Doppelhaltung“ in der Karte kaum auffällt (dieses Vorgehen
wurde auch in Kapitel 4.1.3 praktiziert, einen Eindruck davon gibt Abbildung 32 auf Seite
80), es gibt jedoch auch Signaturen, bei denen dieses aufgrund der ZV-Aut-Vorgaben
nicht möglich ist (siehe Abbildung 54).
110

Abbildung 54: Begleitsignaturen der ZV-Aut (Folie 082)
Quelle: Innenministerium NRW 2005, S.97
5. Diskussion und Ausblick
Bei dem topographisch bedeutenden Zaun bzw. dem topographisch bedeutenden Wall
sind klare Vorgaben gesetzt, in welchem Maße Signaturen voneinander entfernt sind bzw.
gegeneinander versetzt sind.
Durch eine auftretende „Doppelzeichnung“ an einer Polygongrenze kann kein eindeutiger
Abstand zwischen Symbolen festgelegt werden.
Es ergäbe sich somit beispielsweise eine Darstellung wie in Abbildung 55:
Abbildung 55: Nicht-ZV-Aut-konforme Darstellung von OS 0353 der Folie 082
Quelle: Eigene Darstellung
Die Lösung kann also nur sein, dass es keine doppelte Polygongrenzenführung gibt,
111

eine Polygongrenze dürfte nur als eine einzelne Linie dargestellt werden.
5. Diskussion und Ausblick
Ausdrücklich zu begrüßen ist übrigens die Tendenz, dass im Rahmen des FreeZVAUT-
Projektes die Datenmodelle der EDBS-Konverter Edbsilon und EDBS2WKT (entwickelt von
Frank Jäger aus dem Kommunalen Rechenzentrum Minden-Ravensberg/Lippe)
homogenisiert werden sollen. Dieses würde dann bedeuten, dass auch EDBS2WKT im
Rahmen von FreeZVAUT verwendet werden könnte.
112

5.2 Flurstücksinformationssystem
5. Diskussion und Ausblick
Für ein leistungsfähigeres Auskunftsystem wären mehr Daten, welche an Flurstücke
angehängt werden können, wünschenswert. Dennoch zeigt das Auskunftssystem das
Prinzip auf, was bei entsprechenden Daten möglich ist.
Der Nutzer im Web kann sich gezielt und ohne besonderen Aufwand Flurstücke einer
Gemeinde anzeigen lassen. Er kann bestimmte Attribute angeben und somit innerhalb
der Grundstücke selektieren. Auch können je nach Flurstück dessen Attribute angezeigt
werden.
Schnell wird deutlich, welche Flächen für eine bestimmte Nutzung in Frage kommen.
Innerhalb der vorgegebenen Anwendung (und der vorhandenen Daten) können einfach
und unkompliziert Flurstücke gefunden werden, welche sich für einen Kauf und eine
bestimmte Nutzung eignen (oder auch nicht eignen).
Je nach Datenmaterial könnte ein Auskunftssystem dieser Art für Privatpersonen,
Wirtschaft oder Verwaltung eine sehr wichtige Rolle spielen.
Durch die Funktionen des Zoomens und des Pannings sowie der Maßstabsangabe bzw.
-leiste ist auch eine Navigation in der Anwendung denkbar einfach.
Eine Schwierigkeit ergab sich nach Auffassung des Autors in der Darstellung einer
Legende.
Denkbar wäre es, zu sämtlichen vorhandenen Folien und Symbolen einen Eintrag
festzusetzen.
Hierbei treten allerdings verschiedene Schwierigkeiten auf.
Durch die erstellten Linien (z.B. Flurstücksgrenzen, Gebäudegrenzen etc.), deren Breite
innerhalb der Bildschirmauflösung nicht klar differenziert werden kann (siehe auch
Kapitel 5.1.1.1), kann es zu Verwechslungen kommen. Auch kann die darzustellende
Anzahl von Symbolen in einer ALK so dermaßen hoch sein, dass eine Legende viel zu
komplex und unübersichtlich werden würde.
Aus diesem Grunde werden in der Legende des Auskunftssystems nur die farblichen
Unterscheidungen von ausgewählten Flurstücken präsentiert.
Für die Zukunft wäre es wichtig, in dem System auch eine automatische Druckausgabe
113

5. Diskussion und Ausblick
(in einer entsprechenden Auflösung) zu gewährleisten. Auf diese Problematik wurde
bereits in Kapitel 5.1.1.3 eingegangen.
Es wäre wünschenswert, dass nach Auswahl einer bestimmten Karte und einem
Mausklick auf einen entsprechenden Button die Kartenanwendung in einem hohen
Maßstab analog zur Verfügung steht.
Dieses müsste über ein noch zu erstellendes Skript realisiert werden, welches sämtliche
Größenangaben in Map- und Symbolfile automatisiert umrechnet und bestenfalls die
Kartengrafik in ein PDF-Dokument einbettet.
5.3 Umstellung von ALK zu ALKIS
Natürlich ist es sehr schwierig etwas zu bewerten, was umfassend noch gar nicht
exisitiert. Es gibt noch keine Konverter (zumindest keine Open Source-Konverter), welche
ALKIS-Daten in ein für den Mapserver ohne weiteres lesbares Format umwandeln.
Diverse Bundesländer sind noch mit der flächendeckenden Erhebung von ALK-Daten
beschäftigt, an ALKIS ist in diesem Sinne noch gar nicht zu denken.
Nach Durchsicht und Vergleich der ZV-Aut sowie des ALKIS-Signaturenkatalogs wird
jedoch deutlich, dass verschiedene Umsetzungsprobleme auch durch die Vorgaben des
ALKIS-Signaturenkataloges nicht gelöst werden. Auch dort gibt es Linienvorschriften
derart, dass Linien eine Breite von z.B. 0,18 mm oder 0,35 mm aufweisen sollen, was im
Mapserver in dieser Genauigkeit nicht umzusetzen ist.
Während in der ZV-Aut keine Angabe darüber vorhanden war, in welcher Form Linien
enden, so ist dieses im Signaturenkatalog (leider) explizit angegeben.
Auch werden hier genaue Angaben zu den Verbindungen an den Scheitelpunkten
deklariert (siehe Abbildung 56).
114

5. Diskussion und Ausblick
Abbildung 56: Vorgaben des ALKIS-Signaturenkatalogs zu Linienend- bzw.
Scheitelpunkten
Quelle: AdV 2005b, S.11
Im UMN Mapserver gibt es für eine Darstellung dieser Art bereits eine Lösung.
Linien können vom sogenannten Typ CARTOLINE erstellt werden.
Dieser Typ gewährleistet die Gestaltung von unterschiedlichen Linienenden und
Scheitelpunkten mittels verschiedener Parameter. 184
Dennoch wird durch diese neue Anforderung an die Darstellung von Linien eine
erhöhte Komplexitität entstehen, deren Umsetzung im Vergleich zur ZV-Aut einen noch
höheren Zeitaufwand bedeutet.
Ein weiterer zusätzlicher Aufwand entsteht dadurch, dass in ALKIS nun auch farbliche
Markierungen und Belegungen möglich sind.
Der Farbanteil wird laut Signaturenkatalog Teil A mit dem Farbgrundton und den Euro-
Skala-Farbanteilen Cyan, Magenta, Yellow und Black angegeben (siehe Abbildung 57).
184 http://www.mapmedia.de/dokumente/umn_signaturen_howto/index.html vom 28.5.2006
115

Abbildung 57: Farbangaben im ALKIS-Signaturenkatalog
Quelle: AdV 2005b, S.11
5. Diskussion und Ausblick
Das Format CYMK wird standardmäßig für Druckausgaben verwendet; der UMN
Mapserver aber verwendet für die Erstellung von Farben, wie in der Webdarstellung
üblich, Angaben im RGB-Format.
Über Umrechnungsroutinen kann eine Angabe im CMYK-Format in das RGB-Format
umgewandelt werden, auch dieses jedoch bedeutet natürlich einen zusätzlichen
Zeitaufwand.
Zur Kartenbeschriftung werden im ALKIS-Signaturenkatalog die Schriftartten „Arial“
und „Times New Roman“ vorgegeben. 185 Dieses sind keine Schriftarten, welche im
ursrpünglichen Sinne lizenzrechtlich „frei“ sind; für ein explizites Open-Source-Projekt
scheiden diese Schriftarten aus. Es müssen, wie auch schon im FreeZVAUT-Projekt,
Schriftarten verwendet werden, welche den vorgegebenen Schrifttypen ähnlich sind.
Nach Durchsicht des ALKIS-Signaturenkataloges wird deutlich, dass auch in der
Zukunft Umsetzungsprobleme bleiben werden. Die Komplexität und die Anforderungen
an die zu erstellenden Kartenelemente werden, wie oben dargestellt, steigen. Es wird
deutlich, dass auch der ALKIS-Signaturenkatalog, wie schon die ZV-Aut, Vorgaben für
Papierkartenwerke darstellt und nicht für Kartenanwendungen im Web.
Dennoch ist davon auszugehen, dass auch diesbezüglich zumindest rechtskonforme
Kartendarstellungen entwickelt werden können.
185 AdV 2005b, S. 5f.
116

6. Fazit
6. Fazit
Innerhalb dieser Diplomarbeit konnte dargestellt werden, auf welche Art und Weise
Symbole und Signaturen in FreeZVAUT annähernd ZV-Aut-konform entwickelt werden.
Es wurde deutlich gemacht, welche Möglichkeiten unter Verwendung der genannten
Systemkomponenten bestehen. Ca. 90% aller benötigten Signaturen sowie ein
umfangreiches Map- bzw. Symbolfile konnten für den UMN Mapserver erstellt werden.
Der Nutzen des FreeZVAUT-Projektes konnte auch durch die Erarbeitung eines
Flurstücksauskunftssystems präsentiert werden.
In diesem ist es unter anderem möglich, verschiedene Abfragen zu einzelnen Flurstücken
durchzuführen und sich eine Karte mit nahezu ZV-Aut-konformen Elementen anzeigen zu
lassen.
Innerhalb dieser Arbeit wurde auch gezeigt, dass durch die Umstellung von ALK zu
ALKIS verschiedene Darstellungsprobleme bleiben werden und dass die Anforderungen
an eine Erstellung von Symbolen und Objekten an Komplexität zunehmen.
Das FreeZVAUT-Projekt ist mit dieser Diplomarbeit nicht abgeschlossen (ein
endgültiger Abschluss hätte den Rahmen dieser Arbeit bei weitem gesprengt);
verschiedene Funktionen, Symbole und Signaturen sind noch zu entwickeln.
Mit Spannung darf der Blick in die Zukunft gerichtet werden. Zur Zeit ist die Anzahl
der Entwickler im Rahmen des FreeZVAUT-Projektes noch begrenzt, die Hoffnung bleibt,
dass sich dieses in der Zukunft ändern wird.
Es ist auch zu erwähnen, dass es im Rahmen der verwendeten Komponenten (noch)
Hemmnisse und Begrenzungen gibt.
Wünschenswert wäre es, wenn im Rahmen der großen Open-Source-Gemeinschaft,
eventuell unter Nutzung öffentlicher Gelder, diese Schwierigkeiten mittelfristig beseitigt
werden könnten.
Man wird sehen, was diesbezüglich die Zukunft bringt.
117

7. Literaturverzeichnis
7.1 Publikationen
Aulds, Charles (2001): “Linux Apache Web Server Administration“. Köln
7. Literaturverzeichnis
Boenigk, Claudia (2003): “PostgreSQL - Grundlagen, Praxis, Anwendungsentwicklung mit
PHP“. Heidelberg
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005a): "Dokumentation zur Modellierung der Geoinformationen
des amtlichen Vermessungswesens (GeoInfoDok). ALKIS-Objektartenkatalog“. Version 5.0.
Bonn
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005b): "Dokumentation zur Modellierung der Geoinformationen
des amtlichen Vermessungswesens (GeoInfoDok). ALKIS-Signaturenkatalog, Teil A:
Vorbemerkungen“. Version 4.0. Bonn
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005c): "Dokumentation zur Modellierung der Geoinformationen
des amtlichen Vermessungswesens (GeoInfoDok). ALKIS-Signaturenkatalog, Teil B:
Signaturenbibliothek“. Version 4.0. Bonn
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005d): "Dokumentation zur Modellierung der Geoinformationen
des amtlichen Vermessungswesens (GeoInfoDok). ALKIS-Signaturenkatalog, Teil C:
Präsentation“. Version 4.0. Bonn
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005e): "Erläuterungen zu ALKIS". Bearbeiter: Günther Rothberger
und Markus Seifert. Bonn
Arbeitsgemeiscnhaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland (AdV) (2005f): "Erläuterungen zu ALKIS". Version 4.0. Bonn
Autorenteam von Sun Microssystems (2002): "Website-Administration & Grundlagen
Apache". Berlin
Booch, Grady; Rumbaugh, James; Jacobson, Ivar (2005): "Das UML Benutzerhandbuch".
München
Behncke, Kai (2005): “Installation des UMN-Mapservers auf Windows & erste Schritte
anhand eines Beispiels“. Vechta
118

Bowen, Rich; Coar, Ken (2000): “Apache und CGI“. München
7. Literaturverzeichnis
CCGIS und terrestris (2004): "Praxishandbuch WebGIS mit Freier Software". Bonn
Christl, Arnulf; Trakas, Athina (2004): "Open Source und Freie Software - Argumente
jenseits der Kostendiskussion", in: Strobl, Josef (Hrsg.): Angewandte Geoinformatik 2004;
S.73-78. Heidelberg
Derksen, Gerhard; Peick, Manfred; Ulbricht, Volkmar (2001) "Die Automatisierte
Liegenschaftskarte (ALK) des Landkreises Barnim", in: Vermessung Brandenburg; 1/01,
S.31-41. Potsdam
Dickmann, Frank (2001): "Webmapping und Web-Gis". Braunschweig
Feller, Joseph; Fitzgerald, Brian (2002): "Understanding Open Source Software
Development". London
Fischer, Thorsten (2003): "UMN Mapserver 4.0". Berlin
Fürpaß, Christian (2001): "Mapserver als Hilfsmittel zur Datenvisualisierung im Internet-
Erläutert anhand des Internetprojektes AtOS". Diplomarbeit an der Fakultät für Human-
und Sozialwissenschaften zur Erlangung des Magistergrades für Naturwissenschaften.
Wien
Geschwinde, Ewald; Schönig, Hans-Jürgen (2002): “Datenbankanwendungen mit
PostgreSQL“. München
Glinsky, Peter; Gehrke, Frank; Klappheck, Günther (2000): “Linux Power“. Düsseldorf
Grassmuck, Volker (2002): “Freie Software zwischen Privat- und Gemeineigentum“. Bonn
Hahne, Felix (2003): “Interaktive Websites“. Poing
Innenministerium des Landes Nordrhein-Westfalen (2003) "Vorschriften für die
Verschlüsselung der Grundrissobjekte des Liegenschaftskatasters in Nordrhein-Westfalen
Objektschlüsselkatalog Liegenschaftskataster NRW". RdERl. d. Innenministeriums vom
12.8.2003
Innenministerium des Landes Nordrhein-Westfalen (2005): "Vorschriften für das
automatisierte Zeichnen der Liegenschaftskarte in Nordrhein-Westfalen.
Zeichenvorschrift-Aut-NRW (ZV-AUT)". RdErl. d. Innenministerium v. 19.3.2004
Kofler, Michael (2005): "Linux: Installation, Konfiguration, Anwendung". München
119

7. Literaturverzeichnis
Kraak, Menno-Jan; Ormeling, Ferjan: (1996) "Cartography - Visualation of spatial data".
Harlow
Landesvermessung und Geobasisinformation Niedersachsen (LGN), AG Hannover im
Vorhaben ALK/ALKIS (1987): "ALK-Datenbankteil". Hannover
Lindenbeck, Christof; Schulz, Michael (2004): "UMN-MapServer-Integration in den Web-
Applikationsserver ZOPE", in: Strobl, Josef (Hrsg.): Angewandt Geoinformatik 2004; S.423-
432. Heidelberg
Möller, Erik (2005): “Die heimliche Medienrevolution. Wie Weblogs, Wikis und freie
Software die Welt verändern“. Hannover
Müller, Martin; Snoopy (1999): “Open Source kurz und gut“. Köln
Novel Inc. (2005): “Suse Linux professional 9.3“. München
Olbrich, Gerold; Quick, Michael; Schweikart, Jürgen (2002): "Desktop Mapping". Berlin,
Heidelberg
Oesterreich, Bernd (1999): "Objektorientierte Softwareentwicklung: Analyse und Design
mit der Unified modeling language". München, Wien, Oldenburg
Oswald, Manfred; Rothberger, Günther (1998): "ALKIS - Amtliches
Liegenschaftskatasterinformationssystem", in: Vermessung Brandenburg; 1/98, S.11-19.
Potsdam
Peyton, Christine; Möller, Andre (2004): “PHP 5 & Mysql 4“. München
Pohlmann, Eckart; Ridder, Ingbert (1995): "Die ALK als Arbeitsgrundlage innerhalb und
außerhalb der Verwaltung", in: Vermessungswesen und Raumordnung; 57, 8/05, S.251-
259. Bonn
Projektgruppe Studienprojekt Wesermarsch (2005): “Endbericht: Tourismus-
Informationssystem“. Hochschule Vechta, Institut für Umweltwissenschaften,
Studienprojekt. Vechta
Reiter, Bernhard (2004): "Wandel der IT: Mehr als 20 Jahre Freie Software", in:
Sauerburger, Heinz (Hrsg.): Open-Source-Software; S.83-91. Heidelberg
Riecken, Jens (2000): "Der bundesweite Projektstand ALKIS und der Projektstand von
GEOBASIS NRW", in: Nachrichten aus dem öffentlichen Vermessungsdienst Nordrhein-
Westfalen; 33, 2/2000, S.78-85. Düsseldorf
120

Rotter, Robert (2002): "JavaScript". Poing
Roßbach, Steffen (1999): "Der Apache Webserver". München
7. Literaturverzeichnis
Schönbuchner, Ruth; Unterpaintner, Johanna (2005): “WebGis Anwendung für den
Nationalpark Berchtesgarden“. Diplomarbeit an der Fachhochschule Weihenstephan,
Fachbereich Landschaftsarchitektur. Weihenstephan
Schüngel, Jan (2004): "Management von Web-Mapping Anwendungen in GIS-
Applikationen". Diplomarbeit an der Fachhochschule Oldenburg, Fachbereich
Geoinformatik. Oldenburg
Schüttel, Marcel (2003): "ALB und ALK - Fit für ALKIS?" in: Zeitschrift für Geodäsie,
Geoinformation und Landmanagement; 3/2003, S.185-191. Augsburg
Seifert, Markus (2000): "Der Standard ALKIS - der Schritt zum GIS" in: Nachrichten aus
dem öffentlichen Vermessungsdienst Nordrhein-Westfalen; 33, 1/2000, S.13-22. Bonn-
Bad-Godesberg
Seifert, Markus (2004): "Der Standard ALKIS - Was bringt er?", in: Vermessung
Brandenburg; 2/04, S. 25-33. Potsdam
Seifert, Markus; Grote, Thomas (2001): "ALKIS - Eine Konzeption für Anwender und
Nutzer", in: Flächenmanagement und Bodenordnung. Zeitschrift für Liegenschaftswesen,
Planung und Vermessung; S.238-248. Wiesbaden
Stöppler, Hans Werner (1987): "Die automatisierte Liegenschaftskarte", in: Nachrichten
aus dem öffentlichen Vermessungsdienst Nordrhein-Westfalen; 20, 1/2000, S.64-88,
Bonn-Bad Godesberg
Suse Linux GmbH (2005): "Suse Linux professionell 9.3 - Administrationshandbuch".
Ohne Ortsangabe
Verso (2003): „We are everywhere“. New York, London
Vermessungs- und Katasterverwaltung Rheinland-Pfalz (2005): "AAA-Newsletter
Nr.3". Koblenz
Wilhelmy, Herbert (2002): "Kartographie in Stichworten". Berlin, Stuttgart
Wichmann, Thorsten (2005): “Linux- und Open Source Strategien“. Berlin, Heidelberg
Williams, Sam (2002): "Free as in Freedom. Richards Stallman`s crusade for free
software". Beijing
121

7.2 Internetquellen
Homepage des Apache Webservers
http://www.apache.org vom 23.5.2006
http://www.apache.org/licenses vom 24.5.2006
ALK Lexikon
http://www.igip.de/ALK-Lexikon/index-alk-lexikon.html vom 22.5.2006
7. Literaturverzeichnis
Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik
Deutschland
http://www.adv-online.de/extdeu/broker.jsp?uMen=ea510328-46de-1afa-6d78-
79f08a07b51a vom 17.5.2006
http://www.adv-online.de/extdeu/broker.jsp?uMen=ea7769da-d319-fa6d-7879f08a07b51a69
vom 1.6.2006
Blau direkt – Europas erster Internetpool
https://www.maklerinfo.biz/homepage-Dateien/include-Dateien/Wikipedia_Schnittstelle.php?Suchbegriff=EDBS
vom 20.5.2006
Behörden für Geoinformation Landentwicklung und Liegenschaften
http://www.gll.niedersachsen.de/master/C10540068_N8679277_L20_D0_I7746208.html
vom 18.5.2006
Das GIS-Tutorial
http://www.gis-tutor.de/theorie/daten/basisdat/basisdat.html vom 21.5.2006
Edbsilon-Homepage
http://edbsilon.intevation.org vom 24.5.2006
ESRI-Deutschland
http://www.esri-germany.de/products/arcims/index.html vom 20.5.2006
Fontforge-Homepage
http://fontforge.sourceforge.net vom 22.5.2006
http://fontforge.sourceforge.net/fontinfo.html#PS-General vom 5.6.2006
Free Software Foundation
http://www.fsf.org/licensing/essays/free-sw.html vom 24.4.2006
122

FreeZVAUT-Projektseite und Mailingliste
http://wald.intevation.org/projects/freezvaut vom 2.6.2006
7. Literaturverzeichnis
http://lists.wald.intevation.org/pipermail/freezvaut-devel/2005-December/000025.html
vom 1.6.2006
http://lists.wald.intevation.org/pipermail/freezvaut-devel/2006-January/000030.html vom
1.6.2006
http://lists.wald.intevation.org/pipermail/freezvaut-devel/2006-January/000030.html vom
24.5.2006
Geoinformatik Lexikon
http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=62 vom 18.5.2006
Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen
http://www.gwdg.de/forschung/publikationen/gwdg-nr/GN0311/gn0311_04.html vom
20.5.2006
GIS-Management Homepage
http://www.gismngt.de/update/alk.htm vom 23.5.2006
HHK Datentechnik
http://www.hhk.de/produkte/gw/ALKIS.html vom 3.6.2006
Landesvermessungsamt Nordrhein-Westfalen
http://www.lverma.nrw.de/produkte/liegenschaftsinformation/katasterinfo/alk/ALK.htm#
vom 17.5.2006
http://www.lverma.nrw.de/produkte/druckschriften/verwaltungsvorschriften/images/zvaut
/TCAUT_NRW.zip vom 28.5.2006
http://www.lverma-mv.de/lie_alk.htm vom 20.5.2006
Landesvermessungsamt Sachsen
http://www.lvsn.smi.sachsen.de/produkte/liegen/alk/inhalt_re_alk.html vom 1.6.2006
Landesregierung Schleswig-Holstein
http://landesregierung.schleswigholstein.de/coremedia/generator/Aktueller_20Bestand/M
/z__Katasteraemter/Information/Produkte/ALKIS.html vom 3.6.2006
Mapbender Projekt auf der Sourceforge-Homepage
http://sourceforge.net/project/showfiles.php?group_id=88554 vom 18.5.2006
123

7. Literaturverzeichnis
http://sourceforge.net/project/showfiles.php?group_id=88554&package_id=110215 vom
18.5.2006
Mapmedia Homepage
http://www.mapmedia.de/dokumente/umn_signaturen_howto/index.html vom 28.5.2006
Mapserver Homepage
http://mapserver.gis.umn.edu/download/current vom 23.5.2006
http://mapserver.gis.umn.edu/docs/howto/ogr_howto/#what-data-formats-are-supported
vom 18.5.2006
http://mapserver.gis.umn.edu/docs/howto/raster_data/#supported-formats vom
19.5.2006
Open Source Initiative
http://www.opensource.org/advocacy/faq.php vom 24.5.2006
http://www.opensource.org/docs/definition.php vom 22.5.2006
Open Source Geospatial Foundation
http://mapserverfoundation.org/open_letter_de.pdf vom 12.11.2005
UMN Mapserver Community
http://www.umn-mapserver-community.de vom 23.5.2006
UMN Mapserver Homepage und Mailingliste
http://www.umn-mapserver.de vom 23.5.2006
http://intevation.de/pipermail/mapserver-de/2006-January/001946.html vom 24.1.2006
Vermessungs- und Katasterverwaltung Rheinland-Pfalz
http://www.lvermgeo.rlp.de/lv/aufgaben/ALKIS.html vom 5.6.2006
Version Control with Subversion
http://svnbook.red-bean.com/nightly/en/svn-book.html vom 22.5.2006
Wikipedia - die freie Enzyklopädie
http://de.wikipedia.org/wiki/Open-Source vom 25.5.2006
http://de.wikipedia.org/wiki/Propriet%C3%A4re_Software vom 27.5.2006
http://de.wikipedia.org/wiki/Suse_Linux vom 29.5.2006
124

http://de.wikipedia.org/wiki/Apache_HTTP_Server vom 27.5.2006
Wiki Unixboard
http://wiki.unixboard.de/index.php/Freie_Software vom 20.5.2006
7. Literaturverzeichnis
125

8. Anhang
8. Anhang
126

Abkürzungsverzeichnis
AdV: Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder
ALB: Automatisiertes Liegenschaftsbuch
ALK: Automatisierte Liegenschaftskarte
ALKIS: Amtliches Liegenschaftskataster-Informationssystem
ATKIS: Amtlich Topographisch-Kartographisches Informationssystem
EDBS: Einheitliche Datenbankschnittstelle
FAQ: Frequently asked questions
FSF: Free Software Foundation
ISO: International Standardization Organisation
GIAP: Grafisch interaktiver Arbeitsplatz
GNU: Gnu is not Unix
GPL: General Public License
LG: Landesvermessung und Geobasisinformation
LPGL: Lesser General Public License
NAS: Normierte Austauschschnittstelle
NREO: Nicht raumbezogene Elementarobjekte
OBAK: Objektabbildungskatalog
OGC: Open Geospatial Consortium
OS: Objektschlüssel
OSI: Open Source Initiative
OSKA: Objektschlüsselkatalog
PHP: PHP: Hypertext Preprocessor
REO: Raumbezogene Elementarobjekte
SVN: Subversion
UMN: University of Minnesota
UML: Unified modeling language
WFS: Web Feature Service
8. Anhang
127

WMS: Web Mapping Service
ZUSO: Zusammengesetzte Objekte
ZV-Aut: Zeichenvorschrift Automatisierung
8. Anhang
128

Abbildungsverzeichnis
8. Anhang
Abbildung 1: Ausschnitt aus der Automatisierten Liegenschaftskarte 7
Abbildung 2: Systemkonzeption der ALK 8
Abbildung 3: ALK-Objektmodell 11
Abbildung 4: U-Bahnhof-Symbol aus der ZV-Aut 13
Abbildung 5: Auszug aus der ZV-Aut 14
Abbildung 6: ALK-Verwendungsbereiche 15
Abbildung 7: ALKIS-Datenmodell 19
Abbildung 8: Beschreibung der Objektartengruppe Vegetation im ALKIS-
Objektartenkatalog 20
Abbildung 9: Beispiel aus dem ALKIS-Signaturenkatalog (Teil B) 23
Abbildung 10: Beispiel für Darstellungsvorschrift im ALKIS-
Signaturenkatalog (Teil C) 24
Abbildung 11: Gesamtbetriebskostenvergleich im Laufe der Zeit.
Vergleich zwischen Freier Software/Open Source und proprietärer Software 36
Abbildung 12: Vergleich zwischen Freier Software/OS und proprietärer Software 37
Abbildung 13: Serverarchitektur des ArcIMS 40
Abbildung 14: FreeZVAUT-Projektseite 44
Abbildung 15: Gestaltungsvariablen von Punkt-, Linien- und Flächenelementen 48
Abbildung 16: Mapserverarchitektur 53
Abbildung 17: Zusammenspiel der technischen Dateien im UMN Mapserver 57
Abbildung 18: Logo des Apache Webservers 58
Abbildung 19: Systemkomponenten im Rahmen des FreeZVAUT-Projektes 61
Abbildung 20: UML-Klassendiagramm der verwendeten Testdaten der LG
Brandenburg 65
Abbildung 21: Beispiel für ein UML-Objekt 65
Abbildung 22: Auszug aus der Folie 082 (Ergänzungstopographie) der ZV-Aut 67
Abbildung 23: em-square in Fontforge 69
Abbildung 24: Symbol „Laufkran“ in FontForge erstellt 70
Abbildung 25: Symbole aus dem TrueType-Font „zvaut-folie082.ttf“ 71
129

8. Anhang
Abbildung 26: Symbol „Laufkran“ (OS 3923 aus Folie 082) im UMN Mapserver 73
Abbildung 27: Darstellungsvorschriften für Flurstücksnummern aus der ZV-Aut 74
Abbildung 28: Datenstruktur für die Darstellung von Flurstücksnummern
in phpPgAdmin 77
Abbildung 29: Darstellung der Flurstücksnummern im UMN Mapserver 77
Abbildung 30: ZV-Aut-Vorschriften für Begleitzeichen der Folie 001 78
Abbildung 31: Linienbegleitsignatur von OS 0232 „Flurgrenze“ in Fontforge 79
Abbildung 32: Flurgrenzenbegleitsignatur im UMN Mapserver 80
Abbildung 33: Darstellungsvorschrift für den Aufnahmepunkt (OS 0122,
Folie 051) der ZV-Aut 81
Abbildung 34: Umriss des Aufnahmepunktes (OS 0122, Folie 051) in Fontforge 82
Abbildung 35: Hintergrundkreis des Aufnahmepunktes (OS 0122, Folie 051)
in Fontforge 82
Abbildung 36: Zahl mit automatisch integriertem Unterstrich in Fontforge 83
Abbildung 37: Datenmodell für die Darstellung von
Aufnahmepunkten (Folie 051) 84
Abbildung 38: Vorgaben für Flächensignaturen aus der ZV-Aut 85
Abbildung 39: Flurstücke überlappende Flächensignaturen im UMN Mapserver 85
Abbildung 40:„Einzelsymbol“ für Streuobstwiese (OS 6220, Folie 021) in Fontforge
Abbildung 41: Datenstruktur zur Darstellung der tatsächlichen
Nutzung (Folie 021) 88
Abbildung 42: ZV-Aut-konforme Darstellung von Flächensignaturen
im UMN Mapserver 89
Abbildung 43: Oberfläche des Flurstücksauskunftssystems 90
Abbildung 44: Auszug aus der Flurstückstabelle „f001_f“ 92
Abbildung 45: Verschiedene Layer deaktivert 93
Abbildung 46: Flurstück ausgewählt nach seiner Nummer 95
Abbildung 47: Navigationsleiste in dem Flurstücksauskunftssystem 98
Abbildung 48: Nach Attributen ausgewählte Flurstücke 99
Abbildung 49: Datenanzeige zu einem einzelnen Flurstück 101
Abbildung 50: Linienbegleitende Signatur mit Orientierung am Kartenbild 105
86
130

8. Anhang
Abbildung 51: Linienbegleitende Signatur mit Orientierung an der Linie 106
Abbildung 52: Überlappende Darstellung von Flurstücksnummern 108
Abbildung 53 Doppelte Begleitsignatur an Polygongrenzen 110
Abbildung 54: Begleitsignaturen der ZV-Aut (Folie 082) 111
Abbildung 55: Nicht-ZV-Aut-konforme Darstellung von OS 0353 der Folie 082 111
Abbildung 56: Vorgaben des ALKIS-Signaturenkatalogs zu Linienend- bzw.
Scheitelpunkten 115
Abbildung 57: Farbangaben im ALKIS-Signaturenkatalog 116
131