entwurf und implementierung eines ... - idb.uni-bonn.de · rheinische...

Rheinische Friedrich-Wilhelms-Universität Bonn

Institut für Informatik III

Diplomarbeit

Entwurf und Implementierung eines generischen

2D-Kartengenerators basierend auf relationalen

Geodatenbanken

Ahmet Devrim

13. September 2005

Erstgutachter: Prof. Dr. Rainer Manthey

Danksagung

Ich möchte an dieser Stelle die Gelegenheit nutzen, mich bei den Menschen zu bedan-ken, von denen ich glaube, dass sie einen entscheidenden Beitrag zu dieser Diplomarbeitgeleistet haben, indem sie mich während meiner gesamten schulischen und akademischenLaufbahn in unterschiedlicher Form unterstützt haben.

• Ein ganz besonderer Dank gilt Herrn Prof. Dr. Manthey für seine einzigartige undintensive Betreuung über die gesamte Diplomarbeitsphase. Insbesondere haben un-zählige fachliche Diskussionen mit ihm zu einer fortwährend positiven Entwicklungder Arbeit beigetragen.

• Ein besonderer Dank gebührt meiner Frau Fatma Poyraz-Devrim ebenfalls, die mirwährend meines Studiums liebevoll zur Seite gestanden hat und ohne die ich meineZiele niemals erreicht hätte. Fatma - mein Schatz ich liebe Dich!

• Bedanken möchte ich mich auch bei meinen Gymnasial-Lehrern Herrn MichaelMannheims und Herrn Karheinz Damerow, die mehr Freund als Lehrer waren, fürihr persönliches Engagement während meiner Zeit auf dem Humboldt-Gymnasiumin Köln.

• Auch bei meiner Grundschullehrerin Frau Eva Kortmann möchte ich mich rechtherzlich bedanken, die meinen Start in das Schulleben hätte nicht angenehmer undfördernder gestalten können.

• Zu guter letzt möchte ich mich bei meiner Familie - Mehmet Devrim mein Vater,Fikriye Devrim meine Mutter und Gülüzar Devrim meine Schwester - bedanken, diemir all dies ermöglicht haben, indem sie mich so viele Jahre in vielen Dingen auchneben Schule und Studium unterstützt und motiviert haben.

Vielen lieben Dank!Ahmet Devrim

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen aus der Geographie 32.1 Kartographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Karten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Geoinformationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Geoobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Geodaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Grundlagen aus der Informatik 203.1 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.2 Entity-Relationship-Modell . . . . . . . . . . . . . . . . . . . . . . . 213.1.3 Relationales Datenmodell . . . . . . . . . . . . . . . . . . . . . . . 223.1.4 Relationale Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.5 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 GDI+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Entwurf - Methodologie - Konzept 364.1 Generische Visualisierung von 2D-Geoobjekten . . . . . . . . . . . . . . . . 36

4.1.1 Beispiel - Touristik/Umwelt . . . . . . . . . . . . . . . . . . . . . . 384.2 Visualisierung in MapGENeric . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.1 Darstellung von Geoobjekten . . . . . . . . . . . . . . . . . . . . . 444.2.2 Bildschirmkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Visualisierungs-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.1 Bestandteile des Visualisierungs-Mappings . . . . . . . . . . . . . . 514.3.2 Dynamisierung des Visualisierungs-Mappings . . . . . . . . . . . . . 53

4.4 Regelbasierter Ansatz für dasVisualisierungs-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4.1 Grundkonzepte der Regelsprache . . . . . . . . . . . . . . . . . . . 58

i

ii Inhaltsverzeichnis

5 Syntax und Semantik derRegelsprache VRL 655.1 VM-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 Kon�gurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 Darstellungsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3.1 PunktDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.2 LinieDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.3.3 FlaecheDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Geoobjektklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 Punktförmige Geoobjekte . . . . . . . . . . . . . . . . . . . . . . . 705.4.2 Flächenförmige Geoobjekte . . . . . . . . . . . . . . . . . . . . . . 73

6 Architektur und Funktionalität von MapGENeric 776.1 MapGENeric-Architektur im Kontext . . . . . . . . . . . . . . . . . . . . . 776.2 Autoren-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.1 Geodatenbank wählen . . . . . . . . . . . . . . . . . . . . . . . . . 796.2.2 Geoobjektklassen erstellen/bearbeiten . . . . . . . . . . . . . . . . 816.2.3 Darstellungsformen erstellen/bearbeiten . . . . . . . . . . . . . . . 856.2.4 Visualisierungs-Regeln erstellen/bearbeiten . . . . . . . . . . . . . . 876.2.5 Kon�gurationen erstellen/bearbeiten . . . . . . . . . . . . . . . . . 88

6.3 Nutzer-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.3.2 Inforetrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.3.4 Zooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.3.5 Layermanipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7 Implementierung 1007.1 Map Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.1.1 Con�guration und Geoobject Loader . . . . . . . . . . . . . . . . . 1017.1.2 Projection Transformer . . . . . . . . . . . . . . . . . . . . . . . . . 1037.1.3 Layer Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

7.2 Module des Layer Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.2.1 Generierung der Zeichen�äche - Layer . . . . . . . . . . . . . . . . . 1067.2.2 World To Screen - Koordinatentransformation . . . . . . . . . . . . 1077.2.3 Zeichnen der Repräsentations-Objekte . . . . . . . . . . . . . . . . 111

8 Zusammenfassung und Ausblick 1168.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A VRL 121A.1 Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Inhaltsverzeichnis iii

B DB-Schnittstelle 126B.1 clsConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.2 clsLayerDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.3 clsMapObjectsDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.4 clsViewshapeDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127B.5 clsAttributesDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Kapitel 1

Einleitung

Auf Karten werden menschlicheWahrnehmungs- und Kognitionsfähigkeiten genutzt, groÿeInformationsmengen und komplexe Zusammenhänge visuell in graphischer Form schnellaufnehmen zu können. Mit dem Inhalt und der Darstellung von Karten beschäftigt sich dieKartographie unter Berücksichtigung von Anwendung und Nutzerkreis der zu erstellendenKarte. Um eine Karte für eine spezielle Anwendung und einen bestimmten Nutzerkreiserstellen zu können, muss ein Kartenautor redaktionelle Arbeit leisten. Dies ist Notwen-dig, da die Verständlichkeit einer Karte unter anderem vom gegebenen Umfeld und demVorwissen des Nutzers abhängt. Herkömmliche Karten stellen Datenspeicher und visuel-le Darstellung in nur einem Medium dar. Von der Güte der redaktionellen Arbeit undden Erfahrungen des Kartenautors, beim Entwurf von Karten diesen begrenzten Spei-cher optimal auszunutzen und geeignete Techniken für Darstellungen einzusetzen, wirddie Qualität einer Karte in hohem Maÿe beein�usst.

Im digitalen Zeitalter von gra�kfähigen Computern mit immer mehr Speicherkapazitätkönnen immer öfter moderne Formen der herkömmlichen Karte angetro�en werden, diemehr Informationen bieten als gedruckte Karten. Diese so genannten Bildschirmkarten, diehauptsächlich im Rahmen von Navigationssystemen oder Internet-Informationssystemenvorzu�nden sind, basieren auf Daten, die durch Messungen von Objekten auf der Erdober-�äche gewonnen wurden. Auf solchen Geodaten basieren auch Geoinformationssysteme(GIS), die wesentlich komplexer aufgebaut sind als Navigationssysteme oder Internet-Informationssysteme und Vorteile von Datenbanksystemen nutzen, um diese raumbezo-genen Daten digital erfassen, reorganisieren, analysieren und graphisch präsentieren zukönnen. Da Bildschirmkarten im Vergleich zu herkömmlichen Karten auf Papier wesent-lich weniger Platz und Detailmöglichkeiten bieten, können sie die Darstellung von mehrInformationen lediglich durch eine interaktive Schnittstelle zum Nutzer erreichen. Zurgraphischen Präsentation dieser Daten in Form von Bildschirmkarten werden unter an-derem in den oben genannten Programmen (Navigationssysteme, Internet-IS, GIS, usw.)kartengenerierende Softwarekomponenten (Kartengeneratoren) benötigt. Diese Kartenge-neratoren werden bisher anwendungs- und nutzerkreisbezogen entwickelt und basieren aufanwendungsbezogen modellierten Geodaten. Ferner ist bis dato für die Entwicklung einessolchen Kartengenerators die Zusammenarbeit von Softwareentwicklern und Kartenauto-ren unerlässlich, um die Qualität der Karte zu gewährleisten. Ergibt sich im nachhinein,dass die Darstellung von Geoobjekten anders erfolgen soll oder dass sich die Struktur der

1

2 Kapitel 1. Einleitung

Geodaten geändert hat, so muss die Software durch den Entwickler diesen Gegebenheitenangepasst werden. Wünschenswert ist stattdessen ein generischer Kartengenerator, derunabhängig von Daten und Darstellung arbeitet, so dass eine Trennung von Daten, Logikund Design erreicht wird.

Nach der Identi�zierung der vom Kartengenerator darzustellenden Geoobjektartenanhand eines Beispiels, sollen in dieser Arbeit notwendige Eigenschaften für die Darstel-lung dieser Geoobjektarten ermittelt werden. Ferner sollen Bildschirmkarten im Hinblickauf Funktion, Layout und Interaktion diskutiert werden, um dabei feststellen zu können,welche dieser Eigenschaften in das zu entwickelnde System integriert werden sollen. Essollen ebenfalls statische Komponenten identi�ziert werden, die für die Entwicklung einesgenerischen Kartengenerators dynamisiert werden müssen. Zusammenfassend kann dasZiel dieser Arbeit beschrieben werden, als die Entwicklung und Implementierung einesgenerischen 2D-Kartengenerators, der alphanumerische Geodaten aus einer relationalenGeodatenbank in geographische Bildschirmkarten transformiert. Dabei ist das Systemmöglichst unabhängig von einem bestimmten Datenbanksystem zu entwickeln. Exempla-risch wird eine Schnittstelle für Microsoft Access implementiert werden. Eine graphischeNutzer-Schnittstelle sollte zur Demonstration der Leistungsfähigkeit ebenfalls implemen-tiert werden, die Interaktionen und Darstellungsmöglichkeiten moderner Bildschirmkartenunterstützt. Ferner wäre ein Kon�gurationsassistent wünschenswert, der die komfortableEingabe von Regeln für die Kon�guration des Kartengenerators erlaubt.

In Kapitel 2 sind Grundlagen zum Kontext der Arbeit erörtert. Nach einem histori-schen Überblick über Kartographie wird eine Einführung in deren Grundlagen gegeben,um ein Gefühl für das Produkt �Karte� zu bekommen, das durch das zu entwickelndeSystem erzeugt werden soll. Ein weiterer Teil des Kapitels widmet sich den Geoinforma-tionssystemen. Über ihre Modellierung und Visualisierung sollen Grundlagen vermitteltwerden, die im weiteren Verlauf der Arbeit zur Identi�zierung von Basisstrukturen die-nen. Grundlagen für die Entwicklung des Systems werden in Kapitel 3 gegeben. Hierwerden Datenbanken und die Programmierumgebung .NET vorgestellt. Dadurch sollenTechniken vermittelt werden, die für die Modellierung und Implementierung des Systemsnotwendig sind. Die Identi�zierung der darzustellenden Geoobjekte erfolgt in Kapitel 4mit Hilfe eines Beispiels, das verschiedene Anwendungen und Nutzerkreise umfasst. NachDiskussionen über die Darstellung der Geoobjekte, das Layout und die Interaktionsmög-lichkeiten der Bildschirmkarte, die durch das zu entwerfende System generiert werden soll,widmet sich das Kapitel den Komponenten eines Kartengenerators und deren Dynami-sierung. Dabei steht das Konzept einer Regelsprache für Visualisierungskonventionen imVordergrund. Im Verlauf des gesamten Kapitels kristallisiert sich dabei die Modellierungdes zu entwickelnden Systems heraus. Kapitel 5 dient zur De�nition der Regelsprache, diewiederum zur Kon�guration des Systems dient. Die Struktur und Funktionalität, des inKapitel 4 modellierten Systems, wird in Kapitel 6 dargestellt. Dabei wird detailliert aufden Kartengenerator, die Nutzer-Schnittstelle und den Kon�gurationsassistenten einge-gangen. Kapitel 7 erläutert die implementierte Architektur des Systems und geht dabeiauf spezielle Teilprobleme der Entwicklung detaillierter ein. Nach einer Zusammenfassungder Arbeit gibt Kapitel 8 einen Ausblick auf die mögliche Weiterentwicklungen.

Kapitel 2

Grundlagen aus der Geographie

2.1 Kartographie

�Ein Fachgebiet, dass sich beschäftigt mit dem Sammeln, Verarbeiten, Spei-chern und Auswerten raumbezogener Informationen sowie in besonderer Weisemit der Veranschaulichung durch kartographische Darstellungen.� [HG94]

Geographische Karten, um deren automatische und regelbasierte Generierung es indieser Diplomarbeit vorrangig geht, dienen der Visualisierung von Informationen übergeographische Gegebenheiten der Erde. Sie helfen Menschen bei der Orientierung, Pla-nung und Darstellung von Sachverhalten, je nach Maÿstab und Informationsgehalt bzw.Informationsart.

2.1.1 Historie

Seit Menschengedenken verspürten Menschen den Drang, ihre Umgebung kartographischzu erfassen, um Entdecktes weitergeben zu können und um es ggf. wieder zu �nden. Kar-ten machten auf Gebirge aufmerksam, die evtl. unüberquerbar waren, sie zeigten auf, wodie letzte Jagd erfolgreich verlaufen war und wo das Meer beginnt oder nach damaligerAnsicht die Welt aufhört. Die Kartographie, wie man sie aktuell kennt und nutzt, istnach Bollmann [Bol05] in mehreren Tausend Jahren neuer Erkenntnisse entstanden. Mankann sie unterteilen in zwei Phasen der Nutzung und Entwicklung. Phase A deckt dieZeit 100.000 bis 2.000 Jahre v. Chr. und Phase B die Jahre seit 2.000 v. Chr. bis heute ab.

Vermutungen zu Folge begann die Entwicklung der Kartographie mit Markierungs-zeichen in der Altsteinzeit (vor 100.000 bis 40.000 Jahren). Mit Steinen, Hölzern undähnlichen anderen Hilfsmitteln wurden zur Orientierung im Gelände Wege markiert. Spä-ter zur Mitte der Altsteinzeit hin wurden Geländemodelle erstellt, die zur Vororientierungdienten. Gegen Ende der Altsteinzeit (vor 20.000 bis 10.000 Jahren) entwickelten sich erstegraphisch-stationäre Karten an Felswänden. Sie bildeten das Gelände erstmals mit graphi-schen Zeichen ab. Graphisch-transportable Karten kennt die Menschheit seit ca. 10.000Jahren.

3

4 Kapitel 2. Grundlagen aus der Geographie

Die älteste Karte in der uns bekannten Form der Landkarte bzw. Umgebungskarteist in Anatolien gefunden worden und stellt eine graphisch-stationäre Karte dar [MB89].Diese ca. 250 cm groÿe Karte (Abbildung 2.1) bildet die Stadt Çatal Höyük in der jetzigenTürkei ab und wird datiert auf ca. 6.200 v. Chr.

Abbildung 2.1: Çatal Höyük - original oben, nachgezeichnet unten

Mit der Zeit wurden graphisch-transportable Karten der Ägypter auf Papyrus (Nubi-sche Goldminenkarte ca. 1.300 v. Chr. Abbildung 2.2) und der Assyrer und Babylonierauf Tontafeln gefunden, die auf ca. 600 v. Chr. datiert werden. Die wohl älteste Weltkarteaus dieser Zeit ist die babylonische Weltkarte (Abbildung 2.3).

Die Entwicklung der Kartographie schritt voran durch die alten Griechen, die Kartenzur Dokumentierung der ihnen bekannten Welt anlegten und sich geographischer Problemeannahmen. Hekataios beispielsweise schuf eine Weltkarte mit drei Kontinenten ca. 450 v.Chr., die seine Heimatstadt (Milet - Kleinasien) im Mittelpunkt darstellt. Hundert Jahrespäter stellte Aristoteles (384* - 322† v. Chr.) die These auf, dass die Erde eine Kugel-form besitzen würde. Ca. 100 Jahre später bewies Eratosthenes (276* - 202† v. Chr.) dieseThese und zeichnete eine Karte mit Hilfe eines Koordinatennetzes von Parallelkreisen undMeridianen, (Abbildung 2.4) auf der sogar Irland auf der einen Seite und Indien auf deranderen Seite verzeichnet waren. Auch seine Berechnung zum Erdumfang mit 39816 km

2.1 Kartographie 5

Abbildung 2.2: �Nubische Goldminenkarte�auf Papyrus

Abbildung 2.3: BabylonischeWeltkarte auf Tontafel

war ein wichtiger Schritt in der kartographischen Darstellung. In dieser Zeit entwickelteArchimedes (287* - 212† v. Chr.) die Zylinderprojektion [Str02]. Von da an befassen sichgriechische Wissenschaftler und Philosophen mit Erdumfangsberechnungen, Höhenmes-sungen und Projektion. Die wohl erste komplexere Karte mit einem Koordinatensystemstammt ursprünglich von dem griechischen Geographen, Astronomen und MathematikerClaudius Ptolemäus (150 n. Chr.) (Abbildung 2.5). Zeichnungen von Karten dieser Epo-che haben den Untergang der jeweiligen Weltmacht nicht überlebt und wurden später mitHilfe detaillierter schriftlicher Aufzeichnungen nachgezeichnet. Ptolemäus' Karten weisenEin�üsse der römischer Kartographen auf, die eher praktische als wissenschaftliche Kartenzeichneten. Straÿennetze, Wegekarten, Küstenverläufe, Grundstückskarten und Weltkar-ten zeichneten die Römer zu jener Zeit (ca. 250 n. Chr.) anhand von Vermessungsergeb-

Abbildung 2.4: Weltkarte des Eratosthenes, rekonstruiertnach den Angaben Strabons im 2. Buch der Geographika


nissen. Im Mittelalter wurde das Interesse an Karten bei den Arabern angeregt durch eingroÿes Handelsaufkommen mit fernen Ländern. Al Idrisi zeichnete ca. 1.200 n. Chr. seineWeltkarte auf einer zwei Meter groÿen Silberscheibe. Diese und weitere 70 Karten fassteer zu einem Atlas zusammen.

Später sollte die Kartographie einen groÿen Rückschritt erleiden, da die möglichst ex-akte Darstellung der Erde zugunsten einer religiösen Weltanschauung eingetauscht wurde[Mit05]. Um 1275 stellte Richard von Haldingham eine Weltkarte (Mappa Mundi) herbasierend auf dem damaligen geographischen Wissen über die Erde beein�usst durch dieKirche. Im Zentrum der Karte be�ndet sich Jerusalem, das für Christen den damaligenMittelpunkt der Welt darstellte. Durch den groÿen Ein�uss der Kirche hielt sich dieseAnsicht weit bis ins 16. Jahrhundert, da Karten hauptsächlich von Mönchen gezeichnetwurden. Mit der Er�ndung des Kupferstichs (ein Druckverfahren) wurden Unikatkartenimmer seltener.

Be�ügelt durch die immer stärker voranschreitende Seefahrt im 14. Jahrhundert ent-standen immer mehr See- und Weltkarten. Auf der einen Seite mussten sie immer genaue-re geometrische Abbildungen des Raumes darstellen (für die Kriegsführung) und auf deranderen Seite möglichst viel von der gesamten Welt zeigen (für die Kolonialisierung). Dar-unter war auch die Weltkarte des Piri Reis aus dem Jahre 1513. Er war ein Admiral derOsmanischen See�otte und Kartograph aus Leidenschaft, der seinen Zugang zur Bibliothekdes Sultans nutzte und eine der bekanntesten Karten der Weltgeschichte zusammentrug[Rae05]. Diese mit der Zeit immer genauer werdenden Karten waren so genannte Portola-ni, also Küstenkarten. Man entfernte sich mit der Zeit auch von den Fehlern Ptolemäus'

Abbildung 2.5: Hier 5. Europakarte des Ptolemäus, gezeichnetim Jahr 1541 in Wien durch Martin Waldseemüller

2.1 Kartographie 7

und ersetzte bislang �herbeifantasierte� Ausfüllungen der Karten durch neue Entdeckun-gen und Aufzeichnungen. Ende des 16. und Anfang des 17. Jahrhunderts traten erstmalsAtlanten vor die Portolani, wie z.B. der von Mercator und seinen Söhnen. Er entwickeltezu seiner Zeit eine Kartenprojektion der Erde, die noch heute unser Weltkartenbild prägt[BK01].

Mit Jacques und César Cassini, welche 1750 bis 1793 die groÿe Triangulation vonFrankreich und die darauf begründete groÿe topographische Karte vollendeten, beganndie Zeit der genauen topographischen Aufnahmen und der kritischen Bearbeitung vonKarten. Dem Beispiel der Franzosen folgten nun viele Länder Europas und kartographier-ten den Kontinent. Seit 1972 sind photogra�sche Abbildungen der Erdtopologie in denVordergrund gerückt durch verschiedene Satelliten, die der Erdbeobachtung dienen. Seitden 1990er Jahren ist die topographische Erforschung der Erde weitgehend abgeschlossen.Im Zeitalter der Computer gehen die jahrhundertelang handwerklich erstellten Zeichnun-gen zurück, und immer öfter treten so genannte Geoinformationssysteme (GIS) in denVordergrund.

2.1.2 Karten

�Unsere wichtigste Orientierungshilfe � nach der Sonne � ist die Karte� [Lin98]

Nachdem im historischen Abriss der Kartographie deutlich geworden ist, wie wichtigKarten für die Menschheit waren und auch heute noch sind, werden im folgenden Kar-ten klassi�ziert. Des weiteren wird verdeutlicht werden, welche Eigenschaften einer Karteexistieren und wie wichtig sie sind, wenn es um ihre Darstellung geht. Im späteren Ver-lauf der vorliegenden Arbeit wird der Einsatz dieser Eigenschaften diskutiert und die zugenerierenden Karten eingeordnet werden.

Der Wert einer Karte wird gemessen an ihrer Verständlichkeit für den Nutzer. DerNutzer muss in die Lage versetzt werden, Symbole und Zeichen in der Karte auf die Rea-lität zu beziehen. Anforderungen an eine gute Karte sind geometrische Richtigkeit undGenauigkeit, relative Vollständigkeit, Zweckmäÿigkeit (Topographie), Klarheit, Verständ-lichkeit, Lesbarkeit und Ästhetik.1 Karten haben einige allgemeine Eigenschaften, anhandderer sie gruppiert werden können. Hierzu zählen die Art der Karte, ihr Maÿstab und ihreProjektion.

Kartenart

Man unterscheidet bei Karten zwei Gruppen. Diese sind topographische und thematischeKarten, die im folgenden näher erläutert werden. Eine exakte Unterscheidung zwischentopographischen- und thematischen Karten ist jedoch nicht möglich, da auch die Topo-graphie einer Karte ein Thema darstellt.

1Soweit nicht separat angegeben, sind Ausführungen im folgenden Unterkapitel zum gröÿten Teilentnommen aus [HG94] [Den99] [Imh72].


Topographische Karten Topographie ist ein Teilgebiet der Kartographie und Geo-däsie und befasst sich mit der Vermessung, Darstellung und Beschreibung von Gelände,Orten und Landschaften. Das Institut für Angewandte Geodäsie de�niert 1973 Topogra-phische Karten als jene

�Karten in denen Situtation, Gewässer, Geländeform, Bodenbewachsung undeine Reihe sonstiger zur allgemeinen Orientierung notwendiger oder ausge-zeichneter Erscheinungen den Hauptgegenstand bilden und durch Kartenbe-schriftung eingehend erläutert sind.� [HG94]

Daraus folgt, dass Topographische Karten die Gegebenheiten der Erde oder Ausschnit-te dieser mit ihren wichtigsten Eigenschaften darstellen.

Thematische Karten Thematische Karten wurden von der Internationalen Kartogra-phischen Vereinigung 1973 de�niert als

�Jede Karte, in der Erscheinungen und Sachverhalte zur Erkenntnis ihrerselbst dargestellt sind. Der Kartengrund dient zur allgemeinen Orientierungund/oder zur Einbettung des Themas.� [HG94]

Einige Beispiele für Thematische Karten sind Straÿenkarten, politische Karten, geo-logische Karten und Wetterkarten. In thematischen Karten dient in der Regel eine topo-graphische Karte zur Orientierung als Untergrund bzw. Hintergrund (in obiger De�nitionKartengrund). Erscheinungen und Sachverhalte werden explizit eingezeichnet (geologischeKarten) oder besonders hervorgehoben wie bspw. das Schienennetz in den Netzplänen derdeutschen Bundesbahn. Thematische Karten vermögen stärker als rein topographischeKarten Informationen an den Nutzer zu vermitteln, da sie Informationen selektiert dar-stellen und somit übersichtlicher sind. Bis auf wenige Themenbereiche (z.B. Kataster-und Planungskarten) gibt es zu Kartendarstellungen und Inhalten kaum anerkannte undallgemeingültige Normen. Dies kann je nach Hersteller der Karte und Situation ein Vor-oder ein Nachteil sein, da gestalterische Freiheiten sehr unterschiedliche Darstellungsfor-men zulassen, aber andererseits dadurch thematische Karten schwer vergleichbar werden.

Maÿstab

Karten können auch nach ihrem Maÿstab gruppiert werden:

• Karten mit kleinem Maÿstabkleiner als 1:300000

• Karten mit mittlerem Maÿstab1:10000 - 1:300000

• Karten mit groÿem Maÿstabgröÿer als 1:10000

2.1 Kartographie 9

Als Kartenmaÿstab (Mk) gilt das lineare Verkleinerungs- oder Verjüngungsverhältnisder Karte gegenüber der Natur. Diese Verkleinerung wird beschrieben durch das Verhältniszwischen Kartenstrecke und Naturstrecke, wobei im Zähler die Längeneinheit 1 verwendetwird (mk = Maÿstabszahl) :

Mk = 1 : mk

Der Maÿstab bestimmt den Grad der Generalisierung auf der Karte. Mit sinkenderMaÿstabszahl sinkt auch die Detaillierung der geometrischen Darstellung von Realwelt-objekten. Je nach Thema resultiert ein Detaillierungsgrad, der wiederum den Maÿstabder Karte bestimmt.

Kartenprojektion

Eine weitere wichtige Eigenschaft von Karten nach der sie auch gruppiert werden können,ist die Kartenprojektion, deren Grundlagen im folgenden beschrieben werden.

Die Kartenprojektion ist der Versuch einer zweidimensionalen Abbildung der dreidi-mensionalen Erde. Mit dieser Problematik beschäftigen sich Mathematiker und Geogra-phen seit der Erkenntnis, dass die Erde keine Scheibe ist. Um nun die Ober�äche einerKugel (vereinfachte Darstellung der Erde - Abbildung 2.6) auf einer zwei dimensionalenFläche abzubilden, muss diese projiziert werden. Die Erde ist aber auch keine Kugel, son-dern ein Geoid (Abbildung 2.7). Zur Vereinfachung der mathematischen Berechnungenam Erdkörper benutzt man ein sogenanntes Rotationsellipsoid, das annähernd die Formdes Welt-Geoids aufweist.

Abbildung 2.6: Erdkugel Abbildung 2.7: Geoid,15000fach überhöht gezeichnet

Kartenprojektionen basieren auf geographischen Koordinatensystemen, die zur Positi-onsangabe auf dem Erdkörper dienen. Diese Koordinatensysteme bestehen aus der soge-nannten geographischen Breite, Länge und Höhe, die de�niert werden durch die Äquato-rialebene und einer künstlich festgelegten Nord-Süd-Linie, dem Nullmeridian (Abbildung2.9). Eine Gerade, die man sich durch den Nord- und Südpol denkt, bildet die Erdachse


um die sich die Erde dreht. Die Äquatorialebene liegt senkrecht zu dieser Achse in derMitte von Nord- und Südpol. Sie de�niert den Nullpunkt der geographischen Breiten,von der die Entfernung in Richtung Nord- und Südpol durch das Winkelmaÿ angegebenwird. In Nordrichtung wird sie dadurch mit positiven Gradwerten bis 90◦ de�niert undin Südrichtung durch negative Gradwerte bis -90◦. Bei geographischen Längen handelt essich um Längenkreise, die durch den Nordpol und durch den Südpol gehen (siehe Abb.2.8). Da es für Längen keine Orientierungs- bzw. De�nitionshilfe wie den Äquator für dieBreiten gibt, wurde dieser bis zum Jahre 1884 unterschiedlich de�niert, bis man sich dannauf den aktuellen Nullmeridian durch Greenwich in London einigte. Die Länge ist auch einWinkel, der jedoch in West- und Ost-Richtung vom Nullmeridian aus je maximal 180◦ seinkann, in Westrichtung -180◦ und in Ostrichtung 180◦. -180◦ und 180◦ stellen beide dieselbegeographische Länge dar, die gleichzeitig (mit einigen von den betro�enen Ländern be-stimmten Abweichungen) die Datumsgrenze bildet. Das Gauÿ-Krüger-Koordinatensystemist eines der bekanntesten die auf dieser Technik basieren. Es wird seit ca. 1923 vor al-lem im deutschsprachigen Raum genutzt. Dabei wird ihm das Bessel-Rotationsellipsoidzugrundegelegt mit 3◦ breiten Längengraden.

Abbildung 2.8:geographisches Breiten- u. Längennetz

Abbildung 2.9:geographische Breite, Länge u. Höhe

Die Projektion kann man sich vorstellen als eine Abbildung der Erde die dadurch ent-steht, dass eine Lichtquelle die Erde von innen ausleuchtet oder von auÿen durchleuchtet.Gewässer werden dabei durchleuchtet und Land wirft Schatten. Es gibt u.a. drei Haupt-gruppen von Projektionen: Planar- bzw. Azimutal-, Zylinder- und Kegelprojektion.

Bei der Planar- bzw. Azimutalprojektion unterscheidet man drei Arten der Pro-jektion, die die Erde auf eine �ache Ebene abbilden, wie in Abbildung 2.10 zu sehenist. Bei der orthographischen Azimutalprojektion wird durch eine Lichtquelle, die auÿer-halb der Erde parallele Lichtstrahlen wirft, die Erde durchleuchtet und auf eine planeEbene abgebildet. Bei der stereographischen Projektion hingegen sitzt die Lichtquelle ander gegenüberliegenden Kugelwand der interessierenden Seite. Gnomonische Projektionenerhält man dadurch, dass die Lichtquelle im Zentrum der Kugel sitzt und in alle Richtun-gen ausleuchtet. Orthographische Azimutalprojektionen können lediglich eine Hemisphäredarstellen und verzerren die Realität besonders zu den Rändern hin. Diese Darstellung

2.1 Kartographie 11

wird hauptsächlich genutzt, um die Ansicht der Erde aus dem Weltall darzustellen. Auchbei den stereographischen und gnomonischen Projektionen auf einer �achen Ebene ent-stehen unweigerlich Verzerrungen.

Zylinderprojektionen entstehen wie bei der gnomonisch azimutalen Projektion da-durch, dass im Erdzentrum eine vorgestellte Lichtquelle sitzt und die Erdkugel wiederumin einem Zylinder steckt, auf die projiziert wird. Hier unterscheidet man drei Arten wieder Zylinder zur Erde steht. Bei der äquatorialen Zylinderprojektion berührt der Zylin-der den Äquator. Wenn die beiden Pole durch den Zylinder berührt werden, handelt essich um eine transversale Zylinderprojektion. Die letzte, weniger gebräuchliche Art ist dieschiefachsige Zylinderprojektion.

Bei der Kegelprojektion ist der Körper, auf den abgebildet wird, ein Kegel. DerKegel berührt die Erdkugel in einem Kreis oder schneidet sie in zwei Kreisen. Der Berüh-rungskreis und die Form des Kegels entscheiden über das Aussehen der Projektion.

Streckenlängen, Winkel zwischen zwei Linien, Flächenform und -gröÿe sind die Ei-genschaften, die durch verschiedene Projektionen in Mitleidenschaft gezogen werden. Jenach Verwendungszweck und Maÿstab der Darstellung ist man gezwungen, die jeweilsbeste Projektion zu wählen, da es Projektionen gibt, die zwischen diesen Verfälschungenvermitteln aber nicht alle gleichzeitig beheben können. Es werden folgende Projektions-verzerrungen unterschieden, die desto gröÿer die abzubildende Fläche ist, umso extremerausfallen:

• ÄquidistantzverzerrungStrecken auf der Karte entsprechen nicht den realen Strecken auf der Erde; keineLängentreue.

• KonformitätsverzerrungWinkel an den Längengraden auf der Karte geben nicht die gleichen Winkel auf derErde an; keine Winkeltreue.

• ÄquivalentzverzerrungFlächen werden in ihrer Gröÿe nicht Maÿstabsgetreu dargestellt; keine Flächentreue.

Bei der bekanntesten Projektion der Weltkarte handelt es sich um die Mercatorprojek-tion aus dem Jahre 1569. Sie ist eine äquatoriale Zylinderprojektion, die als Berührungs-kreis den Äquator hat. Dadurch wird der Äquator längentreu dargestellt. In südlicher und

Abbildung 2.10: Planar- bzw. Azimutalprojektionen


nördlicher Richtung werden die Verfälschungen der Länge immer ausgeprägter. Dadurchist die Mercatorprojektion auch nicht �ächentreu, die Sowjetunion wird beispielsweise mitihren ca. 22, 4Miokm2 wesentlich gröÿer dargestellt wie der gesamte Kontinent Afrika mitseinen ca. 30Miokm2 (siehe Abbildung 2.11). Dies führte auch zu heftigen Diskussionenbei vielen nachfolgenden Kartographen, diese Projektion würde ein falsches Weltbild ver-mitteln. Jedoch ist sie winkeltreu, was zur damaligen Zeit der Seefahrer eine sehr wichtigeEigenschaft für Karten war. Eine �ächentreue Projektion einer Weltkarte bieten uns Gallund Peters. Sie entwickelten unabhängig voneinander eine zum verwechseln ähnliche Pro-jektion. Man bezeichnet diese auch als eine Konstruktion statt einer Projektion, da sienichts mit der Projektion, wie sie oben geschildert wurde, zu tun hat, sondern mathema-tisch berechnet wird.

Abbildung 2.11: Mercatorprojektion - Flächenuntreue Darstellung Sowjetunion/Afrika

Nachdem in diesem Abschnitt gezeigt wurde, wie es zu den bekanntlich unterschiedli-chen Darstellungen auf Karten des gleichen Weltausschnitts kommt, soll im folgenden derBereich, in den diese Arbeit einzuordnen ist, vorgestellt werden.

Gedruckte bzw. gezeichnete Karten, wie man sie bis zum Zeitalter der Computer ge-kannt hat, stellen Datenspeicher und Datenvisualisierung in nur einem Medium dar. Mitdem Druck der Karte sind die inhaltlichen und konzeptionellen Überlegungen abgeschlos-sen, eine nachträgliche Änderung ist nicht erwünscht, oftmals auch nicht möglich [Kri99].Dies stellt eine statische �Entwickler- und Nutzer-Beziehung� dar, die linear vom Entwick-ler zum Nutzer geht, ohne dass der Nutzer eine Möglichkeit der Manipulation hätte.

In der �heutigen Kartographie� steht die Trennung von Haltung und Visualisierunggeographischer Informationen im Vordergrund. Diese Tatsache führt immer mehr zur Ver-schmelzung der Kartographie mit der Informatik und somit u.a. zu dem neuen Werkzeugder �Geoinformationssysteme�.

2.2 Geoinformationssysteme 13

2.2 Geoinformationssysteme

�Ein Geoinformationssystem (GIS) ist ein Informationssystem, mit dem raum-bezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert, mo-delliert und analysiert sowie alphanumerisch und graphisch präsentiert werden.�[BF94]

Man kann auch sagen, dass Geoinformationssysteme versuchen, die reale Welt abzubil-den, wie es in Abbildung 2.12 verdeutlicht wird. Es werden nicht die realen Raumobjekteselbst betrachtet, sondern vielmehr Modelle der Realität. 2

Abbildung 2.12: Abbildung der realen Welt [Str05]

Diese Arbeit konzentriert sich im folgenden auf Grund der Aufgabenstellung haupt-sächlich auf die alphanumerische und graphische Präsentation von Geodaten, die in obigerDe�nition benannt werden.

Die Komponenten eines GIS unterteilt U. Streit, wie in Abbildung 2.13 zu sehen ist,in strukturelle Komponenten � Geodaten, Hardware, Anwender und Software � auf dereinen Seite und funktionale Komponenten � Erfassung, Verwaltung, Modellierung undVisualisierung � auf der anderen Seite. Bei der Visualisierung in GIS unterscheidet manverschiedene Dimensionen der Geodaten, die in dieser Diplomarbeit bis einschlieÿlich 2Dbetrachtet werden.

2Soweit nicht explizit angegeben sind die Ausführungen aus dem Skript zur Vorlesung �Einführung indie Geoinformatik� von Prof. Dr. Ulrich Streit an der Universität Münster ([Str05]) entnommen.


2.2.1 Geoobjekte

�Ein Geoobjekt (feature) ist das abstrakte Modell eines realen räumlichen Ob-jektes, das hinsichtlich seiner räumlichen Lage (Geometrie), seiner Lagebezie-hungen zu anderen Geoobjekten (Topologie), seiner fachlich relevanten Eigen-schaften (Thematik) und seiner zeitlichen Veränderungen (Dynamik) gegen-über anderen Geoobjekten unterschieden werden kann.� [Str05]

Ein solches Geoobjekt wird beschrieben durch seinen Objektidenti�kator, seineGeometrie /Topologie, seine Thematik und durch seine Dynamik und ist räum-lich eindeutig abgrenzbar. Der Objektidenti�kator ist ein eindeutiger Schlüssel, mit demein direkter Zugri� auf das Objekt gewährleistet wird. Die Geometrie von Geoobjektenbesteht in der Regel aus Positionsdaten in einem kartesischen Koordinatensystem mitder die absolute Lage festgehalten wird. Um die Geometrie eines Geoobjektes eindeutigbestimmen zu können, ist ein räumliches Bezugssystem nötig. Man di�erenziert dabeiVektordarstellung und Rasterdarstellung. Die Topologie beschreibt räumliche Beziehun-gen zwischen Geoobjekten, wie z.B. Nachbarschaft und Überschneidungen. Attribute, diemit dem Geoobjekt verknüpft werden (z.B. bei Stadt-Objekten Name, Einwohnerzahl,...) und einem fachlichen Charakter angehören, machen die Thematik aus. Dadurch wirdermöglicht verschiedene Thematiken zur Grundlage einer Geometrie zu verwalten. ZurBeschreibung der Thematik gibt es zwei Modelle:

1. Layer-ModellHier wird jedes Attribut in einer eigenen Schicht dargestellt, die je nach Bedarf ein-oder ausgeblendet werden kann (siehe Abb. 2.12). Dabei werden gleiche Attributeunterschiedlicher Objekte in der selben Schicht dargestellt. Der Maÿstab und auchder Raumausschnitt müssen bei allen Schichten gleich sein, damit sie übereinanderdeckungsgleich dargestellt werden können.

Abbildung 2.13: GIS-Komponenten nach U. Streit


2. Objekt-ModellIn diesem Modell sind Geoobjekte als Instanzen ihrer beschreibenden Klassen zusehen. Jedes Objekt verwaltet seine Attribute zu Geometrie, Topologie, Thematikund Dynamik selber. Ferner dienen Methoden zur Beschreibung des Verhaltens vonGeoobjekten.

Zeitliche Veränderungen am Objekt, die ihre Geometrie, Topologie sowie Thematikbetre�en können, machen die Dynamik aus. Beispielsweise in der Geologie interessierenZeitabschnitte von Tausenden von Jahren, in denen sich auch die Geometrie von Objektenverändern (Stichwort: Kontinentalverschiebung).

Modellierung von Geoobjekten

Wie in der De�nition des Begri�es Geoobjekt beschrieben, werden in der Geoinformatiknicht die realen Raumobjekte selbst betrachtet, sondern ihre gedanklichen Abbilder, alsoModelle der Realität. Modelle der Realität werden durch Abstraktion erhalten, d.h. durchVereinfachung der Realität. Dabei werden nur diejenigen Strukturen, Funktionen und Be-ziehungen betrachtet, die für die betrachtete Anwendung unbedingt erforderlich sind. Daswichtigste Abstraktionsmittel ist das Zusammenfassen ähnlicher Objekte (Klassi�kation)zu einem übergeordneten Typ (Klasse) unter Vernachlässigung spezieller Eigenschaften(Generalisierung).

In GIS werden dabei die Begri�e Typ und Klasse häu�g synonym verwendet. In derInformatik wird mit Klasse die De�nition von Attributen und Operationen für eine Men-ge gleichartiger Objekte bezeichnet, die durch diese Klasse erzeugt werden können. Dasheiÿt, dass die Klasse als eine Art Bauplan für Objekte anzusehen ist. Der Typ-Begri� je-doch wird in der Informatik meist allgemeiner verwendet (z.B. Datentypen, Systemtypen).

Geoobjekte können in verschiedenen Dimensionen modelliert werden. Die Dimensi-on eines Geoobjektes beschreibt die Anzahl voneinander unabhängiger Richtungen desRaumes, die zur geometrischen Modellierung des Raumobjektes verwendet werden. Da-bei stellen Punkte 0-Dimensionale Geoobjekte dar, da sie weder eine Länge noch eineFläche aufweisen. 1-Dimensionale Geoobjekte werden Linien genannt, die eine endlicheLänge jedoch auch keine Fläche aufweisen. 2-Dimensionale Geoobjekte werden bezeich-net als Flächen, die sie auch darstellen. Je nach Anwendung kann bei der Modellierungdie Dimension verringert werden. Beispielsweise werden im Streckennetzplan der Deut-schen Bundesbahn �ächenhafte Geoobjekte wie Städte in kleineren Maÿstäben model-liert als Punkte. Strecken, die diese Punkte verbinden, werden als Linien modelliert (1-Dimensionale Geoobjekte) und Bundesländer als Flächen (2-Dimensionale Geoobjekte).


2.2.2 Geodaten

�Geodaten sind formale Beschreibungen der Eigenschaften von Geoobjekten inForm von Zi�ern und Zeichen zur computergerechten Verarbeitung.�[Str05]

Geodaten werden interessen- bzw. anwendungsspezi�sch modelliert und durch Aus-wahl der dazu nötigen Eigenschaften abstrahiert. Objekte können dann weiter durch Ge-neralisierung (Weglassen spezieller Eigenschaften) zu Klassen zusammengefasst werden.Beispielsweise kann man Wald�ächen und Weide�ächen zusammenfassen zur Klasse derGrün�ächen. Der Prozess dieser Informationsreduzierung wird Generalisierung genanntund dient zur Maximierung der Vermittlung von relevanten Daten. Man unterscheidet da-bei zwischen Objekt- und Modellgeneralisierung. Eine Objektgeneralisierung tritt schonbei der Erfassung von Geodaten auf [Grü95], denn das zugrundeliegende Datenmodell be-stimmt Detaillierungsgrad und Ausschnitt der Realität, wonach Daten erfasst werden. Eskann auch vorkommen, dass aus vorhandenen Daten eines sehr detaillierten Modells Dar-stellungen extrahiert werden müssen, die weniger Informationen enthalten. Diese Formder Generalisierung nennt man Modellgeneralisierung, die oft in GIS auch als Datenbank-Generalisierung bezeichnet wird, da sie durch gezielte Abfragen an die Datenbank erzieltwerden kann. Bei der analogen Kartengestaltung sind beide Formen der Generalisierungdurch die begrenzte Darstellungsmöglichkeit von enormer Wichtigkeit. Bei digitalen Kar-ten, wie sie in GIS dargestellt werden können, dient Generalisierung hauptsächlich zurErstellung von ästhetischen und lesbaren Karten.

In Geoinformationssystemen ist es üblich, dass solche Geoobjekte mit den Informa-tionen ihrer geometrischen Form und mit ihren Attributen (Sachinformationen) abgelegtwerden. Dabei ist ihre Modellierung abhängig von verschiedenen Faktoren, wie Frage-stellung, Messtechniken, Analysemethoden, Arbeitsaufwand etc. auf der einen Seite undräumliche Dimension, räumliche Au�ösung und räumliche Dynamik auf der anderen Seite.

Bei der räumlichen Au�ösung besteht mit dem Kartographischen Maÿstab (aus demKapitel Grundlagen - Kartographie) eine enge Beziehung. Auch hier ist je nach Fachbe-reich ein bestimmter Maÿstab zu wählen, wonach sich bei der Modellierung der Detail-lierungsgrad der geographischen und sachlichen Informationen richtet. Desto detaillierterdie Informationen sind, umso gröÿer kann der Maÿstab gewählt werden.

2.2.3 Visualisierung

�Visualisierung (im Sinne der Informatik) ist die Transformation von Datenin ein sichtbares Bild zur Unterstützung der Exploration (Erkundung), Kogni-tion (Erkennen) und Explanation (Erklärung) von Strukturen und Prozessen.�[Str05]

Das menschliche Auge ist mit seinen 126 Millionen Rezeptoren (ca. 120 Mio. Stäbchenfür Graustufen, 6,5 Mio. Zäpfchen für Farbsehen) eines der komplexesten Organe desMenschen. Die visuelle Wahrnehmung des Menschen ist geprägt durch Erwartungen undErfahrungen. Wenn das Gesehene nicht den Erwartungen bzw. Erfahrungen entspricht,wird seine Wahrnehmung oder Interpretation schwieriger und somit langsamer. Ziel der


Visualisierung von Geoobjekten oder Visualisierung in GIS sollte es sein, die korrekteWahrnehmung räumlicher Sachverhalte durch die Berücksichtigung von Erwartungen desNutzers zu unterstützen.

Bei Geodaten handelt es sich in der Regel um alphanumerische Informationen, derenErkundung und Erkennung wegen der Gröÿe der Datenmenge ohne eine entsprechendeVisualisierung nicht zu bewältigen wäre. Aus diesem Grund bedienen sich Geoinforma-tionssysteme der modernen Kartographie. Diese unterscheidet bei der Darstellung vonGeoobjekten vereinfachend die Klassen punkt-, linien- und �ächenförmige Geoobjekte.Dabei entscheidet der Generalisierungsgrad, welche Geoobjekte Punkt-, Linien- oder Flä-chenförmig dargestellt werden müssen. Eine Stadt hat in der Realität eine �ächenhafteAusbreitung, doch kann diese, je nach Anwendung, auch punktförmig dargestellt werden.Punktförmig dargestellte Geoobjekte auf Karten sind in der Regel Vereinfachungen derRealität. Für die Gestaltung einer Karte gibt es sechs Variablen für die BasiselementePunkt, Linie und Fläche, wie sie in Abbildung 2.14 zu sehen sind.

Abbildung 2.14: Variablen zur Kartengestalltung nach Bertin [Ber74]

Bildschirmkarten

Bei Bildschirmkarten ist Qualität und Gröÿe der Ausgabe gegenüber dem herkömmlichenPapier wesentlich geringer. Sie unterliegen einigen Restriktionen, wie beispielsweise derBildschirmau�ösung, dem Bildschirmformat oder dem höchstmöglichen Kontrast, weshalbbei Ihrer Darstellung auf einiges geachtet werden muss, um die Lesbarkeit zu gewährleis-ten. Hierzu zählen minimale Strichbreite, minimaler Abstand zwischen Objekten, minima-le Längen, Flächen und Breiten [RP96]. Berücksichtigt man die Pixelgröÿen (ca. 0,25 mm)eines Bildschirms mit der Darstellungsmöglichkeit einer analogen Karte (ca. 0,1 mm), sokann man sagen, dass Bildschirmkarten etwa im doppelten Maÿstab der jeweiligen analo-gen Karte gezeichnet werden müssen [Töp92]. Bei einer normalen Leseentfernung von ca.


30 cm vermag das menschliche Auge eine Au�ösung von 0,05 mm wahrzunehmen. Dahersind Darstellungen von Linien mit 0,1 mm bei analogen Karten durchaus sinnvoll, die mitaktuellen Bildschirmen nicht denkbar sind.

Zu den auf normalen Karten vorhandenen Randangaben wie Titel, Maÿstab, Legende,usw. kommen nun Kontroll- und Steuerungsmechanismen zum Einsatz, die auch nochmalPlatz in Anspruch nehmen, wodurch sich der Raum für die Darstellung noch einmal verrin-gert [Rob93]. Jedoch können diese Nachteile teilweise durch Möglichkeiten der Interaktionund Techniken, wie u.a. �kurzzeitiges Herauszoomen zur Orientierung�, kompensiert wer-den. Bei der Bildschirmdarstellung sind zu beachten:

• Kleinmaÿstäbige und speziell generalisierte Darstellungenso ist trotz der kleineren Fläche, ein ähnlicher Überblick möglich,wie durch eine gedruckte Karte [Mat97]

• Zoom- und Scrollmöglichkeitenbei Darstellung groÿmaÿstäbiger Karten nötig, um gesamte Karteausschnittsweise anzeigen zu können

Randangaben können auch ausgelagert werden, um den Platz besser auszunutzen, z.B.in ein separates Fenster, dass über ein Menüpunkt erreichbar ist.

Vektordarstellung

Es sei ein kartesisches Koordinatensystem mit euklidischer Metrik vorausgesetzt. Im vor-angegangenen Kapitel wurde für die Kartographie das Gauÿ-Krüger-Koordinatensystemals solches vorgestellt. Das Basiselement der Vektordarstellung ist der Punkt, der im zwei-dimensionalen Raum eindeutig bestimmt ist durch ein Koordinatenpaar. Beispielsweiseist ein Punkt P im Gauÿ-Krüger-Koordinatensystem durch seinen Rechts- und Hochwerteindeutig bestimmt: P (r, h). Je nach Thematik und Generalisierungsgrad der anzuzei-genden Geodaten können diese Punkte Städte (bei Weltkarten) oder Raststätten (beiAutobahnkarten) repräsentieren. Zur exakten Beschreibung einer Linie, zur Darstellungeiner Landstraÿe im geometrischen Sinne wäre eine mathematische Formel notwendig, dieeine Verbindung von zwei Punkten darstellt. Da diese in der Regel nicht geradlinig sind,wären solche Formeln recht aufwendig, weshalb man sich in der Geoinformatik einer Ap-proximation bedient. Eine solche Landstraÿe wird durch eine geordnete Folge von PunktenP1, P2, P3, P4, ... dargestellt, die mit Geraden verbunden werden. Durch die Ordnung inder Folge, ist es auch möglich, gerichtete Linien im topologischen Sinne darzustellen. Mitdieser Technik ist es dann auch einfacher, Flächen wie Bundesländer darzustellen, jedochmit dem Unterschied: P1, P2, P3, P4, ..., P1. Man fordert, dass es eine geschlossene Folgevon Punkten ist, d.h. der erste und letzte Punkt der geordneten Folge sind identisch.

Rasterdarstellung

Bei der Rasterdarstellung ist die Au�ösung, die zugrunde gelegt wird, sehr wichtig. Nachdieser richtet sich die Detaillierung der Daten. Da der Speicherbedarf für Rasterdaten


Abbildung 2.15: Vektordarstellung Abbildung 2.16: Rasterdarstellung

enorm ist, eignen sich diese eher zu Darstellungen mit geringerer Detailstufe. Sie entste-hen in der Regel durch Satellitenfotos oder Scannen von Karten. Ein weiteres Problemstellt auch die Tatsache dar, dass zusammengehörige Objekte nicht sofort als solche er-kannt werden können. Durch Optimierungsverfahren ist es möglich den Speicherbedarf zuverkleinern; hier sei das Quadtree-Verfahren erwähnt, bei dem Pixel mit gleichen Wertenzusammengefasst werden. Pixel sind quadratische Gebilde einer bestimmten Gröÿe, diein Zeilen und Spalten angeordnet sind, wie in Abbildung 2.16 dargestellt. Sie sind immergefüllt mit nur einer Farbe und kennen keine Unterscheidung zwischen Punkt, Linie oderFläche.

Vektor- vs. Rasterdarstellung

Bei der Vektordarstellung von Geometriedaten ist eine sehr gute Modellierung einzelnerGeoobjekte möglich. Sie erlaubt dabei eine beliebig hohe Genauigkeit von Form und Lage,jedoch wächst der Erfassungsaufwand mit steigender Genauigkeit. Ein weiterer wesent-licher Vorteil ist, dass geringere Datenmengen entstehen. Für �ächenhafte Verteilungen(Bsp.: Bodenarten von Acker�ächen, die nicht durchgehend gleich sind) ist sie jedoch eherungeeignet.

Rastermodelle hingegen sind für solche �ächenhaften Verteilungen besser geeignet.Rastermodelle zur Darstellung haben den entscheidenden Nachteil, dass jeder Pixel einebestimmte (Teil-)Fläche darstellt und somit bei höheren Ansprüchen die Au�ösung wach-sen muss. Mit wachsender Au�ösung wächst der Speicherbedarf mit.

Welches nun das geeignetere Modell zur Darstellung von Geodaten ist, ist abhängigvom Genauigkeitsanspruch des Anwenders bzw. der Anwendung. Bei hohen Ansprüchen,wie bei Flurstücksbeschreibungen, ist das Vektormodell vorzuziehen. Auf der anderen Sei-te gestaltet sich in einem Rastermodell die Verarbeitung von Daten im Sinne geometrischerOperationen erheblich einfacher [DZ99].

Kapitel 3

Grundlagen aus der Informatik

3.1 Datenbanken

�A database is a repository of data that is logically related, but possibly phy-sically distributed over several sites, and required to be accessed by manyapplications and users. A database is created and maintained using a general-purpose piece of software called a database management system (DBMS).�[WD04]

Wie dem Titel dieser Diplomarbeit auch zu entnehmen ist, entstammen die darzustel-lenden Geodaten aus relationalen Datenbanken. Datenbanken sind wegen ihrer schnellenund e�zienten Bearbeitung von Anfragen zu gespeicherten Daten jeder Art, das Herz-stück eines jeden Geoinformationssystems. Der Begri� der Datenbanken wird oft synonymfür Datenbanksysteme genutzt. 1

3.1.1 Datenbanksysteme

Datenbanksysteme bestehen aus anwendungsunabhängiger Verwaltungssoftware (DBMS),die die Gesamtheit aller Programme zur Verwaltung verschiedener Datenbanken aus-macht, und aus anwendungsspezi�schen Datenbanken [Man99]. DBMS basieren auf ei-nem Datenmodell, mit der die Modellierung der realen Welt möglich wird. Eine solcheModellierung ist in beiden Ebenen des Datenbankentwurfs (konzeptioneller- und physi-scher Entwurf) nötig. Im konzeptuellen Entwurf gibt es u.a. das am häu�gsten genutzteEntity-Relationship-Modell (ER-Modell), das im Verlauf dieser Arbeit genutzt werdenwird. In der physischen Ebene können Netzwerkmodell und hierarchisches Datenmodellals Beispiele angeführt werden. Relationales Datenmodell, objektorientiertes Datenmodellund deduktives Datenmodell zählt man zu den hybriden Modellen. Im GIS-Umfeld wer-den relationale und objektorientierte Datenmodelle bevorzugt. Das Augenmerk in dieserDiplomarbeit wird auf das relationale Datenmodell gerichtet werden.

1Ausführungen in diesem Kapitel entstammen aus [Man99], [KE01] und [WD04] soweit nicht explizitetwas Anderes angegeben wird.

20

3.1 Datenbanken 21

3.1.2 Entity-Relationship-Modell

Das Entity-Relationship-Modell soll im folgenden vorgestellt werden, da es ein system-unabhängiges Modell für den konzeptionellen Entwurf darstellt, und die fast automatischeÜberführung aus dem konzeptuellen in das relationale Schema erlaubt. Ferner ist es ei-nes der bekanntesten Modelle unter Entwicklern. Das ER-Modell basiert auf den Model-lierungsstrukturen Entities (Gegenstände) und Relationships (Beziehungen). WeitereStrukturen sind Rollen und Attribute. Entities sind physisch oder gedanklich exis-tierende und wohlunterscheidbare Dinge der zu modellierenden Welt. Gegenstände mitähnlichen oder gleichen Eigenschaften können zu Entitytypen zusammengefasst werden.Da das ER-Modell ein graphisches Modellierungskonzept ist, existieren Vereinbarungen,wie ihre Modellierungsstrukturen darzustellen sind. Entitytypen werden beispielsweise inRechtecken dargestellt, in denen ihr Name ausgeschrieben wird (siehe Abbildung 3.1 -Studenten). Analog werden Beziehungen zwischen Entities zusammengefasst zu Rela-tionshiptypen. Diese wiederum können betrachtet werden als Relationen im mathe-matischem Sinne. Dabei können diese Relationen 1:1-, 1:n- und n:m-Beziehungen dar-stellen. Die graphische Darstellung von Relationshiptypen erfolgt durch die Bezeichnungin einer Raute (siehe Abbildung 3.1 - hören). Entities sowie Relationships werden durchAttribute charakterisiert, die durch abgerundete Kästen dargestellt werden, in denen ihreBezeichnung stehen (siehe Abbildung 3.1 - MatrikelNr und Häu�gkeit). Die Identi�zie-rung eines bestimmten Entity innerhalb des Entitytyps erfolgt über einen so genanntenSchlüssel. Ein Schlüssel ist eine minimale, identi�zierende Attributskombination. Es istüblich ein einzelnes Attribut als Schlüsselattribut künstlich zu erzeugen, wenn keine At-tributskombination dieser Forderung genügt. Das Schlüsselattribut wird graphisch durchUnterstreichen des Attributnamen dargestellt (siehe Abbildung 3.1 - MatrikelNr). Die ge-genseitige Zuordnung der graphischen Elemente im ER-Modell erfolgt durch ungerichteteKanten. In Abbildung 3.1 ist ein Bruchteil eines ER-Schema zur Universitätsverwaltungbeispielhaft dargestellt. Diese enthält Studenten- und Vorlesungen-Entities und die Rela-tion hören mit den zugehörigen Attributen.

Abbildung 3.1: Beispiel für ER-Modell

Um eine bessere Strukturierung der Entitytypen zu erzielen, wird im konzeptuellenEntwurf die Generalisierung eingesetzt. Diese ist als eine Abstraktion auf Typebene an-zusehen. Dabei werden die Eigenschaften ähnlicher Entitytypen (hauptsächlich Attribu-te und Beziehungen) einem gemeinsamen Obertyp zugeordnet. Diese ähnlichen Typenwerden als Untertypen bezeichnet. Um die Beziehung zwischen Ober- und Untertypverdeutlichen zu können und eine Verwechslung mit den bisher kennengelernten Bezie-

22 Kapitel 3. Grundlagen aus der Informatik

hungen zu vermeiden, werden Generalisierungen dargestellt durch ein Sechseck und derBeschriftung is-a. Die gegenseitige Zuordnung der graphischen Elemente erfolgt in diesemFall über gerichtete Kanten vom Untertyp über die Beziehung (is-a) zum Obertyp (sieheAbbildung 3.2).

Abbildung 3.2: Beispiel 2 für ER-Modell

Die Überführung eines solchen ER-Modells in ein relationales Datenbankschema kannfast automatisch erfolgen durch die Regeln:

1. Für jeden Entitytyp des ER-Modells wird eine Relation (Tabelle) erstellt. DieseRelation enthält alle Attribute eines Entitytyps.

2. Auch für jeden Relationshiptyp wird eine Relation erstellt. Dabei enthält die Relati-on als Attribute alle Primärschlüssel der beteiligten Entitytypen und alle Attribute,die zu dem Relationshiptyp gehören.

3.1.3 Relationales Datenmodell

Das relationale Datenmodell basiert im wesentlichen auf Tabellen (Relationen). DieseTabellen können eine Objektklasse darstellen, deren Zeilen (Tupel) den Datenobjektenentsprechen. Datenobjekte werden durch die Gesamtheit der Spaltenwerte einer Zeile de-�niert, die die einzelnen Attribute der Objekte beinhalten. Werte für Attribute könnenaus unterschiedlichen Wertebereichen (Domänen) sein. Die Werte einer Spalte dürfen da-bei nur aus dem selben Wertebereich stammen und dabei atomar sein. D.h. sie dürfen nuraus einfachen Wertebereichen stammen, die nicht zusammengesetzt, mengenwertig oderrelationenwertig sind. Eine Relation, die dieser Einschränkung genügt, wird als Relation inerster Normalform bezeichnet. Es wird unterschieden zwischen dem Relationsschema undeiner Instanz dieses Schemas. Das Schema ist gegeben durch Spalten und ihren Wertebe-reichen. Die Instanz hingegen ist eine Teilmenge des Kreuzproduktes dieser Wertebereiche.Bei der Schemade�nition, die zu Beginn jeder Datenbankmodellierung vorgenommen wird,werden Relationen und ihre Spalten mit Namen benannt.

Stadt: {[ Name: string, Einwohnerzahl: integer, Länge: �oat, Breite: �oat ]}

Es kann nötig sein, dass unterschiedliche Objektklassen modelliert werden müssen, diein einer Beziehung zu einander stehen. Dabei werden drei Beziehungstypen 1:1, 1:n undm:n unterschieden. Gibt es beispielsweise zwei Relationen (Stadt und Oberbürgermeister),

3.1 Datenbanken 23

so kann folgende 1:1 Beziehung formuliert werden: Stadt x regiert von Oberbürgermeis-ter y, da eine Stadt höchstens von einem Oberbürgermeister regiert werden kann. Umeinzelne Objekte in Relationen eindeutig bestimmen zu können, werden ihnen künstlichSchlüssel (Primärschlüssel) zugewiesen. Mit Hilfe dieser Schlüssel ist es möglich, die obengenannten Beziehungen zu verwirklichen. Dabei wird bei 1:1-Beziehungen der Primär-schlüssel der einen Relation in der anderen Relation aufgenommen. An dieser Stelle wirder �Fremdschlüssel� genannt.

Stadt: {[ Name: string, Einwohnerzahl: integer,Länge: �oat, Breite: �oat,regiert_von: integer ]}

Bei 1:n-Beziehungen, wie sie gegeben sind bei Stadt x gehört zu Land y, wird derFremdschlüssel in die Relation mitaufgenommen, die die Stelligkeit n hat. Im vorange-gangenen Beispiel wäre dies so, dass in die Relation Stadt der Fremdschlüssel land_idaufgenommen werden würde. m:n-Beziehungen bedürfen einer weiteren eigenen Relation,damit keine redundanten Daten gehalten werden müssen. Sie vereinen die Primärschlüsselbeider Relationen. Ein Beispiel für diesen Beziehungstyp wäre Partei x regiert Bundeslandy, wenn bei koalitionsregierten Bundesländern die Speicherung der einzelnen Parteien zu-gelassen wird.

Um Informationen aus der Datenbank extrahieren zu können, existieren für das re-lationale Datenmodell zwei formale Anfrage-Sprachen: die relationale Algebra (RA)und der Relationenkalkül. Diese basieren auf mengentheoretischen Operationen, wieVereinigung, Di�erenz, Schnitt und Kreuzprodukt.

3.1.4 Relationale Algebra

Die relationale Algebra bietet verschieden Operatoren an, die im Folgenden erläutertwerden sollen.

Selektion

Um eine bestimmte Menge von Tupeln aus einer Relation auswählen zu können, bietetsie beispielsweise die Selektion:

σ<Selektionspradikat>(< Relation >)

Sie gibt die Tupel der Relation zurück, die das Selektionsprädikat erfüllen. Ein Beispielfür die Selektion wäre folgende Anfrage:

σEinwohnerzahl>100000(Stadt)

Dadurch würden alle Städte mit mehr als 100000 Einwohnern zurückgegeben. Dazu wirdjedes Tupel der Relation Stadt einzeln auf das Prädikat Einwohnerzahl > 100000 geprüft.Wenn das Tupel dieses erfüllt wird es in eine Ergebnisrelation kopiert.


Projektion

Zum extrahieren von bestimmten Spalten (Attributen) aus der Relation wird die Projek-tion genutzt:

Π<Attributliste>(< Relation >)

Würde beispielsweise Name, Einwohnerzahl für Attributliste eingesetzt und die Relationbei Stadt belassen, so würde die Ergebnisrelation lediglich aus den beiden Spalten Nameund Einwohnerzahl bestehen.

Vereinigung

Zwei Relationen mit gleichem Schema (d.h. gleiche Attributnamen und Domänen) könnendurch die Vereinigung zu einer Relation zusammengefasst werden.

< Relation > ∪ < Relation >

Dabei kann <Relation> auch eine Ergebnisrelation sein, die durch einen RA-Ausdruckdargestellt wird. Zum Beispiel:

ΠPersNr, Name(Angestellte) ∪ ΠPersNr, Name(Arbeiter)

Mengendi�erenz

Sollen aus zwei Relationen R und S mit gleichem Schema, nur diejenigen Tupel aus Rextrahiert werden, die nicht in S enthalten sind, ist die Mengendi�erenz anzuwenden:

R− S

Kartesisches Produkt

Auch das Kreuzprodukt zweier Relationen ist de�niert:

R× S

Sie ergibt eine Ergebnisrelation in der alle Attribute beider Relationen vorkommen. Dabeiwird bei Gleichheit von zwei Attributnamen, jeweils der Relationsname mit einem Punktvorangestellt. Die Anzahl der Tupel in der Ergebnisrelation ergibt sich aus dem Produktder Anzahl der jeweiligen Relation, d.h. in der Ergebnisrelation kommt jedes Tupel dereinen Relation gepaart mit einem Tupel der anderen Relation vor.

Umbenennung

Wenn eine Relation mehrfach in einer Abfrage genutzt werden soll, bietet die RA denOperator zum Umbenennen der Relation:

ρ<Relationsname neu>(< Relationsname alt >)

3.1 Datenbanken 25

Weitere Operationen

Mit Hilfe dieser Basisoperationen der RA sind weitere komplexere Operationen (sieheAbb. 3.3) formulierbar, z.B. der relationale Verbund 1 (Join). Dieser setzt sich wiefolgt zusammen, wenn die Relation R mit m + k Attributen A1, ..., Am, B1, ..., Bk und dieRelation S mit k + n Attributen B1, ..., Bk, C1, ..., Cn �verbunden� werden:

R 1 S = ΠA1,...,Am,R.B1,...,R.Bk,C1,...,Cn(σR.B1=S.B1∧...∧R.Bk=S.Bk(R× S))

Abbildung 3.3: Verschiedene Join-Operatoren [KE01]

Auf der relationalen Algebra und dem Relationenkalkül basierend, hat sich die struc-tured query language (SQL), zur De�nition und Manipulation von Daten auf relationalenDatenbanken, durchgesetzt.

3.1.5 SQL

Diese Sprache zur Schemade�nition und Datenmanipulation kann alleine eingesetzt wer-den, um direkt über eine Konsole des DBMS auf die Datenbank einzuwirken oder einge-bettet in anderen Programmiersprachen. Sie wird praktisch von allen relationalen Daten-banksystemen zur Verfügung gestellt.

Datentypen

Relationale Datenbanken stellen in der Regel drei fundamentale Datentypen als Attribut-Domänen zur Verfügung: Zahlen, Zeichenketten und einen Datumstyp. Bei Zeichenkettenwerden hauptsächlich zwei Typen unterschieden: char(n) oder varchar(n). Dabei reprä-sentiert n die maximale Anzahl der Zeichen, die gespeichert werden können. Bei char(n)werden Werte immer mit der festen Länge n abgespeichert. Wird varchar(n) verwendet,so speichert die DBMS bis zu einer Maximallänge von n lediglich mit der genutzten Län-ge. Der Zahlentyp numeric(p, s) ist der allgemeinste und reserviert einen Speicher mitp Stellen, wovon s Nachkommastellen sind. Der Datumstyp date speichert in der RegelDatum und Uhrzeit in der Form JJJJ-MM-TT hh:mm:ss.


Schemade�nition

Die Schemade�nitionen einer Datenbank werden in dem sogenannten DataDictionary ge-speichert. Dieses enthält Metadaten, die den Zustand der Datenbank beschreiben. Um dasSchema einer Datenbank zu de�nieren, das aus Tabellen- und deren Attributde�nitionenbesteht, muss der create table-Befehl genutzt werden.

CREATE TABLE Studenten

(MatikelNr INTEGER NOT NULL,

Name VARCHAR(10) NOT NULL,

GebDat DATE NOT NULL);

Dem CREATE TABLE-Befehl folgt der Tabellenname. Dahinter steht in runden Klam-mern eine Liste der Attribute, die durch Komma getrennt werden. Den Attributnamenfolgt eine Typangabe. Optional kann hierauf NOT NULL folgen, was eine sogenannteIntegritätsbedingung darstellt, die besagt, dass Tupel der Tabelle zwingend Werte für dieseAttribute haben müssen. Die Angabe der Datentypen gehört auch zur Integritätsbedin-gung dieser Tabellende�nition, denn diese verlangt beispielsweise bei der MatrikelNr eineganze Zahl. Kein anderer Wert würde hier von dem DBMS akzeptiert werden.

Schemaveränderung

Die Schemade�nition kann im nachhinein noch immer verändert werden. Hierfür exis-tiert in der SQL-De�nition der Befehl ALTER TABLE. Mit seiner Hilfe ist es möglichTabellen Attribute hinzuzufügen durch ADD:

ALTER TABLE Studenten

ADD (Initialen CHAR(2) );

Attribute der Tabelle zu verändern ohne dieNOT NULL-De�nition aus der ursprünglichDe�nition zu berühren:


MODIFY (Name VARCHAR(20) );

Attribute der Tabelle zu entfernen:


DROP COLUMN GebDat;

oder die ganze Tabelle zu entfernen:

DROP TABLE Studenten ;

3.1 Datenbanken 27

Datenmanipulation

Die Datenmanipulation lässt sich unterteilen in Einfügeoperationen, Anfrageoperationen,Änderungsoperationen und Löschoperationen. Für die Einfügeoperation steht der Be-fehl INSERT INTO zur Verfügung. Um ein Tupel in zuvor erstellte Tabelle einzufügen,würde der Befehl folgendermaÿen genutzt werden:

INSERT INTO Studenten

VALUES (934752, 'Max Mustermann', 1975-03-13 00:00:00, 'MM' ) ;

Für einfache Anfrageoperationen an eine Datenbank ist der SELECT-Befehl vor-gesehen. Hinter dem reservierten Wort SELECT kann ein * oder eine Liste von kommage-trennten Attributnamen stehen, die eine Liste der gewünschten Attribute darstellt. Dabeientspricht der * allen Attributen der Tabellen im FROM-Teil. Im From-Teil werden allean der Anfrage beteiligten Tabellen (Relationen) deklariert. Auch die in der Relationa-len Algebra (RA) kennengelernte Operation zur Umbenennung von Tabellen, kann hierangewandt werden, indem der alte Tabellenname gefolgt vom Schlüsselwort AS und demneuen Tabellennamen eingefügt wird. Der optionale WHERE-Teil ist vergleichbar mitder Selektion aus der RA. Sie dient dazu, die Teilmenge der gewünschten Tupel zu spezi-�zieren. Wenn dieser Teil weggelassen wird, gibt die SELECT-Anweisung alle Tupel derangegebenen Relationen zurück. Mit dem letzten optionalen Teil ist eine sortierte Rück-gabe der Tupel möglich. Dafür muss der Attributname, nachdem sortiert werden soll,und eines der Schlüsselwörter ASC für absteigende Sortierung und DESC für ansteigendeSortierung angegeben werden.

SELECT Attributliste

FROM Tabellenliste

[WHERE Bedingung ]

[ORDER BY Attributname ASC | DESC]

Im folgenden seien die Möglichkeiten von SQL beispielhaft erläutert. Mit folgender An-frage werden alle Deutschen Städte sortiert, nach Ihrem Namen, angefordert.

SELECT *

FROM Stadt, Land

WHERE Land.Name = ` deutschland` AND

Stadt.gehoert_zu = Land.land_id

ORDER BY Stadt.name ASC


Auf diese Weise sind weitere Operatoren, wie sie in Abbildung 3.3 zu sehen sind, konstru-ierbar.

Um bestehende Datensätze in den Tabellen Ändern zu können steht die Änderungs-operation UPDATE zur Verfügung. Die Syntax für diese Operation kann wie folgendbeschrieben werden:

UPDATE Tabellenname

SET Attributname = neuer Attributwert

[WHERE Bedingung ]

Für alle Tupel wird der Attributwert des Attributs Attributname in der Tabelle mit demNamen Tabellenname ersetzt durch neuer Attributwert, wenn die Bedingung für das Tupelerfüllt ist.

Löschoperationen können mit Hilfe des Befehls DELETE FROM ausgeführt wer-den. Folgendes Beispiel löscht alle Städte aus der Tabelle, die weniger als 10.000 Einwohnerhaben:

DELETE FROM Stadt

WHERE Einwohnerzahl < 10000 ;

Sichten

Um Datenbanksysteme an spezielle Bedürfnisse unterschiedlicher Benutzergruppen undAnwendungen anpassen zu können, gibt es das Konzept der Sichten (engl. views). WerdenDatenbanken als Mengen von Daten gesehen, so können Sichten als eine für eine bestimm-te Benutzergruppe oder Anwendung interessante Teilmengende�nition bezeichnet werden.Das besondere an Sichten ist, dass sie virtuelle Teilmengen (Relationen) bieten. �Virtuell�soll dabei verdeutlichen, dass keine neuen Tabellen angelegt werden, sondern bei jedemZugri� die, durch diese Sicht de�nierte, Relation aus vorhandenen Relationen neu berech-net wird. Beispielsweise könnte das letzte SQL-Anfrage-Beispiel als Sicht de�niert werden.Dies ist auch in SQL möglich durch CREATE VIEW ... AS ...wie im folgenden zu sehen:

CREATE VIEW deutscheStaedte AS

SELECT *

FROM Stadt, Land

WHERE Land.Name = ` deutschland` AND

Stadt.gehoert_zu = Land.land_id

ORDER BY Stadt.name ASC;

3.2 .NET 29

3.2 .NET

Eine weitere Vorgabe für diese Diplomarbeit war die Programmiersprache Visual Basic.Um aktuelle Entwicklungen der Softwaretechnologie in den Entwurf und in die Imple-mentierung ein�ieÿen lassen zu können, wurde die aktuelle Version �VisualBasic.NET�eingesetzt.

Die .NET-Plattform gliedert sich in vier voneinander unabhängige Bereiche:

• Entwicklungswerkzeuge und -BibliothekenHierzu zählen u.a. Programmiersprachen wie VisualBasic.NET und C#, Bibliothe-ken zur Erzeugung von Internet und Windowsanwendungen und die Common Lan-guage Runtime (CLR)

• WebservicesHierbei handelt es sich hauptsächlich um kommerzielle Webservices, die Entwicklernzur Verfügung gestellt werden und online genutzt werden können.

• spezielle ServerDiese Server unterstützen .NET-Funktionalitäten und APIs. Zu dieser Gruppe vonServern zählen u.a. SQL-Server und Exchange-Server.

• HardwareMit Hardware sind keine Desktop-PC gemeint, vielmehr handelt es sich dabei umGeräte, die ausschlieÿlich .NET unterstützen, wie einige Spielekonsolen, Handys undPDAs.

Das Ziel von .NET ist es, Software plattformunabhängig als reinen Service bereit stel-len zu können. D.h. Anwender sollen on demand, wenn sie eine bestimmte Anwendungbenötigen, darauf zugreifen können. Wichtigste Komponente ist das oben angesprocheneCLR. Es ist vergleichbar mit der Java Virtual Machine und dient zur internen Erstellungvon Objekten, deren Sicherheitschecks, Speichermanagement, Ausführung und Garbage-collection (Objekte deren Instanzen nicht mehr benötigt werden, werden aufgesammeltund entsorgt). Wie weiter oben erwähnt, ist es in .NET möglich, in verschiedenen Spra-chen zu programmieren. Da alle diese Sprachen auf dem CLR operieren, ist es möglich,programmiersprachenübergreifend zu arbeiten. D.h. man könnte in VisualBasic.NET aufBibliotheken und APIs zurückgreifen und diese beerben, auch wenn sie ursprünglich inC#, C++ oder in einer anderen von .NET unterstützen Programmiersprache erstellt wor-den sind. Der umgekehrte Weg ist analog auch möglich.

3.2.1 Visual Basic .NET

Visual Basic (VB) war die erste Programmiersprache, die es ermöglichte, Bedienerober-�ächen von Anwendungen komfortabel zu zeichnen. Soll eine neue Anwendung entwickeltwerden, legt der VB-Editor automatisch eine so genannte Form an, die die Plattform fürdiese Anwendung repräsentiert. Der Programmierer �zeichnet� die Benutzerschnittstelleder Anwendung, indem er Eingabefelder, Tasten und Ähnliches aus einer Toolbox zieht


und auf der Form platziert. Der Quellcode zu dieser gezeichneten Ober�äche wird auto-matisch durch den VB-Editor erstellt, wodurch dem Programmierer viel Zeit erspart wird.Aus dieser Funktionalität heraus ist auch der Name Visual Basic entstanden.

Die neue Version von Visual Basic � Visual Basic .NET � ermöglicht das Programmie-ren mit aktuellen Softwaretechnologischen Konzepten wie u.a. Namespaces, Schnittstellen,Kapselung, Vererbung, Polymorphismus und Exception-Handling. Damit unterstützt esstrukturierte, komponentenbasierte und objektorientierte Programmierung. Ein VisualBasic .NET - Compiler erzeugt keinen spezi�schen Maschinencode sondern einen plattfor-munabhängigen Zwischencode, genauer einen Microsoft Intermediate Language (MSIL) -Code, der wiederum vom CLR bei jedem Aufruf erneut compiliert wird. Zum ausführenvon Visual Basic .NET Programmen muss deshalb das .NET-Framework installiert sein,welches das CLR und verschiedene Bibliotheken (ADO.NET, GDI+, usw.) mit sich bringt.

3.2.2 ADO.NET

Zu diesen Bibliotheken gehört auch ADO.NET2 mit vielen Klassen zum Einfügen, Ausle-sen, Manipulieren und Löschen von Daten auf unterschiedliche Weisen. Als ein wichtigerBestandteil der .NET-Plattform unterstützt ADO.NET viele Eigenschaften dieser Platt-form, wie beispielsweise Sprachunabhängigkeit, Objektorientierung und Garbagecollecti-on. ADO.NET bietet Klassen zur Verbindung mit einer Datenquelle, die Übermittlungvon Anfragen und die Verarbeitung von Ergebnissen. Zu den unterstützten Datenquel-len zählen neben verschiedenen Datenbanken auch XML-Dateien. Das Objektmodell vonADO.NET besteht aus �verbundenen� und �unverbundenen� Objekten, die im Verlaufdieses Kapitels näher betrachtet werden. Zu den Verbundenen zählen jene Objekte, diedirekt auf die Datenbank zugreifen, um Verbindungen und Transaktionen zu verwalten,Daten zu empfangen und Änderungen zu übermitteln. Die Unverbundenen hingegen stel-len Objekte zur Verfügung, die es erlauben Daten im Speicher zu bearbeiten ohne mit derDatenbank verbunden zu sein (Abbildung 3.4).

Um diese unverbundenen Objekte �befüllen� zu können werden sie der �ll -Methodeeines verbundenen Objektes übergeben, der sie dann befüllt. Analog wird das unverbun-dene Objekt DataSet nach einer Änderung im Speicher übergeben an die Update-Methodedes verbundenen DataAdapter -Objekts, der die Änderungen dann in die Datenbank pro-pagiert.

.NET-Datenprovider bestehen aus einer Reihe von Klassen, die es ermöglichen, Daten-speicher eines bestimmten Typs anzusprechen. Das .NET-Framework bietet hierzu einenfür SQL-Server ab Version 7 an und eines für Datenbanken, die über OLE DB-Providerangebunden werden können. .NET-Datenprovider bieten beide die Basisklassen Connec-tion, Command, DataReader, Parameter und Transaction, die jeweils anders benanntsind: beispielsweise SQLConnection oder OLEDBConnection. Diese beiden Datenprovi-der unterscheiden sich bei der Programmierung dadurch, dass unterschiedliche Klassen

2Inhalte dieses Kapitels entstammen hauptsächlich aus [Sce02] und [JDF02]

3.2 .NET 31

instanziiert werden und verschiedene Verbindungsstrings genutzt werden müssen:

' Öffnen und Schlieÿen einer Verbindung mit dem OLE DB .NET-DatenproviderDim cnOleDb As NewOleDbConnectioncnOleDb.ConnectionString = "Provider=SQLOLEDB; " & _

"Data Source=(local);InitialCatalog=Datenbank;..."cnOleDb.Open()...cnOleDb.Close()

' Öffnen und Schlieÿen einer Verbindung mit dem SQL Client .NET-DatenproviderDim cnSql As NewSqlConnectioncnSql.ConnectionString = "Data Source=(local);" & _

"Initial Catalog=Northwind;..."cnSql.Open()...cnSql.Close()

Verbundene Objekte

Zu diesen zählen die oben angegebenen Basisklassen Connection, Command, DataRea-der, Parameter und Transaction (Abschnitt 3.4). Das Connection-Objekt bietet die Ver-bindung zum Datenspeicher, über die andere verbundene Objekte mit dem Datenspei-cher kommunizieren können. Mit dem Command-Objekt ist es möglich, Anfragen andie Datenbank zu stellen, gespeicherte Prozeduren aufzurufen oder direkte Abfragen zuübermitteln. Dazu ist es nötig, die Connection-Eigenschaft des Command-Objekts aufein zuvor instanziiertes Connection-Objekt zu setzen und die CommandText-Eigenschaftmit der gewünschten Abfrage in SQL (Bsp.: SELECT id, name FROM table1;) zu set-zen. Es ist auch möglich, nur den Tabellennamen in der CommandText-Eigenschaft an-

Abbildung 3.4: Verbundene- und Unverbundene ADO-Objekte [Sce02]


zugeben, was dazu führt, dass die gesamte Tabelle als Ergebnis übergeben wird. DasDataReader-Objekt bietet eine ressourcenschonende und schnelle Möglichkeit Abfrage-ergebnisse zeilenweise abzuarbeiten. Es stellt einen sequenziellen und schreibgeschütztenDatenstrom dar. Um eine Reihe von Änderungen an einer Datenbank zusammenfassendpropagieren zu können, existiert das Transaction-Objekt. Ist es erwünscht Abfragen zuformulieren, die auf einen bestimmten Datensatz prüfen, kann man Parameter-Objektenutzen. Beispielsweise könnte eine Anfrage nach einer Person mit der Id 14, die im nor-malen Gebrauch als SELECT * FROM table1 WHERE id=14 formuliert würde, nun formuliert werdenals SELECT * FROM table1 WHERE id=? . Dies führt bei komplizierteren Anfragen weg vom unüber-sichtlichen Zusammensetzten. Das DataAdapter-Objekt fungiert mit den �ll - und upda-te-Methoden als eine Brücke zwischen der Datenbank und den unverbundenen Objekten.

Unverbundene Objekte

ADO.NET bietet die �unverbundenen Objekte�, um Ergebnisse von Abfragen durch-suchen, sortieren oder ändern zu können. Zu diesen zählen DataTable-, DataColumn-, Constraint-, DataRow-, DataSet-, DataRelation- und DataView-Objekt. Es ist mög-lich das Ergebnis einer Anfrage in einem DataTable-Objekt zu speichern, indem dasDataTable-Objekt der �ll -Methode des DataAdapter-Objektes übergeben wird:

Dim strSQL As String = "SELECT * FROM table1"

Dim strConn As String = "Provider=SQLOLEDB;Data Source=(local);..."

Dim daTable1 As NewOleDbDataAdapter(strSQL, strConn)

Dim tblTable1 As NewDataTable()

daTable1.Fill(tblTable1)

Auf diese Weise werden Daten aus der Datenbank in den internen Speicher geholt undkönnen dort verarbeitet werden. Das DataColumn-Objekt ist in jeder DataTable mehrfachenthalten (für jede Spalte einmal). Es enthält keine Daten aus der DataTable, sondernInformationen über die Struktur der Spalten (Metadaten). Ein DataTable kann auch eineReihe von Constraint-Objekten haben, in denen Integritätsregeln de�niert werden. Eineinfaches Beispiel hierfür wäre, dass nur eindeutige Inhalte in einer Spalte zugelassen wer-den. Um auf die Daten zugreifen zu können, bietet ADO.NET in einem DataTable-Objekteine Liste mit DataRow-Objekten. Diese besitzt eine Eigenschaft item, über die es möglichist, auf einzelne Spalten der Datenzeile zuzugreifen. Da item die Standardeigenschaft vonDataRow ist, kann sie implizit genutzt werden:

Dim rowAs DataRow

row= MyTable.Rows(0)

Console.WriteLine(row(0))

Console.WriteLine(row("CustomerID"))

Console.WriteLine(row(MyTable.Columns("CustomerID")))

Für Änderungen an Daten ist auch das DataRow-Objekt u.a. mit den MethodenBeginEdit, EndEdit und CancelEdit zuständig. Das DataSet-Objekt ist ein Containerfür verschiedene DataTable-Objekte, die zusammengehören. Um nicht den gesamten Da-tensatz bei Änderungen zwischen Datenbank und Anwendung transferieren zu müssen,

3.2 .NET 33

bietet das DataSet-Objekt Methoden an, die nur Änderungen heraus�ltern und wei-ter geben. Mit dem DataRelations-Objekt werden Beziehungen zwischen verschiedenenDataTable-Objekten angegeben. Dadurch wird es möglich, über die GetChilds-Methodedes DataRow-Objekts auf die Verknüpften DataRows zuzugreifen. Das DataRelations-Objekt ermöglicht es auch, Verknüpfungen zwischen DataTable-Objekten anzugeben, dieÄnderungen an dem übergeordneten DataTable weitergeben an die untergeordneten. Fer-ner ist es möglich, wenn ein DataRow im übergeordneten DataTable gelöscht wird, diedamit verknüpften DataRows in der untergeordneten DataTable mitzulöschen. Mit demDataView-Objekt kann, analog zu den Sichten wie sie im Kapitel Datenbanken erläutertwurden, eine Sicht auf DataTable-Objekte de�niert werden.

3.2.3 GDI+

Eine weitere Bibliothek ist �Graphics Device Interface +� derer sich Visual Basic bedient,um Fenster, Tasten, Auswahlboxen, usw. anzeigen zu lassen. GDI+ stellt eine Schnittstel-le dar, die eine Interaktion von Anwendungen mit gra�kfähigen Geräten wie Bildschirm,Drucker und Ähnlichem erlaubt, um menschenlesbare gra�sche Ausgaben zu erzeugen.Mit Hilfe der GDI+ ist es nicht erforderlich, für jede Hardware separat Code zu erzeugen.Die Basisklasse von GDI+ ist Graphics, die Methoden und Eigenschaften zum Zeichnenund Befüllen von Gra�kobjekten bietet. Zu den Zeichenmethoden gehören u.a. DrawEl-lipse, DrawImage, DrawLines und DrawPolygon. Um Gra�kobjekte mit diesen Methodenzeichnen zu können, werden Pens oder Brushes benötigt. Pens dienen zum Zeichnen vonLinien und Umrissen. Brushes hingegen de�nieren die Füllfarbe bzw. das Füllmuster fürGra�kobjekte. GDI+ bietet fünf verschiedene Brushes an (siehe Abbildung 3.5), von de-nen in dieser Diplomarbeit zwei genutzt werden: SolidBrush und TextureBrush.3

SolidBrush kann genutzt werden, um Flächen, die u.a. mit DrawEllipse oder Draw-Polygon gezeichnet wurden, mit einer Farbe zu füllen. TextureBrush erlaubt es, ein Bild(Bitmap) als Brush zu nutzen und Gra�kobjekte damit zu füllen. Pens haben einige Ei-genschaften mehr als Brushes. Sie befähigen Linien zu zeichnen, die u.a. eine bestimmteBreite und Art haben. Ihrem Anfang und Ende kann unterschiedliches Aussehen verliehenwerden.

Pens können auch aus einem Brush-Objekt erstellt werden. Somit können Linien ge-zeichnet werden, die die gleiche Farbe oder Textur haben wie das Brush-Objekt selber.

' erstelle Brush aus einem Bitmap

Dim myImg as Image = new Bitmap("roses.jpg")

Dim myTxtrBrush as TextureBrush = new TextureBrush(myImg)

' erstelle Pen aus Brush

Dim myPen as Pen = new Pen(myTxtrBrush, 20)

3Inhalte dieses Kapitels entstammen aus [Cha03]


Abbildung 3.5: GDI+ Brushes [Cha03]

Abbildung 3.6: GDI+ Linienarten [Cha03]

3.2 .NET 35

Die Art einer Linie, die durch ein Pen gezeichnet werden soll, wird in GDI+ durchu.a. folgende vier Eigenschaften de�niert: DashStyle, DashCap, StartCap und EndCap.Mit DashStyle wird festgelegt, ob eine Linie gezeichnet werden soll, die durchgehend,gestrichelt, gepunktet oder eine Kombination aus diesen ist. Hierzu stehen in GDI+ alsWerte die Konstanten Solid, Dash, Dot, DashDot und DashDotDot zur Verfügung. Mitden Werten Flat, Round und Triangle für die Eigenschaft DashCap besteht die Möglich-keit, die Punkt- und Strichenden gerade, abgerundet oder spitz darzustellen. Der Anfangund das Ende einer Linie kann durch das voneinander unabhängige Setzen der Eigenschaf-ten StartCap und EndCap modi�ziert werden, für die auch eine Reihe von Konstantenals Werte zur Verfügung stehen.

Zum Zeichnen der in Kapitel 2.2.1 erläuterten Geoobjekte, die reduziert werden könnenauf Punkt, Linie und Fläche, bietet GDI+ die bereits erwähnten Methoden DrawEllipse,DrawImage, DrawLines und DrawPolygon. Die ersten beiden dienen zur Darstellung vonPunktobjekten und DrawLines zur Darstellung aller Geoobjekte, die linienhaft dargestelltwerden können. Zur Darstellung �ächenhafter Gebilde wie beispielsweise Landesgrenzenoder Grün�ächen kann DrawPolygon genutzt werden.

Kapitel 4

Entwurf - Methodologie - Konzept

In diesem Kapitel wird eine kurze Problembeschreibung der Generierung von Bildschirm-karten auf herkömmliche Art formuliert, um das zu entwerfende System genauer spezi-�zieren zu können. Es werden Überlegungen erläutert, die von einer bisher spezi�schenKartengenerierung zu einer generischen Kartengenerierung führen. Dazu wird ein Beispieleingeführt, mit dessen Hilfe mögliche Teilprobleme identi�ziert werden. Bei Bedarf wirddas Beispiel sukzessiv ausgebaut und weiter ausdiskutiert. Die Diskussionen umfassenDarstellungen von Geoobjekten auf Bildschirmkarten und das Layout mit Möglichkeitender Interaktion für diese Bildschirmkarten. Im weiteren Verlauf kristallisiert sich heraus,dass das Hauptproblem von einer spezi�schen zu einer generischen Kartengenerierung inder Zuordnung von Darstellungsform oder -art zu Geoobjekten liegt. Hierfür wird eineRegelsprache de�niert und ein Konzept für die Implementierung erarbeitet.

4.1 Generische Visualisierung von 2D-Geoobjekten

Bei der herkömmlichen Generierung von Bildschirmkarten ist im Programmcode festge-legt, wie Geoobjekte auf Bildschirmkarten dargestellt werden sollen. Bevor ein Kartenge-nerator für diese Programme erstellt wird, muss feststehen, welche Geodaten auf welcheWeise darzustellen sind und wie ihre Struktur in der Datenbank aussieht. Wie bei derErstellung von analogen Karten, muss ein Kartenautor � noch bevor der Kartengeneratorerstellt wird � bestimmen, welche Klassen von Geoobjekten dargestellt werden sollen undwie diese auszusehen haben. Oft bieten solche Programme die Möglichkeit einige Darstel-lungsvariablen (Farbe, Muster, ...) zu ändern, jedoch sind diese Möglichkeiten begrenzt.Es ist also für jede neue Anwendung ein neuer Kartengenerator zu programmieren, dessenFunktionsweise zuvor festgelegt werden muss. Bei nachträglichen Änderungen an der Da-tenstruktur der darzustellenden Geoobjekte oder ihrer Darstellungsform, ist ein Eingri�in den Quellcode der jeweiligen Anwendung unvermeidlich.

Ziel dieser Arbeit ist, um den Titel aufzunehmen, der Entwurf und die Implementie-rung eines generischen 2D-Kartengenerators basierend auf relationalen Geodatenbanken,d.h. dass ein Kartengenerator zu entwickeln ist, der beliebige Geoobjekte aus der Rea-lität, die beliebig modelliert als Geodaten in einer Geodatenbank vorliegen, auf einerinteraktiven Bildschirmkarte als graphische Objekte darstellt. Dem letzten Absatz ist zuentnehmen, dass bisherige GIS-Anwendungen die Zuordnung zwischen Geoobjekten und

36

4.1 Generische Visualisierung von 2D-Geoobjekten 37

ihrer graphischen Darstellungsform statisch im Quellcode der Anwendung implementie-ren. Dies soll durch eine dynamische Zuordnung ersetzt werden, die dem zu entwickelndenSystem einen hohen Grad an Flexibilität verleiht. Dadurch entsteht ein universaler undsomit anwendungsunabhängiger Kartengenerator, der die Zusammenarbeit des Karten-autors mit dem Programmierer einer Anwendung über�üssig macht. Es stellt viel mehrein Werkzeug für Kartenautoren dar, die in die Lage versetzt werden die Darstellung derGeoobjekte im nachhinein durch Parameter zu bestimmen. Spätere Änderungswünschewie die Wahl der darzustellenden Geoobjekte oder die Art ihrer Darstellung sind durchein solches System komfortabel umzusetzen. Es ist dann lediglich nötig, die Zuordnung,die im folgenden Visualisierungs-Mapping genannt werden soll, zu überarbeiten.

Als Name für das neue System wurdeMapGENeric als passend empfunden, der sichaus den englischen Wörtern mapgenerator für Kartengenerator und generic für generischzusammensetzt. Der gemeinsame mittlere Teil des Namens kann auch alleine abkürzendfür Generator stehen, weshalb er in Groÿbuchstaben gehalten wird.

MapGENeric gewährleistet über ein DBMS Zugri� auf eine beliebige relationale Geo-datenbank. Zu den Geodaten in dieser Datenbank ist es möglich, ein Visualisierungs-Mapping zu de�nieren, anhand dessen das System dann eine interaktive Bildschirmkarteerstellt und über ein GUI anzeigt. Beliebige Geodatenbank soll ausdrücken, dass das Sche-ma der zu visualisierenden Datenbank beliebig sein darf. Das DBMS ist mit MicrosoftTM

Access vorgegeben.

Abbildung 4.1: MapGENeric

Um ein System wie MapGENeric zu entwerfen, muss zuerst festgelegt werden, welcheTypen von Geoobjekten existieren und welche das System darstellen können sollte. Dazuwird ein Beispiel eingeführt, das im Verlauf des Kapitels mit den auftretenden Teilproble-men wachsen wird. Ferner soll diskutiert werden, welche der in Abbildung 2.14 gezeigtenDarstellungsvariablen zur Darstellung dieser Geoobjekte implementiert werden müssen.Danach wird nach einer Möglichkeit gesucht, das dynamische Visualisierungs-Mapping zuverwirklichen.

38 Kapitel 4. Entwurf - Methodologie - Konzept

Im Grundlagenteil ist gezeigt worden, dass Geoobjekte der Realität durch Abstraktionmodelliert werden können als punkt-, linien- und �ächenförmige Basisobjekte. Als solchewerden sie auch auf Bildschirmkarten dargestellt. Es ist auch zu bedenken, dass Geoobjek-te eines bestimmten Typs mit unterschiedlichen Basisobjekten dargestellt werden können.Beispielsweise können Städte, die in der realen Welt eine �ächenhafte Ausbreitung haben,auf Bildschirmkarten entweder als �ächenförmige oder aber als punktförmige Abstrak-tionen dargestellt werden. Auch hier bietet es sich an, die Entscheidung, durch welchesBasisobjekt ein Geoobjekt repräsentiert werden soll, in das Visualisierungs-Mapping auf-zunehmen, so dass es einem späteren Nutzer von MapGENeric möglich ist, dies je nachNutzerkreis der Bildschirmkarte bzw. Art der vorliegenden Daten anzupassen.

4.1.1 Beispiel - Touristik/Umwelt

In diesem Beispiel wird von je einem Repräsentanten zweier Nutzerkreise ausgegangen,einem Touristen und einem Umweltbeauftragten. Der Tourist ist in der Regel interes-siert an verschiedenen Sehenswürdigkeiten und daran, wie diese erreicht werden können.Dabei können von verschiedenen Touristen unterschiedliche Geoobjekte als Sehenswür-digkeit aufgefasst werden. Für den Einen können kulturelle Aspekte eine Rolle spielen,so dass er sich beispielsweise für Museen, Opern und alte Gebäude interessieren wird.Für einen Anderen können Einkaufs- und sonstige Freizeitaktivitäten interessant sein. DaTouristen in der jeweiligen Stadt fremd sind, könnten sie auch Übernachtungsmöglichkei-ten und Restaurants interessieren (siehe Abbildung 4.2). Der Umweltbeauftragte hingegenwird sich eher für lokale Umweltbelastungen, wie spezielle Luftverschmutzungen (unterAnderen Feinstaubbelastung, CO2-Konzentration oder Pollenbelastung) und Wasserver-schmutzungen interessieren (siehe Abbildung 4.3). Um auch eventuelle Ursachen für dieseUmweltbelastungen aus�ndig machen zu können, sind sicherlich vertiefende Informationenzu den Gebäuden, Stadtteilen oder sogar für einzelne Straÿen, wie Bewohnerzahl, Nut-zungsart (gewerblich oder privat), Verkehrsdichte, Verkehrsampeln und Ähnliches, vonhohem Interesse.

Ein weiteres Szenario, in dem zwischen zwei unterschiedlichen Touristen-Kategoriendi�erenziert werden würde, ist auch denkbar. Dies könnten Touristen mit Pkw und Tou-risten ohne Pkw sein, wodurch auf Basis der selben Daten für Abbildung 4.2 zwei unter-schiedliche Karten gezeichnet werden müssten. Denn es ist notwendig für Touristen mitPkw, Straÿen kenntlich zu machen, die ausschlieÿlich für Fuÿgänger reserviert sind, wiein Abbildung 4.4 durch rot gepunktete Linien dargestellt.

Eine Geodatenbank, die diesen Karten (Abbildungen 4.2 und 4.3) zugrundeliegt, kannbeispielsweise wie in den folgenden Tabellen aussehen. Um Geoobjekte darstellen zu kön-nen, müssen Koordinaten zu ihren Geometrien vorhanden sein. Diese Koordinaten werdenin der Regel in einer separaten Relation gehalten, wie sie beispielhaft in Tabelle 4.1 zusehen ist.

Eine Orientierung für beide Nutzerkreise sind erstrangig Straÿen, dann evtl. Flüsseund andere Objekte wie Grün�ächen oder Gebäude. Straÿen können mit zwei und mehrKoordinaten dargestellt werden, weshalb ihre Koordinaten in der Regel in einer solchen


Abbildung 4.2: Beispielkarte für Touristen

Abbildung 4.3: Beispielkarte für Umweltbeauftragte


Abbildung 4.4: Beispielkarte II für Touristen

Relation (Tabelle 4.1) gehalten werden. Die Welschnonnenstr. in Tabelle 4.2 ist modelliertmit zwei Koordinaten, wie in der Beziehungsrelation Tabelle 4.3 zu sehen ist. Die Bel-derbergstr. hingegen ist mit drei Koordinaten erfasst, weil sie beispielsweise einen Knickaufweist. Weitere Informationen zu den Straÿen, wie Anzahl der Fahrspuren, Höchstge-schwindigkeit oder das Vorhandensein von Ampeln wird für den Touristen evtl. nicht in-teressant sein, aber der Umweltbeauftragte könnte mit diesen Informationen, den Ein�ussauf die Umweltbelastung sehen. Es ist auch vorstellbar, dass sogar Straÿen in gewissenNutzerkreisen (Katasteramt) �ächenhaft modelliert sein müssen.

Auch Flüsse die dem Touristen vielleicht lediglich zur Orientierung dienen, könntenfür den Umweltbeauftragten weitere Interessante Informationen bedeuten. Dabei könnensie, wie in Tabelle 4.4 und 4.5 dargestellt, als linienhafte Geoobjekte modelliert wordensein oder aber auch als �ächenhafte Geoobjekte.

id laengengrad breitengrad position1 7,10959 50,74132 12 7,11121 50,73531 23 7,11380 50,73148 14 7,09636 50,73697 15 7,10319 50,73797 26 7,11431 50,73878 3: : : :

Tabelle 4.1: Koordinaten


id name anzahl_spuren max_speed ampel1 Welschnonnenstr. 4 50 ja2 Belderbergstr. 2 50 nein: : : : :

Tabelle 4.2: Straÿen

strassen_id koord_id1 11 22 42 52 6: :

Tabelle 4.3: StraÿenKoordinaten

id name befahrungen min_tiefe max_tiefe1 Rhein 10000 4 92 Sieg 0 0,5 2: : : : :

Tabelle 4.4: Fluesse

�uss_id koord_id1 141 151 19: :

Tabelle 4.5: FlussKoordinaten


id name kapazitaet anzahl_linien breitengrad laengengrad1 Chlodwigplatz 500 3 7,10616 50,740442 Eifelstraÿe 400 1 7,10247 50,73996: : : : : :

Tabelle 4.6: Straÿenbahnhaltestellen

id haltestelle_id1 haltestelle_id2 max_speed1 1 2 502 2 3 70: : : :

Tabelle 4.7: Straÿenbahnteilstrecke

Eine dritte linienhafte Darstellung bietet sich an bei Straÿenbahnnetzen, wie sie in denBeispielkarten durch eine feine blaue Linie mit gleichfarbigen Punkten darauf zu erkennenist. Die Punkte repräsentieren dabei Haltestellen der Straÿenbahn. Hier ist eine weitereMöglichkeit der Modellierung naheliegend, wie anhand der Relationen in Tabelle 4.6 und4.7 zu sehen ist.

Gebäude wie z.B. Museen oder Hotels werden in der Regel als punktförmige Geoob-jekte modelliert, jedoch können sie auch mit ihren Umrisskoordinaten erfasst vorliegen,wie in diesem Beispiel die Museen (Tabellen 4.8 und 4.9). Bei punktförmiger Erfassungwerden sie oft, wie in Tabelle 4.10 zu sehen ist, mit ihren Geometrie- und Thematikdatengemeinsam modelliert. Umweltverschmutzungen werden punktuell erfasst aber �ächen-förmig gespeichert und dargestellt, da die erfassenden Sensoren einen gewissen Radiusabdecken.

4.2 Visualisierung in MapGENeric

Im Grundlagen-Abschnitt 2.2.3 wurde festgestellt, dass zur Darstellung von geographi-schen Objekten auf zweidimensionalen Ebenen diese reduziert werden können auf dieBasisobjekte Punkt, Linie und Fläche. Im oben genannten Beispiel wurden darzustel-lende bzw. darstellbare Geoobjekte identi�ziert. Bedacht werden sollte dabei, dass einGeoobjekt je nach Darstellungsziel, Maÿstab und Erfassung bzw. Modellierung in derDatenbank unterschiedlich gespeichert sein kann. Wie dem Beispiel zu entnehmen ist,können interessante Gebäude in einem Stadtplan für Touristen punktförmig dargestelltwerden (Tabelle 4.10) oder aber mit ihren realen Umrisskoordinaten �ächenhaft (Tabelle4.8). Flächenhaft können sie nur dargestellt werden, wenn sie auch als solche erfasst in

id name zeitalter ausstellung1 Römisch-Germanisches Museum Antike Roma di Cesar2 Auto und Technik Museum 19./20. Jahrhundert �: : : :

Tabelle 4.8: Museen

4.2 Visualisierung in MapGENeric 43

museum_id koord_id1 151 161 171 18: :

Tabelle 4.9: MuseumKoordinaten

id name anzahl_zimmer preis laengengrad breitengrad1 Maritim 159 100 7,09948 50,739572 Luxor 248 199 7,10554 50,73870: : : : : :

Tabelle 4.10: Hotel

id art verschmutzungsgrad lufttemperatur luftfeuchtigkeit1 CO2-Konzentration 70 22◦C 52%2 Pollenbelastung 60 23◦C 50%: : : : :

Tabelle 4.11: Umweltbelastungen

umweltbelastung_id koord_id1 101 111 12: :

Tabelle 4.12: Verschmutzungskoordinaten


der Datenbank vorliegen. Punktförmig können sie in beiden Erfassungsformen dargestelltwerden, da für die Darstellung von Punkten ein Koordinatenpaar ausreicht und bei mehre-ren, wie sie bei �ächenhafter Erfassung vorliegen würden, eins von diesen gewählt werdenkann. Anhand beispielhaft identi�zierter Geoobjekte wurde hier die Erfordernis für einSystem deutlich, das alle Geoobjekte der drei Basisklassen darstellen können muss.

4.2.1 Darstellung von Geoobjekten

Um Geoobjekte aus der realen Welt auf Bildschirmkarten abbilden zu können, müssen die-se durch visuelle Objekte repräsentiert werden. Zur Gestaltung dieser visuellen Objekteunterscheidet Bertin sechs Variablen (siehe Abbildung 2.14), die durch das zu entwerfendeSystem auch bereitgestellt werden sollten. Die Relevanz der jeweiligen Darstellungsvaria-blen soll im folgenden diskutiert werden, um die Notwendigkeit für die spätere Implemen-tierung festzustellen. Dabei wird die Notwendigkeit jeder Darstellungsvariable an allendrei Basisklassen für Geoobjekte diskutiert. Da der Schwerpunkt dieser Arbeit nicht aufder Visualisierung an sich liegt, sondern vielmehr darin, Geodaten unabhängig von ih-rem Schema durch den selben Kartengenerator zu visualisieren, wird von einer intensivenDiskussion Abstand gehalten und nahe liegende Lösungen für die Visualisierung gewählt.Ferner soll am Ende jeder Diskussion eine Entscheidung für das Konzept und somit fürdie spätere Implementierung fallen.

Farbe

Viele Geoobjekte assoziiert man mit einer bestimmten Farbe, weil diese auch in der Natureine ähnliche Farbe aufweisen oder in der Kartographie standardmäÿig so gezeichnet wer-den. Gewässer werden beispielsweise mit blauen Farbtönen dargestellt, Grün�ächen allerArt mit unterschiedlichen Grüntönen und Gebirge in Brauntönen. Der geläu�gste Far-braum für Bildschirmkarten ist der RGB-Farbraum, weil Monitore in der Regel technischmit dem selben Farbraum angesprochen werden. Der RGB-Farbraum wird de�niert durchje einen Wert zwischen 0 und 255 für die Farben rot, grün und blau. Durch das Mischendieser Farben entsteht ein Farbraum mit 16,7 Mio. Farben, der auch im zu entwickelndenSystem zum Einsatz kommen sollte.

Durch die Hinzunahme eines weiteren Wertes � dem Alpha-Kanal � ist es möglicheinen Transparenzgrad, für die auf diese Weise de�nierten Farben, festzulegen. Die Trans-parenz ermöglicht es, sich evtl. verdeckende Objekte bis zu einem gewissen Grad trotzdemzu erkennen. Dies hat bei der Darstellung für den Umweltbeauftragten aus dem Beispielden Vorteil, dass �ächenhaft darzustellende Luftverschmutzungen über Geoobjekte gelegtwerden können und trotzdem darunter liegenden Objekte erkennbar bleiben. Der Vorteilist deutlich in der Abbildung 4.3 zu sehen. Die Eigenschaft der Farbe in Kombinationmit der Transparenz sollte deshalb für die Darstellung aller Geoobjekte mit allen dreiBasisklassen zur Verfügung gestellt werden.

Alternative Farbräume existieren mit CMYK-, HSB- und YUV-Farbräumen, jedochkönnen diese nicht als echte Alternativen für Bildschirmkartendarstellungen angesehenwerden. Wie zuvor erwähnt werden Bildschirme aller Art (u.a. CRT � Röhrenmonitore


� oder TFT � Flüssigkristallmonitore �) mit Werten für rot, grün und blau angesteuert,weshalb eine komplizierte Umrechnung aus einem der oben genannten Farbräume nötigwäre. Auÿerdem sind einige dieser alternativen Farbräume kleiner, d.h. es können wenigerFarben dargestellt werden.

Gröÿe

Für jede der Basisklassen hat die Gröÿe eine andere Relevanz und sollte deswegen unter-schiedlich behandelt werden. Bei punktförmigen Objekten, die durch Symbole repräsenta-tiv dargestellt werden (siehe beispielsweise Hotels, Museen und Restaurants in Abbildung4.2), ist eine Gröÿenangabe in zwei Dimensionen denkbar und naheliegend. Diese sindHöhe und Breite, die die Gröÿe der darstellenden Symbole in Pixeln angeben. Für linien-förmige Objekte, wie Straÿen und Flüsse in den Beispielkarten, hingegen wird die Längedurch ihre Anfangs- und Endpunkte de�niert, wodurch nur die Linienbreite als ausschlag-gebende Darstellungsvariable zu betrachten ist. Bei �ächenförmigen Geoobjekten wirddie Gröÿe ausschlieÿlich durch ihre Begrenzungspunkte de�niert, weshalb eine separateAngabe der Gröÿe vernachlässigt werden kann.

Form - Shape

Je nach Generalisierungsgrad der Darstellung können beispielsweise Städte, Straÿenkreu-zungen oder Bäume repräsentiert werden durch punktförmige Geoobjekte. In erster Linieist für ein Punktobjekt die Form ausschlaggebend. Die Form wird in vielen Karten (bei-spielsweise Stadtplänen) genutzt, um allgemein bekannte Objekte wie Sehenswürdigkeitendurch Symbole darzustellen. Hierzu werden Symbole benutzt, die eine direkte Assoziati-on mit den Realweltobjekten erlauben, wie ein rotes Kreuz für Krankenhäuser oder eineminiaturisierte Kirche für die reale Kirche. Bitmaps haben eine rechteckige Form, in dersie nur bedingt geeignet wären für die gewünschte Darstellung. Jedoch können Bereicheeines Bitmaps transparent de�niert werden, so dass jede erdenkliche Form simuliert wer-den kann. Dadurch werden sie wiederum in dieser Arbeit als bestens geeignet empfundenund in das Konzept aufgenommen.

Im vorliegenden Beispiel werden unterschiedliche Symbole benötigt. Auf der Karte inAbbildung 4.2 für den Touristen sind u.a. Sehenswürdigkeiten, Übernachtungsmöglich-keiten und Restaurants auf Anhieb erkennbar. So sollte die Darstellung solcher Objektedurch Bitmaps, wie sie auf dieser Karte zu sehen sind, ermöglicht werden, da diese jedeerdenkliche Form darstellen können. Im Touristik/Umwelt-Beispiel sind wiederkehren-de punktförmige Objekte wie Straÿenbahnhaltestellen dargestellt durch hellblaue Kreise.Diese Kreise wurden eingesetzt, weil durch Bitmaps dargestellte Symbole in dieser Anzahlüberfrachtend wirken könnten. Aus diesem Grund sollten vorde�nierte Formen (beispiels-weise Ellipse, Drei- und Rechteck) existieren. Eine solche Maÿnahme würde ferner dieGeschwindigkeit beim Aufbau der Karte erhöhen, da die zeitraubenden Zugri�e auf dasSpeichermedium entfallen auf dem die jeweilige Bitmapdatei liegt. Eine weitere Mög-lichkeit für die Darstellung der Form von punktförmigen Geoobjekten wäre eine eigene


Symbolsprache. Eine solche Sprache hätte den Vorteil, dass sie erlauben würde vektorori-entiert Formen zu de�nieren, die Beispielsweise beim Vergröÿern des Kartenausschnittsmitwachsen könnte. Da diese Überlegungen den zeitlichen Rahmen dieser Arbeit sprengenwürden, wird auf eine weitere Diskussionen verzichtet.

Die Form eines linienförmigen Objektes kann unterschiedlich aufgefasst werden. Indieser Arbeit wird sie de�niert als die Darstellung der Elementenden eines linienförmigenObjektes, wobei diese Enden angelehnt an die vorde�nierten Formen für die Darstellungpunktförmiger Objekte, �ach, abgerundet oder spitz sein sollten. Wie auch die Gröÿeeines �ächenförmigen Objektes wird die Form durch seine Begrenzungspunkte de�niertund bedarf deshalb keiner expliziten Betrachtung.

Muster - Textur

Durch die Entscheidung in Abschnitt �Form-Shape� Bitmaps für die Darstellung von punt-förmigen Objekten einzusetzen, wird auch dieser Darstellungsvariable Genüge getan. DennBitmaps können jede erdenkliche Form annehmen, wie zuvor zu lesen war. Ferner könnendiesen Formen durch Bildbearbeitungsprogramme (AdobeTM Photoshop, u.a.) beliebigeMuster aufgetragen werden, weshalb in dieser Arbeit eine separate Konzeption vernach-lässigt wird.

Als Muster für Linien werden zwischen durchgehenden, gestrichelten, gepunkteten undKombinationen aus den letzten beiden unterschieden. In den Beispielkarten in Abbildung4.2 und 4.3 ist eine solche gestrichelte Linie zu erkennen, die eine Eisenbahnstrecke dar-stellt.

Die wohl wichtigste Eigenschaft für die Darstellung einer Fläche in Karten ist nach derForm das Muster. Erst durch diese Eigenschaft wird in den gängigen Karten klar, was fürein Geoobjekt die sichtbare Fläche darstellt. Für den Umweltbeauftragten ist es wichtig,wie sich z.B. unterschiedliche Wälder (Laub- oder Nadelwälder) auf Luftverschmutzun-gen auswirken. Eine Darstellung, wie sie auf der Karte in Abbildung 4.3 zu sehen ist,wäre durchaus wünschenswert. Da die Menge an darstellbaren �ächenhaften Geoobjektenunendlich erscheint, ist hier eine entsprechende Umsetzung, die dem genügt, notwendig.Eine solche Möglichkeit für unterschiedliche Muster bieten ebenfalls Bitmaps, weshalb siein MapGENeric für die Füllung �ächenhafter Geoobjekte bereitgestellt werden. Dadurchist eine vielfältige Darstellung von Flächen gewährleistet.

Richtung

Auch der Eigenschaft Richtung wird bei der Darstellung von Punkten durch die Möglich-keit der Nutzung von Bitmaps genüge getan. In der Beispielkarte für Touristen (Abbildung4.3) sind beispielsweise Aussichtspunkte dargestellt durch das Symbol in Abbildung 4.6,die dem Nutzer eine schöne Aussicht in östlicher Richtung verspricht. Das Symbol in Ab-bildung 4.5 hingegen würde auf eine Aussicht im Westen hinweisen. Auf diese Weise sindfür punktförmige Geoobjekte die Darstellung ihrer Richtung möglich.


Abbildung 4.5:Aussichtspunkt nach Westen

Abbildung 4.6:Aussichtspunkt nach Osten

Um beispielsweise die Flieÿrichtung eines Flusses zu visualisieren oder Einbahnstraÿenkenntlich zu machen, ist bei Linien die Darstellung einer Richtung unerlässlich. Durch einePfeilspitze am Ende jeder Linie kann eine solche Darstellung erreicht werden, wie einigeEinbahnstraÿen in den Beispielkarten dargestellt sind. Zur Darstellung von Sackgassen,die unterteilt werden können in Sackgassen mit und ohne Wendemöglichkeit, sind Kreiseund Rechtecke an den Linienenden vorstellbar. Die Ausbreitungsrichtung von �ächenhaf-ten Geoobjekten wird durch ihre Begrenzungspunkte de�niert, somit ist eine expliziteBetrachtung nicht notwendig.

Helligkeit

Bei Geoobjekten, die unterschiedliche Höhen bzw. Tiefen aufweisen, bedient man sichunterschiedlichen Helligkeitsstufen. Dabei werden höhere Teile eines Berges beispielsweiseheller dargestellt als tiefer liegende Teile. Diese Eigenschaft ist somit für die Darstellungvon Höhenunterschieden unerlässlich. Ein weiteres Beispiel ist die Besiedlungsdichte vonStadtteilen: Je heller ein Stadtteil dargestellt wird umso geringer die Dichte. Durch dieWahl eines geeigneten Farbraumes, wie bei der Darstellungsvariable Farbe zuvor gesche-hen, kann auf eine explizite Betrachtung dieser Darstellungsvariable verzichtet werden.Durch das Mischen der drei Farbwerte für Rot, Grün und Blau ist es möglich, verschie-dene Abstufungen von Farbtönen zu erzielen.

Ein weiterer wichtiger Punkt, der bedacht werden sollte bei der Darstellung von Geo-objekten, ist die Reihenfolge in der Geoobjekte gezeichnet werden. Diese Reihenfolgeverhindert unerwünschte Überdeckungen. Andererseits kann es eingesetzt werden, um er-wünschte Überdeckungen zu erzeugen, wie in obigen Beispielkarten die rot dargestelltenLinien. Sie repräsentieren Autobahnen, wie sie in vielen Ländern üblich sind. Die Straÿen,die weiÿ und gelb dargestellt sind, verlaufen unter der Autobahn.

4.2.2 Bildschirmkarte

Der Aufbau einer analogen Karte ist abhängig vom Nutzerkreis und Darstellungsziel, soauch bei Bildschirmkarten. Wie in Abschnitt 2.2.3 zu lesen ist, kommen bei Bildschirm-karten Kontroll- und Steuerungsmechanismen hinzu. Um ein möglichst groÿen Nutzerkreisansprechen zu können, sollten selbsterklärende Elemente für den Kartenaufbau und ihreInteraktionen zur Verfügung stehen. Nutzer von Bildschirmkarten erwarten eine Verbes-serung und Erweiterung der Informationen, die eine analoge Karte bietet. Deshalb dürfendie bekannten Grundelemente einer Karte wie Titel, Maÿstabund Kartenausschnitt nichtfehlen, da dies die Verringerung von Informationen bedeuten würde. Nicht alle Informa-tionen zu Geoobjekten können wie ihre Gestaltrepräsentation auf einer Bildschirmkartedirekt dargestellt werden. Es werden in Geodatenbanken oft zusätzliche Informationen zu


Geoobjekten abgelegt, die bei Bedarf angezeigt werden sollten. D.h. eine Interaktion mitdem Benutzer ist zwingend erforderlich, wodurch verschiedene Kontroll- und Steuerungs-mechanismen hinzukommen, die zusätzlichen Platz auf dem Bildschirm beanspruchen.

Layout

Titel Der Titel einer Karte dient der ersten Orientierung auf einer Karte. Durch ihn wirddem Nutzer deutlich gemacht, welchem Zweck die Karte dient und welchen Ausschnitt ererwarten darf. Ein solcher Titel könnte für die Beispielkarte in Abbildung 4.3 formuliertwerden als �Umweltbelastungen der Stadt X in Abhängigkeit verschiedener Faktoren�,womit dem Nutzer sofort deutlich wird, dass es um Stadt X geht und die Darstellung derUmweltbelastungen in dieser Stadt. Da diese Information einen hohen Gehalt hat, wirdsie in MapGENeric zum Einsatz kommen müssen. In Bildschirmkarten ist es üblich, denTitel in den Rahmen des Fensters zu integrieren, indem die Karte dargestellt bzw. das GUIausgeführt wird. Dies kann bei evtl. PC-unerfahrenen Nutzern der Karte Verwirrungenhervorrufen, weshalb die Darstellung des Titels wie bei analogen Karten direkt über demKartenausschnitt zentriert, dargestellt werden sollte.

Maÿstab Analoge Karten werden in einem bestimmten Maÿstab gezeichnet, der dannauch auf der Karte als Randangabe verzeichnet ist. Der Maÿstab dient in erster Linie dazu,Gröÿen von Geoobjekten und ihre Entfernungen zueinander in Relation zur realen Weltdeutlich zu machen. Dadurch erhält der Nutzer einen Überblick über die Karte und eineVorstellung über Gröÿen auf dieser Karte. Die Darstellung des Maÿstabs wird in dieserArbeit bei Bildschirmkarten als noch wichtiger betrachtet, da durch die Möglichkeiten desZooming (Echtzeit Maÿstabsänderung) der Überblick schnell verloren gehen kann. Map-GENeric sollte aus diesem Grund bei Änderungen am Maÿstab den aktuellen Maÿstabberechnen und dauerhaft einblenden. Der Tourist kann dann beispielsweise abschätzen, obvon seiner aktuellen Standposition aus das nächste Museum zu Fuÿ erreichbar ist oder ober lieber die Straÿenbahn nehmen sollte. Eine Angabe des Maÿstabs in der 1:x Notationkann bei Bildschirmkarten vernachlässigt werden, da dies Abhängig ist von der Gröÿe desBildschirms und dessen Au�ösung bzw. Pixelgröÿe, auf dem die Karte dargestellt wird.Für die Gröÿenabschätzung auf der Karte sollte ein Maÿstab wie in Abbildung 4.2 seinenZweck auch erfüllen. Dieser Maÿstab zeigt wieviel Meter/Kilometer er auf der Karte ein-nimmt.

Wie im Grundlagenabschnitt 2.1.2 dieser Arbeit zu lesen ist, entstehen je nach Wahlder Kartenprojektion und des darzustellenden Ausschnittes Verzerrungen, die dazu füh-ren, dass der eingezeichnete Maÿstab nicht in allen Richtungen treu bleibt. Dadurch wirdaber die Notwendigkeit für ein Maÿstab nicht berührt, da sie trotzdem Nutzern hilft,Überblick über die aktuelle Darstellung zu behalten.

Layerkonzept Eine weitere wichtige Eigenschaft, die in vielen modernen Geo-Infor-mations-Systemen Anwendung �ndet, ist das Layerkonzept. Dabei wird für jede Klassevon Geoobjekten eine eigene Ebene erzeugt, auf der Geoobjekte der jeweiligen Klassegezeichnet werden. Die Karte in Abbildung 4.2 wäre beispielsweise in den meisten GIS-Anwendungen so modelliert, dass Hotels in einer Ebene, Restaurants in einer anderen Ebe-


ne, Sehenswürdigkeiten in einer weiteren Ebene usw. dargestellt würden. Durch separateEbenen entsteht die Möglichkeit, eine komfortable Darstellung zu bieten. Die einzelnenEbenen können in einer Ebenenliste, in der sie durch ihre Namen identi�zierbar sind, ein-und ausgeblendet werden, wodurch dem Nutzer die Möglichkeit gegeben wird, nur die fürseine Bedürfnisse nötigen Geoobjekte anzeigen zu lassen und somit eine spezielle Kartezu erzeugen. Ein Tourist zum Beispiel, der sein Hotel schon gebucht hat, wird sich nichtmehr für andere Hotels interessieren. In einem solchen Fall könnte er Hotels ausblenden,wodurch eine bessere Übersicht für die restlichen Geoobjekte von Interesse erreicht wird.Somit ist dieses Konzept auch in MapGENeric wünschenswert.

Legende Der Wiedererkennungsgrad von Geoobjekten, der durch oben diskutierte Dar-stellungsvariablen und durchgehend gleichbleibender Symbolik erreicht werden kann, isthoch. Durch die Ebenenliste, die im Layerkonzept vorgestellt wurde, ist ein weiteres Ele-ment gegeben, das den Wiedererkennungsgrad der Geoobjekte steigert. Ferner könnenInteraktionsmöglichkeiten, die eine Bildschirmkarte bieten muss, genutzt werden Darstel-lungen von Geoobjekten zu erläutern, so dass in dieser Arbeit auf die Modellierung undImplementierung einer Legende verzichtet werden kann.

Interaktion

Inforetrieval In Geodatenbanken sind meistens mehr Informationen abgelegt als gleich-zeitig auf einer Karte darstellbar. Im Touristik/Umwelt-Beispiel sind zu Hotels ihre Na-men, Anzahl der Zimmer und Preise gespeichert, die nicht nicht auf der Karte dargestelltwerden. In der Regel werden Zusatzinformationen wie diese auf Verlangen des Nutzers erstsichtbar, wozu jedoch eine Interaktion mit dem dargestellten graphischen Objekt nötig ist.Diese Möglichkeit macht unter weiteren den Mehrwert einer Bildschirmkarte aus. Für die-se Art der Interaktion könnte ein Informationsmodus bereitgestellt werden, der zu ausge-wählten graphischen Objekten eine Methode zum Informationsabruf und zur -darstellungzuweist. Zu einem separaten Modus für diese Funktionalität muss zurückgegri�en wer-den, da verschiedene noch zu beschreibende Funktionen der fertigen Anwendung auf demgleichen Ereignis des Mausklicks basieren und deshalb nicht zu unterscheiden wären.

Navigation Eine weitere Interaktion mit der Karte stellt die Navigation auf der Kartedar. Da auf Bildschirmen meistens nur ein Ausschnitt der gesamten Geodaten visualisiertwerden können, wie in Abschnitt 2.2.3 erläutert wurde, ist eine Navigation unerlässlich.Der Ausschnitt in Abbildung 4.2 ist ein sehr kleiner Teil einer Stadt, die sicher mehrTouristische Attraktionen bietet. Die Navigation dient dazu, den Kartenausschnitt in dervom Benutzer gewünschten Richtung zu verschieben. Zur Navigation gibt es verschiedeneLösungen, wie sie folgend vorgestellt werden.

1. Pan-NavigationDabei wird die Karte mit der Maus an einer beliebigen Stelle auf dem sichtbarenKartenausschnitt durch gedrückthalten der Maustaste festgehalten und in die ge-wünschten Richtung gezogen. Diese Navigation kann durch die Vorstellung erläutert


werden, dass eine Karte lose unter einer �xierten Holzplatte liegt, die ein rechtecki-ges Loch hat, wodurch nur ein Ausschnitt der Karte zu sehen ist. Soll ein andererTeil der Karte zu sehen sein, so kann die Karte durch das Loch festgehalten undverschoben werden.

2. RePan-NavigationHierbei handelt es sich um die gleiche Navigationsart wie Pan-Navigation, jedochwird nicht die Karte (hier ist diese �xiert) verschoben, sondern das Holzbrett mitdem Ausschnitt.

3. Zusammengefasste-NavigationstastenEs wird an einem vorde�nierten Platz auf der Arbeits�äche der Anwendung fürjede Himmelsrichtung eine Taste bereitgestellt, die den Ausschnitt in die jeweiligeRichtung verschiebt.

4. Rahmen-NavigationUm das Kartenfenster wird ein schmaler Rahmen zur Navigation eingesetzt, der jenachdem auf welcher Seite oder Ecke des Rahmens angeklickt wird, den Kartenaus-schnitt in diese Richtung bewegt.

Um den E�ekt der ersten beiden Navigationsarten dem Benutzer auch sichtbar machen zukönnen, sollte der Kartenausschnitt in Echtzeit verschoben werden können. Das wiederumwürde bedeuten, dass die Karte dreimal so groÿ wie der aktuelle Ausschnitt immer imSpeicher gezeichnet vorliegen müsste. Bei der dritten Navigationsart liegt der entscheiden-de Nachteil darin, dass eine intuitive Assoziation des Kartenausschnitts mit den Tastennicht so naheliegend ist wie bei der Letzten. Aus diesen Gründen fällt die Entscheidungfür die Rahmen-Navigation, die die Nachteile der drei zuvor genannter Navigationsartennicht hat.

Zooming Das Zooming ist bei der Darstellung von Bildschirmkarten ein sehr wichtigerSteuerungsmechanismus. Es erlaubt den Maÿstab der Karte in Echtzeit zu verändern,wodurch der dargestellte Ausschnitt der realen Welt verkleinert oder vergröÿert wird.In obigem Beispiel ist z.B. denkbar, dass durch herauszoomen der Maÿstab verkleinertwird und dadurch mehr von der Stadt zu sehen ist als in dem Ausschnitt davor. Hierfürsollten die Standard Aktionen von gängigen Programmen bereitgestellt werden, wozu jeeine Taste für das Vergröÿern und Verkleinern des Maÿstabs zählt. Zum Zooming kannauch die Auswahl eines neuen Ausschnitts im sichtbaren Kartenausschnitt gezählt werden.Hierbei wird in der Regel durch gedrückthalten und bewegen der Maustaste ein Bereichmarkiert. Dieser wird dann auf die verfügbare Darstell�äche der Anwendung gestreckt. Dader auswählbare Bereich begrenzt ist auf den dargestellten Kartenausschnitt, ist lediglichein vergröÿern des Maÿstabs möglich. Das Zooming kann auf zwei Arten implementiertwerden:

1. Koordinaten mit einem Zoomfaktor manipulierenDabei werden vor dem Zeichnen der Geoobjekte alle Koordinaten mit einem Zoom-faktor multipliziert bzw. dividiert. Um beispielsweise die Karte in doppelter Gröÿedarstellen zu können, werden Koordinaten aller Geoobjekte mit zwei multipliziert.Soll hingegen um die Hälfte verkleinert werden, muss durch zwei dividiert werden.

4.3 Visualisierungs-Mapping 51

2. Kartenausschnitt verändernHierbei werden nur die Koordinaten des Kartenausschnitts verändert. Der Karten-ausschnitt wird bestimmt durch zwei Koordinatenpaare, die ein Rechteck auf derKarte de�nieren. Diese Koordinatenpaare sind gegenüberliegende Eckpunkte desAusschnitts. Dabei können diese, linke untere Ecke und rechte obere Ecke sein, oderlinke obere Ecke und rechte untere Ecke. Werden diese Eckkoordinaten nach Auÿenverschoben vergröÿern sie den Kartenausschnitt. Da aber der Bereich in dem dieKarte gezeichnet werden soll ihre Gröÿe beibehält, erscheinen Geoobjekte auf derKarte kleiner. Verschiebt man die Eckkoordinaten näher zueinander, dann wird derAusschnitt kleiner und die Geoobjekte werden gröÿer.

In dieser Arbeit wird das Zooming durch das Verändern des Kartenausschnitts verwirk-licht, da weniger Berechnungen nötig sind und die E�zienz somit höher ist.

4.3 Visualisierungs-Mapping

Bisher wurde in diesem Kapitel die Frage aufgeworfen, wie die Visualisierung von Geo-objekten mit bestimmten Typen in einem generischen Kartengenerator erfolgen kann. Eswurde festgestellt, dass für eine solche Visualisierung eine Zuordnung zwischen Geodatenund ihrer Darstellung erfolgen muss, die Visualisierungs-Mapping genannt wurde. DieEntscheidung, ob ein solches Mapping statisch oder dynamisch sein sollte, �el zugunstender dynamischen Zuordnung. Im weiteren wurde diskutiert, wie die Visualisierung einzel-ner Objekte und der Aufbau der gesamten Bildschirmkarte erfolgen kann. Dazu wurdeidenti�ziert, welche Darstellungsvariablen nötig sind und welche Interaktionsmöglichkei-ten die GUI, in der die von MapGENeric erstellte Karte dargestellt werden soll, bietenmuss.

In diesem Abschnitt soll Schritt für Schritt eine Methode für das Visualisierungs-Mapping erarbeitet werden, die den Anforderungen der Flexibilität gerecht wird. Hierzuwird im folgenden erst einmal analysiert werden, aus welchen Bestandteilen eine Zuord-nung besteht und wie die Darstellung von Geoobjekten auf herkömmliche Weise funktio-niert. Diese Funktionsweise muss daraufhin beschrieben werden, da sie die Basis für dasVisualizierungs-Mapping stellt. Im Verlauf werden diese Bestandteile dynamisiert werden,um am Ende zu einer Methode für das Visualisierungs-Mapping zusammengefasst zu wer-den. Ferner wird festgestellt werden müssen, welche Daten nötig sind, um Geoobjekte derdrei Basisklassen darstellen zu können.

4.3.1 Bestandteile des Visualisierungs-Mappings

Bei der Visualisierung der realen Welt auf Bildschirmkarten existieren auf der einen Sei-te die darzustellenden Objekte � Geoobjekte(Modelle der Realität) � in Form vonGeodaten (siehe Kapitel 2.2.1 - Modellierung von Geoobjekten). Auf der anderen Sei-te steht die visuell sichtbare, graphische Darstellung dieser Geodaten, die im folgen-den Repräsentations-Objekte genannt werden. Das Aussehen dieser Repräsentations-


Abbildung 4.7: Zuordnung Geoobjekt ↔ Darstellungsform

Abbildung 4.8: Symbol für Hotels

Objekte wird durch eine Menge von Darstellungsvariablen de�niert, die im weiteren Dar-stellungsformen genannt werden. Zur Darstellung von GeoObjekten agiert in herkömm-lichen Kartengeneratoren eine Zuordnung zwischen GeoObjekten und Darstellungsformen,aufgrund dieser der Kartengenerator Repräsentations-Objekte generiert. Diese Zuordnungist schematisch in Abbildung 4.7 dargestellt. Dabei ist zu beachten, dass diese Zuordnungbidirektional sein muss, um bei Interaktionen mit Bildschirmkarten, wie sie in Kapitel 4.2.2vorgestellt wurden für die Darstellung weiterer Eigenschaften der Geoobjekte, Rückgri�eauf die Datenbank ermöglichen zu können.

An Hand des folgenden Beispiels soll näher betrachtet werden, wie die Zuordnung aufherkömmliche Weise funktioniert. Es wird angenommen, dass die Geodaten in den Tabel-len 4.1 bis 4.12 in einer Geodatenbank bereitstehen. Nun sollen Geoobjekte(Hotels) ausder Tabelle 4.10 mit dem Symbol in der Abbildung 4.8 dargestellt werden.

Dazu ist im Code der jeweiligen Anwendung, die diese Geodaten darstellen soll, eineAbfrage (z.B. SQL-Statement) für die Tabelle mit den Hotels implementiert, die ausge-führt wird. Daraufhin werden Geoobjekte aus dieser Tabelle mit dem Symbol aus Ab-bildung 4.8 gezeichnet. Um eine �exible Zuordnung verwirklichen zu können, muss dieseimplizite Zuordnung aus der Anwendung ausgelagert werden, d.h. dass eine KomponenteVisualisierungs-Mapping, wie sie in Abbildung 4.1 zu sehen ist, entworfen werden muss.Ideal wäre dieses Mapping, wenn es die Möglichkeit bieten würde, darzustellende Geoob-jekte zu spezi�zieren, Darstellungsformen für diese zu de�nieren und einander zuzuordnen,wobei alle drei Möglichkeiten dynamisch sein müssten.


4.3.2 Dynamisierung des Visualisierungs-Mappings

In diesem Abschnitt soll die Dynamisierung der drei Bestandteile eines Visualisierungs-Mappings (darzustellende Geoobjekte, Zuordnung und Darstellungsform) erarbeitet wer-den. Werden die Bestandteile darzustellende Geoobjekte und Darstellungsform als Mengenbetrachtet, so ist die Dynamisierung aufzufassen als eine �exible Erweiterungsmöglichkeitdieser Mengen im Nachhinein. D.h. die Menge der darzustellenden Geoobjekte kann ver-ändert werden, genauso wie die der Darstellungsformen. Wird beispielsweise das Logoeiner bestimmten Restaurantkette durch ein neues ersetzt, so würde die Menge der Dar-stellungsformen dieser Gegebenheit angepasst werden können. Die Zuordnung würde dannals eine mathematische Abbildung z(x) aufgefasst werden können, die aus der Menge derdarzustellenden Geoobjekte abbildet auf die Menge der Darstellungsformen. Die Dyna-misierung der Zuordnung ist somit die Austauschbarkeit der Funktion z(x). Im folgendenwerden Systeme entwickelt und ausdiskutiert, die die Dynamisierung der einzelnen Be-standteile erreichen und zum Schluss die Basis für MapGENeric bieten. Dabei werdenimplizit Fragen beantwortet wie u.a. �Welche Alternativen existieren zum System vonMapGENeric?�.

Dynamische Zuordnung

Unter Berücksichtigung der drei Bestandteile eines Visualisierungs-Mapping ist eine mög-liche Auslagerung der Zuordnung für einen �exibleren Kartengenerator gegeben durchfolgendes System. In einem Kartengenerator sind verschiedene Darstellungsformen fürjede Basisklasse von Geoobjekten mit eindeutigen Namen statisch im Quellcode imple-mentiert. Diese könnten für obiges Beispiel, Hoteldarstellung01, Museumsdarstellung01,Straÿendarstellung01, Straÿendarstellung02, ..., lauten und Werte für die Darstellungsva-riablen für die jeweilige Basisklasse (Punkt, Linie oder Fläche) aus Kapitel 4.2.1 bein-halten wie Farbe, Gröÿe, Muster, usw. Es ist ausreichend, die vorhandene Geodatenbankanzupassen, indem die Beispieltabelle 4.2 der darzustellenden Geoobjekte um eine Spalte�Darstellung� erweitert und in dieser die oben genannten Namen eingetragen werden, wiein Tabelle 4.13 zu sehen.

id name anz_spuren max_speed ampel darstellung

1 Welschnonnenstr. 4 50 ja Straÿendarstellung012 Belderbergstr. 2 50 nein Straÿendarstellung033 Hubertustr. 4 70 ja Straÿendarstellung024 St.Georg Str. 1 50 nein Straÿendarstellung01: : : : : :

Tabelle 4.13: Straÿen mit Darstellungsform

Dieses System hat den entscheidenden Nachteil, dass für jedes Geoobjekt explizit an-gegeben werden muss, durch welche Darstellungsform diese darzustellen ist. Ferner ist dieUnabhängigkeit bzgl. der Geodatenbank nicht gegeben, da noch immer geodatenspezi�schprogrammiert werden muss. Der einzige Vorteil den uns ein solches System bringt, ist der,dass im Nachhinein die Darstellungsform der Geoobjekte geändert werden kann. Natürlich


schreibender Zugri� für den Kartengenerator bzw. dessen GUI auf die Geodatenbank vor-ausgesetzt. Somit stellt dieses System ein teilweise dynamisches Visualisierungs-Mappingdar. Einzig und allein die Zuordnung ist dynamisch, die Wahl der darzustellenden Geo-objekte und die Darstellungsformen sind noch immer statisch.

Da eine Zuordnung auf Geoobjektbasis recht aufwendig ist, sollte eine Möglichkeit derZuordnung entwickelt werden, die die Gruppierung von Geoobjekten � Klassi�kation �erlaubt (siehe Kapitel 2.2.1 - Modellierung von Geoobjekten). Eine naive Klassi�kationkönnte im Kartengenerator implizit enthalten sein, so wie die Darstellungsformen im vor-angegangenen System mit eindeutigen Namen. Mit Hilfe eines GUI könnte dem Benutzerdes Systems die Möglichkeit geboten werden, diesen vorde�nierten Klassen, Darstellungs-formen zuzuordnen, wie in Abbildung 4.9. Gegenüber dem vorherigen System wäre damitlediglich eine leichtere Zuweisung für den Benutzer ermöglicht durch statische Geoobjekt-gruppen bzw. -klassen, denen die Darstellungsformen zugewiesen werden könnten anstatteinzelnen Geoobjekten. Alle anderen Nachteile (statische Geoobjektklassen und Darstel-lungsformen) würden erhalten bleiben, weshalb weitere Überlegungen gemacht werdenmüssen. Jedoch ist in diesem System noch immer die Zuordnung dynamisch.

Abbildung 4.9: Mapping über GUI

Dynamische Darstellungsformen

Als nächstes soll die Dynamisierung der Darstellungsform erarbeitet werden, wobei dieDiskussionen aus Abschnitt 4.2.1 helfen. Dort wurde festgestellt, dass für verschiedeneBasisklassen unterschiedliche Darstellungsvariablen relevant sind. In Tabelle 4.14 ist eineZusammenfassung der Ergebnisse dieser Diskussion.

Eine Dynamisierung würde erreicht werden durch Auslagerung der De�nitionen zuDarstellungsformen aus dem System. Es müssten hierfür Werte für Darstellungsvaria-blen mit einem eindeutigen Namen durch den Nutzer eingegeben und gespeichert werdenkönnen. Das GUI zur Zuordnung, wie sie in Abbildung 4.9 zu sehen ist, würde in denAuswahlboxen für Darstellungsformen statt der internen nun die Darstellungsformen ausdieser Speicherung anbieten. Mit der Auslagerung der Darstellungsformen und ihrer De-�nition wird die Flexibilität erhöht.


Punkt Linie FlächeFarbe + + + + + +Gröÿe + + + + �Form + + + + �Muster + + + + + +Richtung + + + + �Helligkeit + + +

Tabelle 4.14: Relevante DarstellungsvariablenZeichenerklärung: ++ erforderlich / + erforderlich, jedoch bereits abgedeckt / � nicht erforderlich

Vorstellbar für bisher diskutierte Systeme wäre auch eine Erweiterung, die eine hier-archische Struktur der Geoobjektklassen zulässt. Dadurch könnte eine Gruppe de�niertwerden, die beispielsweise Straÿen heiÿt und als Unterklassen Autobahn, Landstraÿe undBundesstraÿen hat. Dies hätte den Vorteil, dass diesen Klassen Werte für einzelne Dar-stellungsvariablen zugeordnet werden könnten, die bei der Generierung der Karte, je spe-zi�scher sie sind, andere überschreiben würden. Für dieses Beispiel wäre denkbar, dassdie Oberklasse Straÿen einen Wert für jede Darstellungsvariable erhält. Autobahn könnteeinen anderen Wert für Gröÿe erhalten und die Farbe rot zugewiesen bekommen. DerKlasse Landstraÿe würde man z.B. nur die Farbe gelb zuweisen. Bei der Generierung derKarte müsste sich der Kartengenerator durch diese Klassenhierarchie arbeiten und, wennes bei der Oberklasse Straÿen beginnt, die Darstellungsvariablen dieser übernehmen. BeiAutobahn angekommen müsste er die Linienstärke und Farbe mit den Werten für Au-tobahn überschreiben und Geoobjekte, die der Geoobjektklasse Autobahn angehören,mit der neuen Darstellungsform zeichnen. Bei Landstraÿen würde nur die Darstellungs-variable für Farbe aus der Oberklasse überschrieben werden und dadurch Landstraÿenin Gelb dargestellt werden. Bei Bundesstraÿen, für die keine Darstellungsvariablen ge-setzt sind, würde die Darstellungsform der Oberklasse angewendet werden. Jedoch wirdin dieser Arbeit von einer solchen Lösung abgesehen, da für potentielle Kartenautoren dieMapGENeric nutzen sollen, zu komplizierte De�nition entstehen würden, wodurch derÜberblick leicht verloren gehen könnte.

Dynamische Objektklassi�kation

Bisher wurde die Dynamisierung der Zuordnung und der De�nition für Darstellungsformenerreicht. Jedoch ist noch immer die Gruppierung der darzustellenden Geoobjekte zu einerKlasse (Klassi�kation � siehe Kapitel 2.2.1 - Modellierung von Geoobjekten) mühsam.Ferner soll mit MapGENeric eine Datenbankunabhängigkeit erreicht werden, die in denbisher vorgestellten Systemen nicht ansatzweise vorhanden ist. Im folgenden soll die Fragegeklärt werden, wie denn Geoobjektklassen spezi�ziert werden können, denen dynamischeine Darstellungsform zugewiesen werden kann. Bei herkömmlichen GIS-Anwendungen dieKarten aus Geodaten generieren, steht das Schema der Datenbank, aus der die Geodatenkommen, von vornherein fest. Ferner stehen auch die darzustellenden Geoobjektklassenfest. Wenn beispielsweise eine Geodatenbank die Tabellen im Beispiel aus dem letztenAbschnitt hat und eine GIS-Anwendung erstellt werden soll, die diese Daten darstellt,dann wird vorher festgelegt, welche Geoobjektklassen darin dargestellt werden können


oder sollen. Beispielsweise sei eine Klasse Museen gegeben, in der alle Museen aus derTabelle enthalten sind. Würde nun der Bedarf bestehen, Museen mit Ausstellungen undohne Ausstellungen unterschiedlich darzustellen und dafür in verschiedene Klassen aufzu-teilen, weil dies vorher nicht bedacht wurde, müsste die GIS-Anwendung umgeschriebenwerden. In MapGENeric sollen ähnliche Aufteilungen oder Neude�nitionen möglich sein,ohne MapGENeric umzuprogrammieren. Somit entsteht der Bedarf für ein System, dasder dynamischen De�nition von Geoobjektklassen dient.

Geoobjekte die hier betrachtet werden, sind in relationalen Datenbanken in so genann-ten Relationen (siehe Kapitel 3.1.3) gespeichert. Dabei ist nicht zwingend erforderlich, dassGeoobjekte einer bestimmten Klasse in nur einer Relation gespeichert sind. Geoobjektekönnen über verschiedene Relationen verteilt gespeichert sein. Mit Hilfe einer Relationa-len Anfragesprache wie SQL, die in Kapitel 3.1.5 vorgestellt wurde, ist es möglich, überverschiedene Relationen Anfragen zu stellen, die eine Menge von Geoobjekten als Ergeb-nis zurück gibt. Relationen werden, wie in den Grundlagen zu Datenbanken zu lesen ist,de�niert als Mengen; Mengen von Tupeln. Diese Überlegungen führen unweigerlich zurgewünschten Dynamisierung der Objektgruppierung/-klassi�kation. Denn mit SQL ist esmöglich, jede durch Mengenoperatoren herleitbare Menge aus der Menge der in der Daten-bank gegebenen Daten zu de�nieren. Somit ist, um das Beispiel der Klassenunterteilungvon Museen aufzugreifen, möglich die Klasse Museen, die durch die SQL Anfrage

SELECT * FROM museen;

de�niert würde, zu unterteilen in zwei SQL Anfragen der Form

SELECT * FROM museen WHERE ausstellung = "";

und

SELECT * FROM museen WHERE NOT ausstellung = "";

Die durch SQL auf diese Weise de�nierten Geoobjektklassen müssten benannt werden,damit sie beispielsweise in einer Anwendung, die eine Zuordnungsmöglichkeit bietet, wiesie in Abbildung 4.9 gezeigt wird, in der Spalte Objektgruppe angezeigt werden kann.Solche SQL-Anfragen, die Datenbanken an bestimmte Bedürfnisse anpassen und einenNamen erhalten, werden bezeichnet als Sichten (siehe Kapitel 3.1.5 � Sichten). So ist einangepasster Zugri� auf die Datenbank möglich. Da SQL von fast allen gängigen DBMSbereitgestellt wird, ist auch gleichzeitig eine datenbankunabhängige Klassi�zierung derGeoobjekte erreicht.

4.4 Regelbasierter Ansatz für das Visualisierungs-Mapping 57

4.4 Regelbasierter Ansatz für das

Visualisierungs-Mapping

In diesem Kapitel wurden bisher Lösungen zur Dynamisierung der Bestandteile einer Zu-ordnung erarbeitet, die einzeln betrachtet ihren Anforderungen gerecht werden. Aus diesendynamischen Bestandteilen soll im folgenden ein System zusammengestellt werden, dasden Forderungen aus Kapitel 4.1 genügt, einen generischen Kartengenerator zu entwickeln.

Die Komponente Visualisierungs-Mapping aus der Abbildung 4.1 kann durch eine ge-eignete Zusammenführung dieser dynamischen Bestandteile gebildet werden. Dabei solltenjedoch in Kapitel 4.1 und 4.2 identi�zierte Funktionalitäten, wie unter anderem die Zu-weisung von Geoobjektklassen zu bestimmten Layern, verschiedene Kon�gurationen fürdieselbe Geodatenbank und die möglichen Darstellungsvariablen für Darstellungsformenberücksichtigt werden. Zusammenfassend kann das Visualisierungs-Mapping anhand fol-gender Schritte beschrieben werden: Geoobjektklassen de�nieren, ihre Darstellungsformde�nieren und zuweisen, Layer bestimmen und zuweisen und diese drei einer Kon�gura-tion zuordnen. Diese Schritte können als Schritte einer Anleitung aufgefasst werden, diezu befolgen sind, um die Kon�guration eines generischen Kartengenerators zu de�nieren.Anleitungen dieser Art werden Regeln benannt. Eine Regel, die auf diesen Schritten ba-siert und die gewünschte Zuordnung beschreibt, könnte lauten: �Stelle Geoobjekte x,y zuKlasse K zusammen und zeichne sie durch Darstellungsform D auf Layer L�. Wird dieseRegel einer Kon�guration zugewiesen, so deckt sie zuvor identi�zierte Bestandteile einerZuordnung ab.

Durch den Einsatz von Regeln kann eine Trennung von Logik, Daten und Darstellungerzielt werden, d.h. die Programmierung eines Kartengenerators ist nicht mehr abhän-gig von den darzustellenden Daten und ihrer Darstellungen. Der Einsatz dieser Technikbedeutet für die vorliegende Arbeit, dass eine Anwendungsunabhängigkeit erreichtwerden würde. Denn Regeln stellen einzelne Bausteine dar, die durch das System derReihe nach abgearbeitet werden können, um das gewünschte Ergebnis zu erzielen. Dabeiist es irrelevant für das System, zu welchem Ergebnis die Regeln führen, solange sie dievereinbarte Syntax befolgen. Falls Ergebnisse verändert bzw. angepasst werden sollen, istlediglich das Anpassen dieser Kon�guration erforderlich. Aus diesen Beobachtungen las-sen sich zwei Akteure für das MapGENeric-System identi�zieren, wobei �ein Akteur einevom Anwender in Bezug auf das System eingenommene Rolle ist� [FS00] :

1. Der Kartenautorist für die Kon�guration von MapGENeric verantwortlich. Er kennt das Schemader darzustellenden Geodatenbank und weiÿ, wie die darin enthaltenen Geoobjektedargestellt werden sollen.

2. Der Kartennutzerist der Endanwender von MapGENeric, der die Karte dargestellt bekommt, wie sievom Kartenautor vorgesehen ist. Ferner interagiert er mit der graphischen Ober�ä-che der Anwendung, um Layer ein- oder auszublenden, den Ausschnitt zu verändern


und weitere Informationen zu bestimmten Geoobjekten anzufordern. Beispielsweisesind aus dem Touristik/Umwelt-Beispiel, der Tourist und der Umweltbeauftragteals Kartennutzer einzuordnen.

4.4.1 Grundkonzepte der Regelsprache

Vorangegangene Beobachtungen legen nahe, das Visualisierungs-Mapping regelbasiertzu entwickeln. Hierzu ist die De�nition einer Regelsprache notwendig. Im folgenden sollenGrundkonzepte einer solchen Regelsprache erarbeitet werden. Dazu werden bisher identi-�zierte Bestandteile einer Zuordnung und gewünschte Funktionalitäten näher betrachtet.Durch eine Diskussion entsteht Schritt für Schritt ein Modell für die Grundkonzepte derSprache, das dargestellt werden wird durch ein EntityRelationship-Diagramm(3.1.2). DasER-Diagramm wurde gewählt, da es Zusammenhänge leichter verständlich macht und einespätere Überführung in ein relationales Datenbankschema nahezu automatisch ermöglicht.Die Überführung in ein relationales Datenbankschema ist insofern notwendig, als die Re-geln, die eine Kon�guration des MapGENeric-Systems darstellen, dauerhaft gespeichertwerden sollten. Für jede Anwendung, die durch MapGENeric dargestellt werden soll, wirdeine relationale Datenbank vorausgesetzt, in der die darzustellenden Geodaten gespeichertsind. Da auch für jede dieser Anwendungen eine Kon�guration für MapGENeric erfor-derlich ist, emp�ehlt es sich, einen Schreibzugri� auf die darzustellende Datenbank zufordern und die anwendungsspezi�sche Kon�guration in der jeweiligen Geodatenbank zuspeichern. Sind die Beziehungen zwischen einzelnen Bestandteilen einer Regel für Map-GENeric erläutert, so wird in einem nächsten Schritt die Modellierung detaillierter aus-gearbeitet.

Zusammengefasst soll eine Regelsprache entstehen, durch die Regeln formuliert wer-den können, die wiederum die Kon�guration von MapGENeric ausmachen. VerschiedeneKon�gurationen sollen zugelassen werden, so dass unterschiedliche Anwendungen undDarstellungen aus derselben Geodatenbank verwirklicht werden können. Ferner soll ei-ne Klassi�zierung verschiedener Geoobjekte zu einer Geoobjektklasse ermöglicht werden.Diese sollen auf verschiedenen Layern dargestellt werden. Geoobjekten einer Klasse solleine Darstellungsform zugewiesen werden können, durch die sie auf einem bestimmtenLayer dargestellt werden.Wird diese Anforderungsanalyse betrachtet, so lassen sich die Entitytypen Regeln, Kon-�gurationen, Layer, Geoobjektklassen und Darstellungsformen ermitteln. Es entsteht eineinfaches ER-Diagramm, wie in Abbildung 4.10 zu sehen, das die generelle Struktur derRegelsprache modelliert.

Die Beziehung �de�nieren� zwischen den drei dunkler dargestellten Entities Geoobjekt-klasse, Darstellungsform und Layer könnte ohne ihre Bezeichnung folgendermaÿen gelesenwerden: stelle Geoobjekte der Klasse [Geoobjektklasse] dar auf dem Layer [Layer], durchdie Darstellungsform [Darstellungsform]. Diese Beschreibung ähnelt der Regelbeschrei-bung aus dem übergeordneten Kapitel 4.4 �Stelle Geoobjekte x,y zu Klasse K zusammenund ...�, wodurch sie eine solche Regel de�niert und deshalb als �de�nieren� bezeichnetwurde. Jetzt kann die Beziehung gelesen werden als Geoobjekte der Klasse [Geoobjektklas-se] dargestellt durch [Darstellungsform] auf [Layer] de�nieren [Regeln].


Abbildung 4.10: ER-Diagramm der Visualisierungs-Mapping-Regelsprache

Kon�gurationen

Kon�gurationen sollen mehrere Regeln für eine bestimmte Anwendung bündeln. Die Zu-weisung von Regeln zu einer bestimmten Kon�guration erfolgt über die Beziehung �ent-halten�. Um zu vermeiden, dass für verschiedene sich ähnelnde Anwendungen, die auf der-selben Geodatenbank basieren, dieselbe Regel mehrfach de�niert werden muss, und ausder Forderung, dass verschiedene Regeln zu einer Kon�guration zusammengestellt wer-den können, die Visualisierungskonventionen für eine bestimmte Anwendung darstellen,ist diese Beziehung als eine n:m-Beziehung modelliert worden. Dadurch wird ermöglicht,dass Regeln unterschiedlichen Kon�gurationen angehören und diese Kon�gurationen wie-derum aus mehreren Regeln bestehen können. Damit Kartenautoren sowie -nutzer Kon�-gurationen unterscheiden können, wird ein bezeichnendes Attribut notwendig, das �Name�genannt wird (Abb. 4.11).

Layer

Layer stellen im übertragenen Sinn durchsichtige Folien dar, auf denen die darzustel-lenden Geoobjekte gezeichnet werden können. Es hat sich (wie auch im Grundlagenteilerläutert) durchgesetzt, dass Geoobjekte einer bestimmten Klasse auf demselben Layergezeichnet werden. Werden diese Folien (gleicher Maÿstab und Ausschnitt vorausgesetzt)übereinander gelegt, entsteht eine Karte. Durch das Übereinanderlegen der Layer kön-nen unerwünschte Überdeckungen von Geoobjekten entstehen. Generell werden deshalb�ächenhafte Objekte als erste, darüber linienhafte und zu letzt punkthafte Geoobjektegezeichnet. Trotzdem können weiter unerwünschte Überdeckungen entstehen. Wenn bei-


spielsweise eine Überführung über einer anderen Straÿe dargestellt werden soll, dann istauch die Zeichenreihenfolge unter den linienhaften Geoobjekten relevant. Das Layerkon-zept soll aus zwei Gründen eingeführt werden:

1. Kartenautoren soll die Möglichkeit geboten werden, bei der Erstellung einer Kon-�guration, beispielsweise Überdeckungsprobleme einfacher zu lösen. Dazu soll derKartenautor die Zeichenreihenfolge von Layern beliebig ändern können, um ent-scheiden zu können, welche Reihenfolge besser für die gewünschte Darstellung derKarte geeignet ist.

2. Der Kartennutzer dagegen soll Layer, deren Inhalt nicht seinem Interesse entspre-chen, ausblenden können (Kapitel 4.2.2).

Wenn die bisher nur verbale Regel-De�nition betrachtet wird, dann ist ein Layer dieZeichen�äche für Geoobjekte, deren Repräsentations-Objekte durch Darstellungsformende�niert werden. Wird ein Layer eingeblendet, ausgeblendet oder in der Zeichenreihen-folge versetzt, so wird im Grunde die Bearbeitung einer Regel eingesetzt, ausgesetzt oderin der Bearbeitungsreihenfolge versetzt. Daraus ergibt sich, dass das Entity �Layer� somitlediglich virtuell vorhanden ist und erst einmal in der Modellierung vernachlässigt wird(Abb. 4.11).

Durch zuvor erläuterte Überdeckungsprobleme ergibt sich die Notwendigkeit für einAttribut der Regel, das seine Position in einer Regelbearbeitungsreihenfolge darstellt. Die-ses Attribut ist nicht der Regel selber zuzuordnen, weil eine Kon�guration aus ein odermehr Regeln besteht und eine Regel mehreren Kon�gurationen zugewiesen werden kann.Daraus ergibt sich, dass diese Position die Position in der jeweiligen Kon�guration dar-stellt und somit der Beziehung zwischen Kon�guration und Regel zuzuordnen ist, wie inAbbildung 4.11 dargestellt.

Um bei der Kon�guration festlegen zu können, welche Layer sichtbar und welche nichtsichtbar sein sollen, muss ein weiteres Attribut eingeführt werden. Dieses wird in Abb.4.11 durch �Sichtbar� dargestellt und ebenfalls der Beziehung �enthalten� zugeordnet,weil auch hier die Sichtbarkeit in der jeweiligen Kon�guration ausschlaggebend ist. Denndie Sichtbarkeit eines Layers in der einen Kon�guration kann erwünscht, jedoch in eineranderen Kon�guration nicht erwünscht sein. Für die spätere Implementation ist ein solcherFlag auch aus Gründen der Performanz wichtig, da dadurch unerwünschte Geoobjektenicht ausgelesen werden müssen. Es ist sicherlich auch wünschenswert Layer zu benennen,um sie bei einer Kon�gurations-De�nition wiedererkennen zu können. Dieses Attribut�Name� muss aus leicht ersichtlichen Gründen der Regel zugeordnet werden. Dadurcherweitert sich das ER-Diagramm, wie in Abb. 4.11 zu sehen ist.

Geoobjektklassen

Als nächstes wird das Augenmerk auf die Geoobjekt-Klassende�nition gelenkt. Geoobjekt-klassen sollen Geoobjekt-Modelle mit ähnlichen Eigenschaften zu einer Klasse gruppieren,damit dieser Klasse komfortabel eine Darstellungsform zugeordnet werden kann, mit der


Abbildung 4.11: ER-Diagramm erweitert um Layer-Attribute

sie gezeichnet wird. Zur Erkennung der jeweiligen Geoobjektklasse bei der Kon�gurations-De�nition durch den Kartenautor sollte ein Bezeichner (Name) für Geoobjektklassen ein-geführt werden.

Zuvor in dieser Arbeit wurde gezeigt, dass Geoobjekt-Modelle einer Basisklasse (Punkt,Linie oder Fläche) angehören. Um Repräsentations-Objekte dieser Geoobjekte entspre-chend zeichnen zu können, muss ein Kartengenerator wissen, welcher dieser Basisklassendas Geoobjekt angehört, da verschiedene Routinen für die Darstellung der einzelnen Basis-klassen erforderlich sind. Es könnte ein Kartengenerator entwickelt werden, der an Handder Geodaten analysiert, welcher Basisklasse diese angehören. Jedoch können Geoda-ten unabhängig von ihrer Modellierung unterschiedlich dargestellt werden, beispielsweisekönnten mit ihren Umrisskoordinaten modellierte Gebäude, anhand eines dieser Umriss-koordinaten punktförmig durch ein Bitmap dargestellt werden. Um die Flexibilität vonMapGENeric auf dem höchstmöglichen Niveau halten zu können, muss aus diesem Grundverlangt werden, dass die Basisklasse der zu spezi�zierten Geoobjektklasse mitgeteilt wird.

Zur Klassi�kation von Geoobjekten wurde unter �Dynamische Objektklassi�kation�(Kapitel 4.3) eine Geoobjekte-Sicht-De�nition erarbeitet, die ebenfalls eine Eigenschaftdes Entitytyps �Geoobjektklasse� darstellt, wie zuvor die Basisklasse. Ferner ist eine wei-tere Sicht-De�nition für die Darstellung der nicht-graphischen Geoobjekt-Eigenschaftenals notwendig befunden worden, die eine weitere Eigenschaft der �Geoobjektklasse� dar-stellt (Abb. 4.12).


Abbildung 4.12: ER-Diagramm erweitert um Geoobjektklassen-Attribute

Darstellungsformen

Geoobjekte aus der realen Welt können auf einer Karte nur durch Repräsentations-Objekte dargestellt werden. Zum Zeichnen eines Repräsentations-Objekts bedarf es ei-niger Werte für Darstellungsvariablen (Kapitel 2.2.3). Diese Werte bestimmen das Aus-sehen der Repräsentations-Objekte. Geoobjekte derselben Klasse werden durch dasselbeRepräsentations-Objekt dargestellt. Es wurde zuvor gezeigt, dass Geoobjekte einer vondrei Basisklassen (Punkt, Linie, Fläche) angehören. Auf Seiten der Darstellung werdenauch drei Klassen von Repräsentations-Objekten unterschieden, für die lt. Diskussionen inKapitel 4.2.1 unterschiedliche Darstellungsvariablen relevant sind. Die Bündelung der Dar-stellungsvariablen zur De�nition eines Aussehens für diese Klassen von Repräsentations-Objekten werden in dieser Arbeit Punkt-, Linien- und Flächen-Darstellungsformen ge-nannt werden. Wenn Geoobjekte, wie im obigen Beispiel als Hotels klassi�ziert werden,erhalten sie in Regeln eine Punkt-Darstellungsform zugeordnet, die das Aussehen ihresRepräsentations-Objekts beschreiben.

Auf Grund dieser Beobachtungen wird im folgenden das Modell für Darstellungsformenentwickelt. Darstellungsformen setzen sich zusammen aus den einzelnen Darstellungsfor-men für die Basisklassen Punkt, Linie und Fläche. In der ER-Diagramm-Darstellung wirddies, wie in Abbildung 4.13 zu sehen ist, durch eine is-a-Generalisierung dargestellt. Dadie Darstellungsvariable Farbe für alle Darstellungsformen benötigt wird, ordnet man siedem Obertyp zu, in diesem Fall Darstellungsform. Die Untertypen PunktDF, LinieDF undFlächeDF erhalten ihre spezi�schen Eigenschaften wie Höhe, Breite, Muster, etc. (sieheAbbildung 4.13).


Abbildung 4.13: ER-Diagramm für Darstellungsformen

Die Darstellungsform für Punkte (PunktDF) sollte nach o.g. Beobachtungen neben derFarbe die Gröÿe und eine Form besitzen. Die Gröÿe ist durch die beiden EigenschaftenLänge und Breite modelliert. Die Form bedarf zwei weiterer Variablen, da zuvor festge-stellt wurde, dass Formen durch Bitmaps möglich sind und zur e�zienteren Darstellungvon oft vorkommenden Punktobjekten vorde�nierte Formen bereitgestellt werden sollten.

Zur Darstellung von Linien sind einige weitere Eigenschaften notwendig. Bei der Grö-ÿenangabe für Linien entfällt die Längenangabe, da diese durch die Begrenzungskoordina-ten der Linie festgelegt werden. Jedoch kommen Muster, Anfang und Ende hinzu. Musterspezi�ziert dabei, ob eine Linie durchgehend, gepunktet, gestrichelt oder aus Kombina-tionen der letzten beiden dargestellt wird. Anfang und Ende de�nieren das Aussehen derLinien. Die Form wird bei Linien anders als bei Punkten de�niert. Sie de�niert bei ge-punkteten und gestrichelten Linien, wie die einzelnen Elemente dieser Linie dargestelltwerden (spitze, runde oder �ache Enden).

Bei der Darstellungsform für Flächen (FlächenDF) wurde zuvor gezeigt, dass nebender Farbe noch das Muster von Bedeutung ist, weshalb alle anderen Darstellungsvariablennicht explizit angegeben werden müssen. Daraus resultiert, dass auch im ER-Diagrammkeine weiteren Eigenschaften zugeteilt werden müssen. Um die Grenzen einer Fläche deut-lich machen zu können, bietet es sich an, diese kenntlich zu machen. Grenzen können ambesten durch eine Linie dargestellt werden, wofür eine eigene Darstellungsform existiert.Dies führt unweigerlich dazu, dass der FlächenDF eine LinienDF zugewiesen werden soll-te. Im ER-Diagramm in Abbildung 4.13 wird dies als Beziehung umrahmt dargestellt. Dasendgültige Modell der MapGENeric-Visualisierungs-Mapping-Regelsprache ist in Abbil-dung 4.14 zu sehen.


Abbildung 4.14: Modell der Visualisierungs-Mapping-Regelsprache

Kapitel 5

Syntax und Semantik der

Regelsprache VRL

Im letzten Kapiel wurde die Notwendigkeit einer Regelsprache deutlich, die zur Beschrei-bung einer Kon�guration für das ebenfalls im letzten Kapitel modellierte MapGENeric-System dient. Eine Kon�guration ist aufzufassen als eine Menge von Regeln, die die Dar-stellung von Geoobjekten aus einer relationalen Geodatenbank de�niert. Ferner wurdenim letzten Kapitel Grundkonzepte einer solchen Regelsprache erläutert, die in diesem Ka-pitel ergänzt werden sollen zu einer formalen Beschreibung dieser Sprache.

Im folgenden soll die Syntax der Regelsprache durch eine kontextfreie Grammatikformal de�niert werden. Diese Syntax wird Schritt für Schritt aufbauend durch die BNF-Notation begleitet von verbal formulierter Semantik der Sprache 1beschrieben. Dabei wirdverzichtet, die Grammatik bis ins letzte Detail zu beschreiben, d.h., wenn ein Nonterminalauf der rechten Seite der Grammatikregel genutzt wird und keine weitere Grammatikregelvorhanden ist, die dieses Nonterminal beschreibt, dann werden diese verbal beschriebenwerden. Ferner wird ein Nonterminal, das auf der rechten Seite der Grammatikregel ge-nutzt wird und maximal eine Grammatikregel vorhanden ist, in der dieses Nonterminaldurch Terminalsymbole de�niert ist, gesondert betrachtet. Diese Nonterminale werden imfolgenden ��nal Nonterminale� genannt und mit F-Nonterminal abgekürzt.

Im folgenden sollen alle Konventionen getro�en werden, die bei der Grammatikbe-schreibung genutzt werden, um die Syntax der Regelsprache VRL zu de�nieren. Dabeisind diese Konstrukte nicht als Erweiterung der BNF-Notation für eine bessere Übersichtanzusehen, sondern vielmehr als Grammatikeigenschaften der Regelsprache, um Sätze derSprache übersichtlicher zu gestalten:

1Die in diesem Kapitel schrittweise erarbeitete Grammatik ist mit einem Beispiel in Anhang A dar-gestellt.

65

66 Kapitel 5. Syntax und Semantik der Regelsprache VRL

• F-Nonterminale werden alleine oder in Gruppen durch runde Klammern ( ) einge-schlossen werden.

• F-Nonterminale werden durch Kommata voneinander getrennt.

• Nonterminale, deren Regeln beschrieben werden, werden in geschweiften Klammern{ } gruppiert.

• Namen und Verzeichnispfade werden in Anführungszeichen geschrieben.

Die Erweiterung der BNF-Notation durch das Konstrukt [uGrenze .. oGrenze]2,wird eingeführt, um eine komplizierte Grammatikbeschreibung zu vermeiden und dientzur Darstellung von numerischen Wertebereichen.

5.1 VM-Regeln

VM-Regeln de�nieren eine Beziehung zwischen Geoobjektklassen und Darstellungsfor-men. Diese Beziehung erhielt in Kapitel 4.4.1 auch einen Namen, so dass VM-Regeln inBNF-Notation wie folgt dargestellt werden können:

<VMRegel> ::= VMREGEL ( " <Name> " )

{ <Geoobjektklasse> <Darstellungsform> }

Eine VM-Regel besteht aus einem Namen und einer Kombination aus einer Geoobjekt-klasse und einer Darstellungsform. Zur Wiedererkennung wird das Terminalsymbol �VM-REGEL� vorangestellt gefolgt vom Namen der Regeln in runden Klammern. <Name>kann aus einer beliebigen Zeichenkette bestehen, jedoch soll deren Länge aus praktischenGründen begrenzt werden auf 25 Zeichen. Ferner muss der Name eindeutig vergeben wer-den, da über ihn auf die Regel zurückgegri�en werden kann. Die Kombination aus dendrei Elementen (Name, Geoobjektklasse und Darstellungsform) sollte ebenfalls eindeutigsein, da es keinen Sinn macht, mehr als einmal dieselbe VM-Regel zu de�nieren.

5.2 Kon�gurationen

Eine Menge bestimmter VM-Regeln, die zusammengenommen eine Visualisierung vonGeodaten einer Geodatenbank für eine bestimmte Anwendung de�nieren, können zu einerKon�guration zusammengefasst werden. Es wurde zuvor gezeigt, dass es zu unerwünschtenÜberdeckungen von Geoobjekten kommen kann, wenn eine Kon�guration aus mehr als ei-ner Regel besteht. Um diese unerwünschten Überdeckungen vermeiden zu können, müssenVM-Regeln eine Position (RegelPos) in der Reihenfolge der Abarbeitung erhalten. DiesePosition ist für Regeln einer Kon�guration eindeutig zu vergeben, d.h. zwei oder mehrVM-Regeln einer Kon�guration dürfen nicht dieselbe RegelPos haben. Positionsangaben

2UntereGrenze .. ObereGrenze des Wertebereichs

5.3 Darstellungsformen 67

werden als positive ganze Zahl de�niert. Ferner muss die �Sichtbarkeit� berücksichtigt wer-den, die bei der Kon�guration durch den Kartenautor eine initiale Einstellung erhaltensoll. Aus diesen neuen Gegebenheiten folgt, dass die <VMRegel>-De�nition angepasstwerden muss:

<VMRegel> ::= VMREGEL ( " <Name> " , <RegelPos> , <Sichtbarkeit> )


<Sichtbarkeit> ::= on | off

Kon�gurationen haben ebenfalls einen Namen (siehe Abbildung 4.14), durch den sie ein-deutig identi�ziert werden können. Die Kon�gurations-De�nition folgt dem Namen ingeschweiften Klammern.

<Konfiguration> ::= KONFIGURATION ( " <Name> " ) { <Konfig> }

<Konfig> ::= <VMRegel> | <Konfig> <VMRegel>

Durch bisher de�nierte Grammatikregeln ist lediglich eine Kon�gurations-De�nition mög-lich, es war jedoch gefordert, für dieselbe Geodatenbank verschiedene Kon�gurationende�nieren zu können. Dies wird erreicht durch:

<Konfigurationen> ::= <Konfiguration> |

<Konfiguration> <Konfigurationen>

Das Nonterminal (<Kon�gurationen>) stellt gleichzeitig das Startsymbol der Grammatikdar.

Bisher wurde das Grundgerüst der VRL formal beschrieben, in der die Nonterminale<Geoobjektklasse> und <Darstellungsform> noch unde�niert geblieben sind. Die De�-nition dieser Nonterminale soll in den folgenden Teilkapiteln erfolgen.

5.3 Darstellungsformen

Die Beschreibung der Darstellungsformen ist wesentlich komplexer als die der vorangegan-genen Nonterminale. Für jede der Basisklassen Punkt, Linie und Fläche wird eine andereSyntax benötigt, da diese unterschiedliche Darstellungsvariablen benötigen.

<Darstellungsform> ::= <PunktDF> | <LinieDF> | <FlaecheDF>


5.3.1 PunktDF

Punkt-Darstellungsformen benötigen für die Repräsentation eines punkthaft modellier-ten Geoobjekts Farbe, Länge, Breite, Form und Bitmap. Die Farbe wurde modelliert ausje einem Wert für Alphakanal(Transparenz), Rot, Grün und Blau. Da die Farbvielfaltmit 16,7 Mio. Farben ausreichend erschien, wurden Werte von 0 bis 255 erlaubt. Für�<Laenge>� und �<Breite>� werden lediglich Zahlen eingesetzt, die in diesem Fall Wertein Pixeln darstellen. Für die Darstellung von punktförmigen Geoobjekten, die in groÿerMenge auftreten und dadurch überfrachtend wirken könnten, wurde es in Kapitel 4.2.1für sinnvoll befunden, vorde�nierte Formen bereitzustellen (Ellipse, Dreieck und Recht-eck). Das letzte Nonterminal für die De�nition von <PunktDF> ist das Bitmap, das eineZeichenkette beinhalten darf, das wiederum einen absoluten Verzeichnispfad zu einer Bit-mapdatei repräsentiert. Absolut bedeutet dabei, dass beispielsweise für windowsbasierteDateisysteme der Pfadangabe auch ein Laufwerksbuchstabe vorangestellt sein muss.

<PunktDF> ::= PUNKTDF ( <Laenge> , <Breite> )

{<Farbe> <PForm> <Bitmap>}

<Farbe> ::= FARBE ( ) |

FARBE ( <Alpha> , <Rot> , <Gruen> , <Blau> )

<Alpha> ::= [0..255]

<Rot> ::= [0..255]

<Gruen> ::= [0..255]

<Blau> ::= [0..255]

<PForm> ::= PFORM( ) |

PFORM(Ellipse) |

PFORM(Dreieck) |

PFORM(Rechteck)

<Bitmap> ::= BITMAP ( ) |

BITMAP ( " <AbsoluterPfad> " )

Darstellungsformen für punktförmige Geoobjekte können auf zwei Arten de�niert werden.Bei der ersten Variante reicht es, neben der Länge und Breite lediglich einen Pfad zueinem Bitmap zu de�nieren. In diesem Fall brauchen keine Angaben zu Farbe und Formgemacht werden, weshalb sie in der Grammatikbeschreibung auch leer vorkommen können.Umgekehrt verhält es sich in der zweiten Variante. Wenn eine Punkt-Darstellungsformde�niert wird durch Farbe und Form, so ist eine Bitmap-Angabe über�üssig.

5.3 Darstellungsformen 69

5.3.2 LinieDF

Für die De�nition von Linien-Darstellungsformen wird eine gröÿere Anzahl an Darstel-lungsvariablen benötigt als für die anderen beiden Formklassen. Neben der Farbe sinddies Breite, Muster, Anfang, Ende und Form. Für Farbe und Breite ist keine spezielleGrammatikregel-De�nition notwendig, so dass die zuvor genannten Nonterminale (<Far-be> und <Breite>) hier ebenfalls genutzt werden können. Das Muster einer Linie wirdde�niert durch eine begrenzte Kombination aus Linienelementen (solid, dash und dot).Um beispielsweise Einbahnstraÿen, Sackgassen mit und ohne Wendemöglichkeit darstel-len zu können, wurde es für notwendig erachtet, Linienanfang und -ende entsprechenddurch eine Pfeilspitze, einen Kreis und ein Rechteck zu markieren. Die begrenzte Kombi-nation aus Linienelementen für das Muster ist mit seiner Variationmöglichkeit durch dieverwendete Programmiersprache Visual Basic als nicht ausreichend befunden worden, sodass durch Hinzunahme der Darstellungsvariable Form eine weitere Variationsmöglichkeitentsteht.

<LinieDF> ::= LINIEDF ( <Breite> , <Muster> , <Anfang> , <Ende> )

{ <Farbe> <LForm> }

<Muster> ::= solid | dash | dot | dashdot | dashdotdot

<Anfang> ::= <Anchor>

<Ende> ::= <Anchor>

<Anchor> ::= ArrowAnchor | RoundAnchor | SquareAnchor | NoAnchor

<LForm> ::= LFORM( ) |

LFORM(flat) |

LFORM(round) |

LFORM(triangle)

5.3.3 FlaecheDF

Darstellungsformen für �ächenförmige Geoobjekte haben lediglich drei Eigenschaften, an-hand derer sie die Darstellung von Geoobjekten de�nieren. Diese sind Farbe, Muster undUmrandung.

<FlaecheDF> ::= FLAECHEDF { <Farbe> <Bitmap> <Umrandung> }

<Umrandung> ::= <LinieDF>

Für die Farbe kann, wie zuvor für Linien-Darstellungsform, die bisherige De�nition über-nommen werden. Da es sich bei Muster um ein Bitmap handelt (siehe Kapitel 4.2.1), kannhierfür die De�nition für das Nonterminal <Bitmap> genutzt werden. Bleibt lediglich dieDe�nition für Umrandung, die jedoch de�niert wird durch die Darstellungsform-De�nitionLinieDF.


5.4 Geoobjektklasse

In Kapitel 4.4.1 wurde bei der Darstellung der Grundkonzepte ermittelt, dass Geoobjekt-klassen durch einen Namen, ihre Basisklasse, ihre Geoobjekt-Sicht- und Attribut-Sicht-De�nition de�niert werden müssen (Abbildung 4.12).

<Geoobjektklasse> ::= GEOOBJEKTKLASSE( " <Name> " , <BasisKlasse> )

{ <GeoObjSicht> <AttribSicht> }

<BasisKlasse> ::= Punkt | Linie | Flaeche

Für eine graphische Repräsentation eines Geoobjektes sind neben der Darstellungsformihre Geometriedaten ausschlaggebend. Diese Geometriedaten bestehen, wie in Abschnitt2.2.1 gesehen, aus Positionsdaten in einem kartesischen Koordinatensystem, mit denendie absolute Lage festgelegt wird. Dazu werden bei punktförmigen Geoobjekten ein, beilinienförmigen mindestens zwei und bei �ächenförmigen mindestens drei Koordinatenpaa-re benötigt.

Zur Geoobjektklassen-De�nition wird eine Sichtde�nition (<GeoObjView>) auf diezuvor genannten Geometriedaten benötigt. Da eine Unterteilung von Geoobjekten inpunkt-, linien- und �ächenförmige Geoobjekte existiert und diese verschiedene Anzah-len von Koordinatenpaaren benötigen, um dargestellt werden zu können, müssen diesedi�erenziert analysiert werden. Dabei soll ermittelt werden, wie eine solche Sichtde�niti-on für die jeweilige Basisklasse aussehen muss.

5.4.1 Punktförmige Geoobjekte

Punktförmige Geoobjekte werden in Datenbanken in der Regel so modelliert, dass in einerTabelle alle punktförmigen Geoobjekte einer Klasse gespeichert werden. Ein Beispiel hier-für bildet die Tabelle 4.10, in der alle Hotels gespeichert sind. Jedes Tupel dieser Relationrepräsentiert ein Hotel mit dem jeweiligen Koordinatenpaar. Es gibt nicht zuletzt auchdie Möglichkeit, wie sie Tabelle 4.8 darstellt. Hier liegen die Koordinatenpaare in eineranderen Relation. Für die Darstellung dieser Geoobjekte durch Repräsentations-Objekteinteressiert einzig und allein das jeweilige Koordinatenpaar. Um jedoch weitere Informa-tionen zu den jeweiligen Geoobjekten auf Anforderung darstellen zu können, wäre dasMitführen des eindeutigen Schlüssel (ID) von groÿer Bedeutung. Dieser ID identi�ziertGeoobjekte eindeutig innerhalb der Relation, in der ihre Geodaten gespeichert sind.

Damit ein generischer Kartengenerator wie MapGENeric punktförmige Geoobjektedarstellen kann, muss er Längen- und Breitengrad dieses Objektes kennen. Da die Spal-ten, in denen diese Informationen in der jeweiligen Geodatenbank gespeichert sind, un-terschiedlich benannt worden sein können, muss für MapGENeric gefordert werden, dassdiese dem System mitgeteilt werden. Eine weitere, bessere Alternative wäre, dass Map-GENeric einen bestimmten Namen für diese Spalten erwartet und die Geodaten bzw.

5.4 Geoobjektklasse 71

die Sicht auf diese angepasst werden. Dies kann in der zuvor erarbeiteten �Dynamisie-rung der Objekklassi�kation� einfach geschehen, da die Objektklassi�kation durch SQLerfolgt und darin Umbenennungsfunktionen enthalten sind. Soll neben einer �Informati-onsdarstellung auf Wunsch� auch eine dauerhafte Darstellung eines Attributs ermöglichtwerden, so ist dieses Attribut ebenfalls in die Sichtde�nition zu integrieren. Eine solchedauerhafte Darstellung wird meistens bei der punktförmigen Darstellung von Städten ge-nutzt, bei der unter dem Repräsentations-Objekt auch der Name der Stadt dargestelltwird. Damit MapGENeric jedoch weiÿ, welches Attribut dargestellt werden soll, mussdies dem System mitgeteilt werden.

Zusammenfassend kann gesagt werden, dass zur Darstellung von punktförmigen Geo-objekten in MapGENeric lediglich Längen- und Breitengrad benötigt werden. Optionalwerden ID (zur Darstellung weiterer Geoobjekt-Eigenschaften) und ein weiteres Attributfür die Bezeichnung benötigt. Die Sichtde�nition (<GeoObjView>) muss diese Attributebereitstellen. Damit MapGENeric die Spalten der Relation, die durch die Sicht de�niertwird, zuordnen kann, sollten sie diejenigen Namen erhalten, die MapGENeric erwartet.Diese werden de�niert als �mge_id�, �mge_long�, �mge_lat� und �mge_label�. Das Kürzelvor den Bezeichnern wird eingesetzt, um evtl. Namenskon�ikte mit dem DBMS oder derGeodatenbank zu vermeiden. Die erarbeitete Sichtde�nition soll am folgenden Beispieldargestellt werden, das aus der in Tabelle 4.10 dargestellten Relation Hotels mit mehr als200 Betten gruppiert und somit eine Geoobjektklassen-De�nition darstellt:

SELECT

id AS mge_id,

laengengrad AS mge_long,

breitengrad AS mge_lat,

name AS mge_label

FROM

hotels

WHERE

anzahl_zimmer > 200

Das Besondere an solchen Klassende�nitionen durch Sichten ist, dass alle erdenklichenSQL-Anfragen, die auf der darzustellenden Geodatenbank möglich sind, auch für solcheSichtde�nitionen genutzt werden können. Die einzige Restriktion ist, dass der SELECT-Teil zumindest Werte für mge_long und mge_lat bereitstellen muss.

Linienförmige Geoobjekte

Linienförmige Geoobjekte werden in ihrer Modellierung unterteilt in zwei Kategorien

• Einfache Linien,die in der Regel einfache Verbindungen darstellen, wie die zwischen zwei Haltestel-len einer Straÿenbahn (Tabelle 4.7). Dabei wird ihre Geometrie durch ihre beidenEnden de�niert, die in diesem Beispiel der jeweiligen Haltestellen mit ihren Koordi-natenpaaren entsprechen (Tabelle 4.6).


• Linienzügewerden eingesetzt, um beispielsweise den gesamten Verlauf eines Flusses darzustel-len. Dazu muss eine 1:n-Beziehung modelliert sein, wie sie die Tabellen 4.4 und 4.5zeigen.

Zur Darstellung von einfachen Linien, wie sie in Tabelle 4.7 modelliert vorliegen, kannauf zwei Arten vorgegangen werden:

1. Es werden Tupel mit zwei Koordinatenpaaren verlangt, so dass die minimal notwen-digen Attribute einer Sichtde�nition beispielsweise mge_long1, mge_lat1, mge_long2und mge_lat2 werden.

2. Die zwei notwendigen Koordinatenpaare werden aus je einem Tupel erwartet, dieüber ihre GeoobjektID als zusammengehörend identi�ziert werden können.

Zur Darstellung von Linienzügen hingegen ist lediglich die Variante über ein Tupelfür jedes Koordinatenpaar möglich. Wie der Tabelle 4.5 und 4.1 zu entnehmen ist, istdie Menge der Koordinaten zu einem Fluss durch die Spalte �Position� in der Koordi-natentabelle (4.1) als eine geordnete Folge modelliert. Eine Ordnung in der Folge ist fürdie Darstellung eines solchen Linienzugs notwendig, da sonst eine realitätsgetreue Dar-stellung nicht möglich wäre. In der Schemade�nition sorgt das Attribut position für dieOrdnung der Folge, wodurch erst eine korrekte Darstellung des Flussverlaufs erstellt wer-den kann.

Um eine möglichst einheitliche Sichtde�nition zu ermöglichen, wird die für beide Li-nienmodelle (einfache Linien und Linienzüge) nutzbare Variante über mehrere Tupel ge-wählt. Durch diese Wahl und vorangegangene Beobachtungen folgt unweigerlich, dass zurDarstellung linienförmiger Geoobjekte durch MapGENeric ein weiteres Attribut für dieKlassen-Sicht-De�nition zwingend notwendig wird, die die Position des jeweiligen Ko-ordinatenpaares in der Folge wiedergibt. Jedoch ist dieses Attribut für einfache Linienoptional. Zu beachten ist, dass im Gegensatz zur Sichtde�nition der punktförmigen Geo-objekte hier die ID zwingend erforderlich ist, um zusammengehörige Koordinatenpaareidenti�zieren zu können. Es folgt ein Beispiel für die Klassen-Sicht-De�nition �Flüsse�:

SELECT

f.id AS mge_id,

k.laengengrad AS mge_long,

k.breitengrad AS mge_lat,

f.name AS mge_label

fk.position AS mge_seqpos

FROM

flusskoordinaten AS fk,

fluesse AS f

koordinaten AS k

WHERE

f.min_tiefe > 10

AND f.id = fk.fluss_id


Mit dieser SQL-Anfrage würde eine Relation mit Flüssen zurückgegeben werden, die alleFlüsse beinhaltet, die eine Mindesttiefe von 10 Metern haben und somit für groÿe Schi�ebefahrbar sind.

5.4.2 Flächenförmige Geoobjekte

Flächenförmige Geoobjekte werden wie Linienzüge modelliert, bis auf den kleinen Unter-schied, dass das erste und letzte Koordinatenpaar dasselbe sind und somit einen geschlos-senen Linienzug darstellen. Durch die Ordnung in der Folge, die schon bei der Darstellungvon Linienzügen verlangt wurde, werden Darstellungsfehler vermieden.

Für die De�nition einer Geoobjektklasse sind somit zwei Arten von Klassen-Sicht-De�nitionen möglich: Geoobjektklassen mit der Basisklasse Punkt <PunktGeoObjSicht>und Geoobjektklassen mit den Basisklassen Linie oder Fläche <SonstGeoObjSicht>. Ausdiesen Beobachtungen lassen sich folgende Grammatikregeln folgern:

<GeoObjSicht> ::= GEOOBJEKTE ( <PunktGeoObjSicht> ) |

GEOOBJEKTE ( <SonstGeoObjSicht> )

<PunktGeoObjSicht> ::= SELECT

<Attr1> AS mge_id,

<Attr2> AS mge_long,

<Attr3> AS mge_lat,

<Attr4> AS mge_label

FROM

<Tablist>

WHERE

<Bedingung>

<SonstGeoObjSicht> ::= SELECT

<Attr1> AS mge_id,


<Attr3> AS mge_lat,


<Attr5> AS mge_seqpos

FROM

<Tablist>

WHERE

<Bedingung>

Geoobjektklassen sollten eindeutig de�niert werden und Schemaweit eindeutige Na-men besitzen. Die De�nition ihrer Sichten ist ein regulärer SQL-Ausdruck, der über derMenge von Relationen der darzustellenden Geodatenbank de�niert ist. Dies ist jedochmit einer kleinen Einschränkung bzgl. der Attributmenge verbunden, die zurückgegeben


wird. Die Attribute dieser Menge sind mit Name und erwartetem Typ vorgegeben, wo-bei lediglich die Typen für mge_seqpos (ganze Zahlen), Längen- und Breitengrad (reelleZahlen) fest erwartet werden. Für mge_id ist lediglich gefordert, dass dieses Attribut eineindeutiger Schlüssel ist, der das Geoobjekt identi�ziert unabhängig davon, ob es eineZahl oder ein String ist. Bei mge_label ist es ebenfalls irrelevant, ob Zahl oder String zu-rückgegeben wird. Die Nonterminale <Attr1> bis <Attr5> stellen die Pendants zu diesenerwarteten Attributen dar und müssen durch die Attributnamen der Relationen ersetztwerden, die in <Tablist> stehen, die wiederum aus der darzustellenden Geodatenbankstammen. Dabei ist natürlich zu beachten, dass <Attr1> den eindeutigen Schlüssel �ID�des Geoobjektes liefert, <Attr2> den Längengrad, <Attr3> den Breitengrad, <Attr4>den Bezeichner und <Attr5> die Position des Koordinatenpaars in der Folge des Linien-zugs. Für <Bedingung> kann jede in SQL zulässige Bedingung eingetragen werden, dieüber die in <Tablist> aufgeführten Relationen de�niert ist.

Für die Geoobjektklassen-De�nition ist neben der Geoobjekt-Sicht eine Sicht auf dieAttribute der durch die Geoobjekt-Sicht gruppierten Geoobjekte notwendig. Dies ist einoptionales Element der Geoobjektklassen-De�nition, die ausschlieÿlich für die Interakti-onskomponente des Systems benötigt wird, um weitere nicht-graphische Eigenschafteneines ausgewählten Geoobjekts auf Anfrage darstellen zu können.

Die Geoobjekte-Sicht liefert ausschlieÿlich die für die Darstellung der Repräsentations-Objekte notwendigen Daten. Die Relation, die von dieser Sicht de�niert wird, enthält dieDaten einer Menge von Geoobjekten, die das Kriterium im WHERE-Teil dieser Sicht er-füllen. Sollen auf Anfrage nicht-graphische Attribute dieser Geoobjekte dargestellt werdenkönnen, so ist eine Relation mit diesen nicht-graphischen Attributen notwendig, in derdiese Attribute des gewünschten Geoobjekts eindeutig identi�ziert werden können. Dazumuss die Attribut-Sicht eine Spalte enthalten, die einen Fremdschlüssel zur Geoobjekte-Sicht darstellt. Auf Wunsch eines Kartennutzers nach mehr Informationen zu einem Geo-objekt, könnte MapGENeric, auf die durch diese Attribut-Sicht de�nierte Relation, eineSQL-Anfrage stellen mit dem bekannten Schlüssel �Id� des Geoobjekts. Der Spaltennamedieser Attribut-Sicht, der den Fremdschlüssel bereithält, muss MapGENeric bekannt seinund wird deshalb als �mge_id� vorausgesetzt.

Dafür müsste die Grammatikregel-De�nition für die Attribut-Sicht folgendermaÿenaussehen:

<AttribSicht> ::= ATTRIBUTE () |

ATTRIBUTE (

SELECT

<Attr1> AS mge_id,

<Attributliste>

FROM

<Tablist>

)


<Attr1> müsste den Namen der Spalte in der Geodatenbank enthalten, die den Fremd-schlüssel darstellt zur Relation, die durch die Geoobjekte-Sicht de�niert wurde. Dies sollan einem Beispiel verdeutlicht werden. Dazu soll erneut die Tabelle 4.10 mit den Ho-tels betrachtet werden. Beispielhaft könnte eine Geoobjekte-Sicht, wie folgend de�niertwerden, die alle Hotels in dieser Relation gruppiert, die mehr als 200 Betten bieten:

GEOOBJEKTE ( SELECT

id AS mge_id,



name AS mge_label

FROM

hotels

WHERE

anzahl_betten > 200

)

Ein Attribut-Sicht-Beispiel dazu:

ATTRIBUTE ( SELECT

id AS mge_id, *

FROM

hotels

)

Diese Attribut-Sicht de�niert eine Relation, die als Fremdschlüssel-Spalte �mge_id� undalle anderen Spalten der Relation �hotels� hat. Dadurch ist es MapGENeric möglich, aufdiese Relation eine SQL-Anfrage der folgenden Form zu stellen, da der Schlüssel des Geo-objekts bekannt ist, der durch den Nutzer ausgewählt wurde. Ferner ist dem System dieFremdschlüssel-Spalte bekannt, da diese in der Grammatik-De�nition des Nonterminals<AttribSicht> de�niert wurde:

SELECT * FROM ( SELECT

id AS mge_id, *

FROM

hotels

)

WHERE mge_id = [X];

Das im Code-Fragment dargestellte [X] müsste von MapGENeric durch die Geoobjekt-IDersetzt werden, die durch die Nutzer-Aktion ermittelt würde. Dadurch würde für diesesBeispiel eine einzeilige Relation entstehen, die beispielsweise wie folgend aussehen würde:


2 Luxor 248 199 7,10554 50,73870

Würde diese Tabelle in dieser Form dem Kartennutzer dargestellt werden, wüssteer nicht, welcher Wert welche Bedeutung hätte. Deshalb muss vom Kartenautor eineDe�nition für <Attributliste> gefordert werden, die eine Beschreibung der Werte mitsich bringt:

ATTRIBUTE ( SELECT

id AS mge_id,

'Hotelname: ' , name,

'Anzahl der Betten: ' , anzahl_betten,

'günstigster Preis: ' , preis

FROM

hotels

)

Diese Attribut-Sicht-De�nition hätte bei zuvor dargestellter SQL-Anfrage durch Map-GENeric folgende Resultat-Relation:

2 Hotelname: Luxor Anzahl der Betten: 248 günstigster Preis: 199

Eine solche auch zuvor unbekannte Relation, die einem bestimmten Schema (womitkein Datenbankschema gemeint ist) entspricht, könnte durch ein System wie MapGENerickomfortabel dargestellt werden, indem nach der ID die Werte für je zwei Spalten neben-einander und darauf ein Zeilenumbruch folgend dargestellt werden (Abbildung 5.1).

Abbildung 5.1: Info-Fenster für nicht-graphische Attribute

Kapitel 6

Architektur und Funktionalität von

MapGENeric

In diesem Kapitel wird zunächst die Gesamtarchitektur des MapGENeric-Systems vor-gestellt werden. Ferner wird die Struktur und die Funktionalität der Schnittstellen vonMapGENeric diskutiert werden. Hierzu zählen Autoren- und Nutzer-Schnittstelle mit ih-ren spezi�schen Funktionalitäten, die in Kapitel 4.2.2 erarbeitet wurden. Die schrittweiseKonstruktion einer Karte durch einen Kartenautor wird genutzt, um die Komponentenfür die Autoren-Schnittstelle mit Struktur und Funktionalität detailliert darzustellen.

6.1 MapGENeric-Architektur im Kontext

In Kapitel 4 ist ein System entworfen worden, das unabhängig von Anwendung und Daten-bank 2D-Bildschirmkarten generieren kann. Der Map Generator ist die Hauptkomponentein diesem System. Im Rahmen dieser Arbeit wurden des weiteren für die beiden zuvoridenti�zierten Akteure (siehe Kapitel 4.4) im MapGENeric-System graphische Ober�ä-chen entwickelt, die deren Bedürfnissen gerecht werden. Da eine Datenbankunabhängigkeitgefordert war, ist eine Schnittstellenarchitektur für die Datenbankanbindung umgesetztworden, auf die nicht weiter eingegangen wird. Aus diesen Komponenten heraus ist dasin Abbildung 6.1 sichtbare Gesamtsystem entstanden.

Die MapGENeric-Architektur erlaubt über unterschiedliche DBMS die Anbindungverschiedener Geodatenbanken. Diese Geodatenbanken wiederum enthalten für unter-schiedliche Anwendungen Daten der darzustellenden Geoobjekte. Mit �Anwendungen�sind unterschiedliche Einsatzgebiete für MapGENeric gemeint, wie beispielsweise Stras-sennetzkarte für PKW-Fahrer, Stadtführer für Touristen oder Umweltbelastungspläne fürUmweltbeauftragte. Um Geoobjekte anwendungsbezogen durch MapGENeric darstellenzu können, muss MapGENeric für jede Anwendung separat kon�guriert werden. Dabeikönnen u.U. auch unterschiedliche Anwendungen auf derselben Geodatenbank basieren,wie im Touristik/Umwelt-Beispiel aus dem letzten Kapitel. Dort wurden verschiedeneGeoobjekte aus einer Geodatenbank auf unterschiedlichen Karten dargestellt, wie Touris-tenkarte und Umweltkarte. Jedoch wurde auch auf die Notwendigkeit hingewiesen, dassdieselben Geoobjekte in unterschiedlichen Anwendungen (Touristenkarte I und Touris-

77

78 Kapitel 6. Architektur und Funktionalität von MapGENeric

Abbildung 6.1: MapGENeric im Kontext

tenkarte II) verschieden dargestellt werden können. Diese anwendungsspezi�schen Kon-�gurationen werden vom Kartenautor über ein Kartenautor-GUI eingegeben und in derjeweiligen Geodatenbank gespeichert.

Um das Ergebnis der Kon�guration sehen zu können, steht dem Kartenautor dieNutzer-GUI ebenfalls zur Verfügung. Die Nutzer-GUI stellt die Karte dar, wie sie durchden Map Generator unter Berücksichtigung der Visualisierungs-Regeln erstellt wurde.Ferner dient sie dem Kartennutzer als Eingabemaske für Darstellungsparameter (wie dar-gestellter Realweltausschnitt, Layer-Reihenfolge, Navigation, Zoom, usw.).

Diese Darstellungsparamter werden über den InteractionManager an den Map Gene-rator weitergeleitet. Der InteractionManager stellt dabei eine Schnittstelle zwischen derNutzer-GUI und dem Map Generator dar, die Ergebnisse der zum Map Generator wei-tergeleiteten Parameter zurück zum Nutzer-GUI leitet.

Über den DataManager kommuniziert MapGENeric mit der externen KomponenteADO.NET, die Klassen für die Kommunikation mit unterschiedlichen DBMS bereithält.Ferner unterstützt ADO.NET die Anbindung verschiedener Geodatenbanken, die durchdiese DBMS verwaltet werden. Der DataManager erlaubt über ADO.NET schreibendenund lesenden Zugri� auf die Geodatenbanken, wie sie zur Speicherung der Kon�guratio-nen und zum Auslesen der Informationen zum Erstellen der Karte erforderlich sind.

Im Kern der vorgestellten Architektur agiert der Map Generator. Dieser ist zuständigfür die Generierung, der durch das Nutzer-GUI angeforderten Bildschirmkarte unter Be-rücksichtigung der über das Kartenautor-GUI eingegebenen Kon�gurationen. Dazu wer-den diese Kon�gurationsdaten über den DataManager angefordert. Der Map Generatorarrangiert in diesen Kon�gurationsdaten spezi�zierte Geoobjektdaten, die ebenfalls überden DataManager angefordert werden, zu einer Bildschirmkarte. Diese Bildschirmkartegelangt daraufhin über den InteractionManager wieder zum Nutzer-GUI.

6.2 Autoren-Schnittstelle 79

6.2 Autoren-Schnittstelle

Von MapGENeric wird erwartet, dass es unabhängig von Datenbankschema Geoobjekteaus relationalen Geodatenbanken als graphische Objekte auf einer Bildschirmkarte dar-stellen kann. Dabei soll es möglich sein, die Darstellungsform der Geoobjekte jederzeitändern zu können. Es wurde zuvor in Kapitel 4.3 gezeigt, dass eine Kon�guration desSystems notwendig ist, um diese Funktionalität bieten zu können. Zu dieser Kon�gu-ration gehören Geoobjektklassen, Darstellungsformen und Layer (siehe Kapitel 4.4.1).Es wurden zwei Akteure in MapGENeric identi�ziert, von denen der Kartenautor fürdiese anwendungsspezi�sche Kon�guration zuständig ist. Er ist für die De�nition derGeoobjektklassen, der Layer, der Darstellungsformen und für die Zuweisung zueinandermit Hilfe der Visualisierungs-Regeln verantwortlich. Diese De�nitionen werden über dasKartenautor-GUI eingegeben und über den Con�gManager mit Hilfe des DataManagersin der jeweiligen Geodatenbank gespeichert.

Die graphische Benutzerober�äche für Kartenautoren besteht aus einem Hauptfenster,das als so genannter Assistent umgesetzt wurde. Assistenten bündeln einzelne Schritte ei-nes gesamten Ablaufs von zusammenhängenden Interaktionen in einem einzigen Fenster.Diese Schritte werden dann in einer bestimmten Reihenfolge zur Bearbeitung angezeigtund mit erklärenden Texten unterstützt. Im Fall von MapGENeric sind dies die ver-schiedenen Schritte, die zur Kon�guration des Systems für eine bestimmte Anwendungnotwendig sind, wie Geodatenbank auswählen, Kon�guration erstellen/bearbeiten, usw.(Abb. 6.2). Dieser Assistent wird im folgenden Kon�gurationsassistent genannt. Strukturund Funktionalität der Autoren-Schnittstelle wird im folgenden durch die Kon�gurationvon MapGENeric für das in Kapitel 4 eingeführte Touristik/Umwelt-Beispiel beschriebenwerden.

6.2.1 Geodatenbank wählen

Der erste Schritt der Kon�guration dient dem Kartenautor zur Identi�zierung derjeni-gen Geodatenbank, aus der er Geodaten mit Hilfe von Visualisierungs-Regeln zu einerBildschirmkarte arrangieren möchte. Hier steht unter �GeoDatabase� ein Textfeld zurVerfügung, in dem der Pfad und der Dateiname der zu visualisierenden Geodatenbankeingegeben werden kann (Abb. 6.3). Ferner ist optional die Möglichkeit gegeben, einenBenutzernamen und ein Passwort einzugeben, wenn die Geodatenbank passwortgeschütztist. Die Geodatenbank kann auch komfortabel über die �Select�-Taste ausgewählt werden.Hierzu ö�net sich eine so genannte DialogBox, die es erlaubt, im Dateisystem des Com-puters, auf dem MapGENeric ausgeführt wird, nach der jeweiligen Geodatenbank (z.B.:TouristikUmweltGeoDB.mdb) zu suchen.

Ein Klick auf �Next �� veranlasst eine Prüfung der Verbindung zur ausgewähltenGeodatenbank. Bei positivem Ergebnis werden eventuell vorhandene Kon�gurationsdatenüber den Data Manager angefordert. Diese Kon�gurationsdaten werden im Hauptspei-cher gehalten, um sie den folgenden Komponenten zur Verfügung stellen zu können. Beierfolgreichem Abschluss des Kon�gurationsassistenten werden diese evtl. geänderten oderergänzten Kon�gurationsdaten in diese Geodatenbank propagiert.


Abbildung 6.2: Architektur der Autoren-Schnittstelle


Abbildung 6.3: Kon�gurations-Assistent � Datenbankauswahl

6.2.2 Geoobjektklassen erstellen/bearbeiten

In Kapitel 4 und 5 wurde gezeigt, dass die Gruppierung von Geoobjekten, die gleichdargestellt werden sollen, an Hand gemeinsamer Attribute durch sogenannte �Sichten�auf Datenbanken verwirklicht werden können. Diesen Geoobjektklassen können durchdas Visualisierungs-Mapping Darstellungsformen zugewiesen werden. Da zu Geoobjektennicht nur deren Gestalt wichtig ist, sondern auch ihre nicht-graphischen Eigenschaften, istes in dieser Kartenautor-GUI-Komponente (Abb. 6.4) möglich, für jede Geoobjektklasseeine weitere DB-View zu de�nieren, die diese Eigenschaften repräsentiert. Diese könntenbeispielsweise Name und Ö�nungszeiten zu Museen sein.

Vorhandene Geoobjektklassen werden unter �Geoobjekt-Classes� aufgelistet (Abb. 6.4).Werte einer ausgewählten Geoobjektklasse aus dieser Liste werden unter �Selected Geo-object-Class� dargestellt. Zu diesen Werten gehören, wie bei der Modellierung in Kapitel4.4.1 dargestellt, Name, Basistyp, Sichtde�nition für Geoobjekte und Sichtde�nition fürderen Attribute (nichtgraphische Eigenschaften). Werden Änderungen an diesen Wertenvorgenommen, so können diese über die �Save�-Taste gesichert werden. Sollen neue Geo-objektklassen de�niert werden, kann dies durch Klicken der �New�-Taste erfolgen, was zurFolge hat, dass die Eingabefelder unter �Selected Geoobject-Class� geleert werden und


Abbildung 6.4: Kon�gurations-Assistent � Geoobjektklassen

darin neue Werte eingegeben werden können. Diese neue De�nition kann durch �Save� ge-speichert werden und erscheint daraufhin in der Liste unter �Geoobjekt-Classes�. Bei derDe�nition der neuen Geoobjektklasse sind die bei der Modellierung erarbeiteten Integri-tätsbedingungen zu beachten. Beispielsweise sind Namen für Geoobjektklassen eindeutigzu vergeben und Geoobjektklassen unterschiedlicher Basisklassen bedürfen verschiedenerSicht-Schemata. Beispielhaft folgt die De�nition der Klassen für Straÿenbahnhaltestellen,Straÿenbahnlinien und CO2-Belastung, wie sie auf den Karten in den Abbildungen 4.2,4.3 und 4.4 dargestellt sind. Diese Sicht-De�nitionen basieren auf den Relationen, die imTouristik/Umweltbeispiel genutzt wurden (Kapitel 4.1.1).

Die für jede Basisklasse notwendigen Sicht-Schemata werden im folgenden durch diePräsentation von Beispielen für diese drei Geoobjektklassen erläutert. Wie zuvor in Kapi-tel 4.4 erarbeitet, wird bei der Sicht-De�nition auf den CREATE VIEW ...-Teil verzichtet.Dies ist möglich, da MapGENeric keine durch das DBMS verwaltete Sicht-De�nition,wie im herkömmlichen Sinne benötigt. Vielmehr handelt es sich hierbei um systeminter-ne Sichten, die MapGENeric zur Gruppierung von Geoobjekten benötigt, denen durchVisualisierungs-Regeln einheitliche Darstellungsformen zugewiesen werden können.


Für die Gruppierung von Straÿenbahnhaltestellen zu einer solchen einheitlichen Dar-stellung werden durch die �Add�-Taste evtl. gefüllte Eingabefelder geleert. Im Eingabefeldfür Name wird zunächst �Straÿenbahnhaltestellen� eingetragen und darauf folgend die Ba-sisklasse �Punkt� unter BaseType gewählt. Für punktförmig darzustellende Geoobjektesind die Attribute Objekt_ID (id), Längengrad (long) und Breitengrad (lat) notwendig.Um die graphische Darstellung dieser Geoobjekte auch beschriften zu können, ist einweiteres Attribut notwendig: Beschriftung (label). Um eventuelle Namenskon�ikte mitAttributen der GeoDaten zu vermeiden, wurde den Attributen �mge_� fürMapGENericvorgestellt. Im Eingabefeld �Geoobjects-Class-View� ist basierend auf Tabellen aus Kapi-tel 4.1.1 folgende Sicht-De�nition einzugeben:

SELECT

id AS mge_id,



name AS mge_label

FROM

Strassenbahnhaltestellen

Um zuvor erwähnte nicht-graphische Eigenschaften der Geoobjekte auf Abruf darstel-len zu können, ist eine weitere Sicht-De�nition notwendig. Dabei ist zu beachten, dass dieRelation zwischen dieser Sicht und der zuvor de�nierten Geoobjektklassen-Sicht durchdas gleiche Attribut �id� (mge_id) gewährleistet ist, d.h., dass diese neue Attribut-Sichtmit einem Freumdschlüssel auf die Geoobjektklassensicht zu de�nieren ist. Für Attributedieser Geoobjektklasse sollte eine Sichtde�nition im Eingabefeld �Geoobject-Attributes-View�, wie folgend eingetragen werden:

SELECT

id AS mge_id,

'Name: ' , name,

'Kapazität: ', kapazitaet,

'Linien #: ' , anzahl_linien

FROM

Strassenbahnhaltestellen

Um diese Geoobjektklassen-De�nition zu speichern, muss die �Save�-Taste betätigtwerden. Für die Gruppierung der Straÿenbahnlinien ist erneut die �Add�-Taste anzuklickenund im Eingabefeld Name �Straÿenbahnlinien� einzutragen. Als Basistyp wird �Linie�gewählt. Unter �Geoobjects-Class-View� wird folgende Sicht-De�nition eingetragen:

SELECT

sbts.id AS mge_id,

sbhs.laengengrad AS mge_long,

sbhs.breitengrad AS mge_lat,

sbts.max_speed AS mge_label,

sbhs.id AS mge_seqpos

FROM


Strassenbahnteilstrecke AS sbts,

Strassenbahnhaltestellen AS sbhs

WHERE

sbhs.id = sbts.haltestelle_id1

OR sbhs.id = sbts.haltestelle_id2

An dieser Sicht-De�nition ist zu sehen, dass ein weiteres Attribut für die Darstel-lung von Linien einge�ossen ist: mge_seqpos. Dieses Attribut dient bei linienförmigenGeoobjekten zur korrekten Darstellung, da es die Richtung für gerichtete linienförmigeGeoobjekte de�niert, und bei Linienzügen die korrekte Reihenfolge darstellt. Beispielhaftist eine Ergebnistabelle dieser Sicht in Tabelle 6.1 dargestellt.

mge_id mge_long mge_lat mge_label mge_seqpos1 50,74044 7,10616 50 11 50,73996 7,10247 50 22 50,73996 7,10247 70 22 50,75555 7,11303 70 4: : : : :

Tabelle 6.1: Straÿenbahnlinien-Sicht-Ergebnis

In dieser Ergebnisrelation ist zu sehen, dass eine Linie durch zwei Zeilen de�niertwird, die ihren Anfangs- und Endpunkt darstellen. Die zur korrekten Darstellung lini-enhafter Geoobjekte notwendige geordnete Folge von Punkten wird in diesem Beispielkünstlich erzeugt, indem die Haltestellen-ID hierfür genutzt wird. Dies ist hier möglich,da die Haltestellen in der Relation in geordneter Reihenfolge stehen. Bei Geoobjekten,die in den darzustellenden Geodatenbanken als Linienzüge modelliert sind, werden dieseGeoobjekte durch zwei oder mehr Zeilen de�niert, je nachdem aus wievielen Punkten siebestehen. Dies wird bei der De�nition der Geoobjektklasse für CO2-Belastungen im nächs-ten Beispiel deutlich. Im folgenden wird ausschlieÿlich die Sicht-De�nition erläutert, dadas Prinzip der Geoobjektklassen-De�nition durch die beiden vorangegangenen Beispieledeutlich geworden ist.

SELECT

umwb.id AS mge_id,

vkoords.laengengrad AS mge_long,

vkoords.breitengrad AS mge_lat,

'' AS mge_label,

koords.position AS mge_seqpos

FROM

Koordinaten AS koords,

Umweltbelastungen AS umwb,

Verschmutzungskoordinaten AS vkoords

WHERE

umwb.art = 'CO2-Konzentration'

AND umwb.id = vkoords.umweltbelastung_id

AND vkoords.koord_id = koords.id


Wird diese Sicht-De�nition auf die Relationen im Touristik/Umwelt-Beispiel angewandt,so entsteht eine Ergebnisrelation, in der CO2-Belastungen �ächenhaft durch mehrere Zei-len repräsentiert werden. Diese Zeilen wiederum de�nieren Punkte eines Linienzuges,der diese Fläche begrenzt. Die Zusammengehörigkeit der Zeilen wird durch die gleichemge_id gewährleistet. Um einen Darstellungsfehler zu vermeiden, die durch eine falscheReihenfolge der Punkte entsteht, wird auch hier das Attribut mge_seqpos erwartet.

Links unten auf der Eingabemaske taucht das erste Mal die Taste �� Back� auf, diein den folgenden Komponenten auch erscheinen wird. Sie dient dem Kartenautor dazu,sich in der Schrittfolge der Kon�guration rückwärts bewegen zu können. Dies kann er-forderlich sein, wenn der Kartenautor beispielsweise im vorangegangenen Schritt etwasvergessen hat. Wird diese Taste betätigt, hat das auch wie �Next �� zur Folge, dass diebearbeiteten Felder durch den Con�gManager auf Integrität geprüft und bei positivemErgebnis gespeichert werden.

6.2.3 Darstellungsformen erstellen/bearbeiten

Um Geoobjekte graphisch auf einer Bildschirmkarte zeichnen zu können, benötigt Map-GENeric Darstellungsformen, wie sie in Kapitel 4.4.1 modelliert wurden. Die Komponentedes Kon�gurations-Assistenten zum Erstellen und Bearbeiten solcher Darstellungsformenist in drei Bereiche unterteilt. Für jede Basisklasse (Punkt, Linie, Fläche) ist ein separaterBereich reserviert (Abb. 6.5). Sind Darstellungsformen bereits vorhanden, werden sie inder jeweiligen Liste angezeigt. Für diese Listen werden die Funktionen Bearbeiten (Edit),Löschen (Delete) und Hinzufügen (Add) bereitgestellt. Für jede Basisklasse werden dieseFunktionen in unterschiedlichen Fenstern angeboten, da sie unterschiedliche Darstellungs-variablen unterstützen müssen.

Die für das Touristik/Umwelt-Beispiel notwendigen Darstellungsformen sind in Abb.6.5 teilweise dargestellt. Beispielhaft folgt die De�nition der Darstellungsformen für dieim letzten Schritt (Step 2 of 5) erstellten Geoobjektklassen Straÿenbahnhaltestellen, Stra-ÿenbahnlinien und CO2-Belastung, wie sie auf den Karten in den Abbildungen 4.2, 4.3und 4.4 dargestellt sind.

Über die �Add�-Taste für Punkt-Darstellungsformen ö�net sich eine Eingabemaske,in der eine neue Darstellungsform für punktförmige Geoobjekte de�niert werden kann.Die Funktionalität dieser Eingabemaske soll im folgenden am Beispiel der Darstellungs-form eines hellblauen Kreises für Straÿenbahnhaltestellen (siehe Beispielkarte in Abb.4.2) erläutert werden. Die Eingabemaske für Punkt-Darstellungsformen bietet eine Tastefür die Farbauswahl, die durch einen Klick ein weiteres Fenster ö�net, das einige vor-de�nierte Farben und Eingabefelder für die Farbwerte rot, grün und blau bietet. Wirdin diesem Fenster beispielhaft eine hellblaue Farbe ausgewählt, so kann dies durch die�Ok�-Taste bestätigt werden, wodurch sich das Fenster für die Farbauswahl schlieÿt unddas Eingabefenster für Punkt-Darstellungsformen in den Vordergrund tritt. Unter �Vor-der�nierte Formen� bietet dieses Eingabefenster eine Auswahl an vorde�nierten Formen,Kreis, Dreieck, Rechteck, wie sie in Kapitel 4.2.1 gefordert wurde. Für die Beispielde�-nition der Straÿenbahnhaltestelle würde aus dieser Auswahl der Kreis gewählt werden.


Abbildung 6.5: Kon�gurations-Assistent � Darstellungsformen

In die Eingabefelder für Breite und Höhe sollte der selbe Wert eingegeben werden, dadie Darstellungsform andernfalls eine elliptische Form annehmen würde. Für das Beispielwürde der Wert fünf gewählt werden. Das Eingabefenster für Punkt-Darstellungsformenbietet des weiteren einen Schieberegler für die Transparenz der Darstellungsform an, derfür das Beispiel bei 255 beibehalten werden sollte. Das Eingabefeld für ein Bitmap, durchdas punktförmige Geoobjekte in MapGENeric auch dargestellt werden können, würde indiesem Fall freigelassen werden. Sollten Haltestellen durch Bitmaps dargestellt werden,so müsste in das Feld unter �Bitmap� ein Verzeichnispfad eingegeben werden der zu ei-nem Bitmap führt. Durch einen Klick auf �Ok� wird die De�nition der Darstellungsformgespeichert, das Fenster geschlossen und die neue Darstellungsform in der Liste für punkt-förmige Darstellungsformen dargestellt.

Für die Darstellungsform der Straÿenbahnlinien wird über die �Add�-Taste unter lini-enförmige Darstellungsformen eine andere Eingabemaske geö�net. Auf dieselbe Art wiezuvor wird die Farbe hellblau für die Linie gewählt und Transparenz bei 255 belassen. Fürlinienförmige Geoobjekte wurde zuvor bei der Modellierung gefordert, dass sie Pfeilspit-zen, Kreise oder Rechtecke für Linienanfang und -ende erhalten sollten, um beispielsweiseEinbahnstraÿen, Sackgassen mit und ohne Wendemöglichkeit darzustellen. Das Eingabe-fenster für die De�nition von Linien-Darstellungsformen bietet dies an in Form von je


einer Auswahlbox für den Anfang und das Ende der Linie. Für das Beispiel werden sie aufden Standardeinstellungen belassen wie auch Linienmuster und -form. Für die Darstellungder Eisenbahnstrecke im Touristik/Umwelt-Beispiel kann unter Linienmuster ein gestri-cheltes Muster gewählt werden (siehe mittlere Spalte in Abbildung 6.5). Zuletzt muss eineLinienbreite festgelegt werden, die für das Beispiel mit drei Pixeln ausreichend ist. Auchhier wird durch einen Klick auf �Ok� die neue Darstellungsform gespeichert und daraufhinin der zugehörigen Liste dargestellt.

Die Darstellung der Umwelt-Belastungen ist eine �ächenförmige Darstellungsform, dieüber die �Add�-Taste für �ächenhafte Darstellungsformen de�niert werden kann. In dersich ö�nenden Eingabemaske wird wie zuvor über einen Farbbutton eine Farbe gewählt(für das Beispiel: schwarz). Die Transparenz wird auf 80 gestellt. Die Eingabe�äche fürein Bitmap wird hierfür frei gehalten, ganz im Gegensatz zur De�nition der Laub- undNadelwalddarstellung, für die hier der Pfad zu einem Bitmap stehen muss. Um Grenzenvon �ächenhaften Geoobjekten deutlich machen zu können, ist unter �Border� eine Linieauszuwählen, die um das �ächenhafte Geoobjekt gezeichnet werden soll. Hierzu werdenalle für diese Geodatenbank de�nierten Linien-Darstellungsformen zur Auswahl in einerAuswahl-Box angeboten. Durch �Ok� wird die neue De�nition übernommen und das Fens-ter geschlossen.

Wenn für jede Basisklasse mindestens eine Darstellungsform vorliegt, kann durch die�Next ��-Taste mit dem nächsten Schritt fortgefahren werden.

6.2.4 Visualisierungs-Regeln erstellen/bearbeiten

Der vierte von fünf Schritten des Arbeitens mit dem Kon�gurations-Assistenten ist dieRegel-Kon�guration. Komponenten der MapGENeric-Kon�guration, die in den vorange-gangenen Schritten de�niert und bearbeitet werden konnten, können hier zu Visualisierungs-Regeln zusammengefasst und benannt werden, wie in Kapitel 4.4 beschrieben. Es er-scheinen verschiedene Visualisierungs-Regeln mit ihren Namen in der Liste unter �VisRu-les�(siehe Abbildung 6.6), wenn bereits Regeln vorhanden sind. Die Werte einer Regel,die in dieser Liste ausgewählt wird, erscheinen in der Eingabemaske �VisRule-De�nition�und können hier bearbeitet werden. Werden Werte einer Regel bearbeitet, so kann dieseÄnderung durch den �Save�-Button gesichert werden.

Soll eine neue Regel erstellt werden, kann dies durch einen Klick auf die �Add�-Tasteerfolgen. Das hat zur Folge, dass Eingabefelder der �VisRule-De�nition� geleert werdenund hier neue Werte ausgewählt und eingetragen werden können. Die De�nition einerneuen Visualisierungs-Regel beginnt mit ihrem Namen, die unter �VisRules� noch nichtvorhanden sein darf. Als nächstes muss die Geoobjektklasse, deren Geoobjekte dargestelltwerden sollen, ausgewählt werden. Je nachdem welcher Basisklasse diese ausgewählte Geo-objektklasse angehört, werden unter �Viewshape� mögliche Darstellungsformen angezeigt,aus denen eine zu wählen ist. Mit �Save� wird die De�nition einer neuen Visualisierungs-Regel abgeschlossen und gesichert.


Abbildung 6.6: Kon�gurations-Assistent � Visualisierungs-Regeln

6.2.5 Kon�gurationen erstellen/bearbeiten

Im Touristik/Umwelt-Beispiel ist der Wunsch entstanden, mehrere Kon�gurationen füreine Geodatenbank erstellen zu können, so dass dieselben Geoobjekte nach Bedarf un-terschiedlich dargestellt werden können (Touristenkarte und Touristenkarte II). Um dieseFunktionalität bieten zu können, ist die De�nition und das Bearbeiten unterschiedlicherKon�gurationen im linken Teil der in Abb. 6.7 sichtbaren Eingabemaske unter �Con�gu-ration� möglich. Diese Eingabemaske bietet die Möglichkeit, Kon�gurationen zu erstellen,umzubenennen und zu entfernen.

Die Karten aus den Abb. 4.2, 4.3 und 4.4 basieren alle auf derselben Geodatenbank.Da sie alle unterschiedliche Anwendungen darstellen, werden unterschiedliche Kon�gura-tionen benötigt. Diese können im zweiten Schritt des Kon�gurations-Assistenten erstelltwerden. Dazu ist es nötig, in die linke Eingabezeile neben der �Add�-Taste einen neuenNamen einzugeben und diesen durch einen Klick mit der Maus auf diese Taste zu bestä-tigen. Für das oben genannte Beispiel wäre diese Aktion dreimal zu wiederholen, jeweilsfür Touristenkarte, Touristenkarte II und Umweltkarte. In Abb. 6.7 ist zu sehen, dassgerade die Kon�guration �Umweltkarte� erstellt wird. Falls die eine oder andere Kon�-guration bereits für die zuvor ausgewählte Geodatenbank existiert, werden diese unter


Abbildung 6.7: Kon�gurations-Assistent � Kon�guration

�Con�guration� aufgelistet. Bei Bedarf ist es möglich eine Kon�guration aus dieser Listeauszuwählen und zu löschen (über �Delete�) oder in einem separaten Fenster den Namenzu Bearbeiten (über �Edit�).

Im Abschnitt �Layer� in Kapitel 4.4.1 wurden Regeln so modelliert, dass sie mehre-ren Kon�gurationen zugewiesen werden können, um zu vermeiden, dass für verschiedenesich ähnelnde Anwendungen auf derselben Geodatenbank dieselbe Regel mehrfach de-�niert werden muss. Regeln die einer unter �Con�guration� selektierten Kon�gurationzugewiesen sind, werden in der mittleren Liste unter �Con�g-VisRules� aufgelistet. Fürdie Zuweisung einer unter �VisRules� ausgewählten Regel zu einer ausgewählten Kon�gu-ration ist das Klicken auf die �⇐�-Taste erforderlich.

In Kapitel 4.4.1 wurde ferner festgestellt, dass eine Zeichenreihenfolge, in der Geoob-jekte gezeichnet werden, notwendig ist, um unerwünschte Überlagerungen der Geoobjektevermeiden zu können. Diese Zeichenreihenfolge wurde für Regeln abhängig davon, in wel-cher Kon�guration sie zum Einsatz kommen, de�niert. Die Darstellung der Regeln erfolgtin der mittleren Liste (Con�g-VisRules) in ihrer Zeichenreihenfolge. Die Position in derZeichenreihenfolge einer in der mittleren Liste ausgewählten Regel kann durch die �Up�und �Down�-Tasten nach oben und unten verändert werden . Die oberste Regel in dieser


Liste mit einem Häkchen davor wird als erstes angewandt, dem weitere Regeln mit Häk-chen in der Liste folgen. Das vorangestellte Häkchen stellt die �Sichtbarkeit� dieser Regelin der jeweiligen Kon�guration dar, die bei neu zugewiesenen Layern automatisch gesetztwird.

Um die Kon�guration von MapGENeric für die unter Schritt 1 von 5 gewählten Geo-datenbank abschlieÿen zu können, muss nur noch die �Finish !�-Taste betätigt werden.Daraufhin werden die auf diese Weise entstandenen Kon�gurationen in die jeweilige Geo-datenbank propagiert, sofern alle Schritte der Kon�guration erfolgreich waren.

6.3 Nutzer-Schnittstelle

Der Kartennutzer sollte die Karte so dargestellt bekommen, wie es vom Kartenautormit Hilfe des Kon�gurations-Assistenten bestimmt wurde. Wie bei der Konzeption derBildschirmkarte festgestellt, ist für den Kartennutzer ebenfalls eine graphische Ober�ächeerforderlich, um Layer ein- oder auszublenden, ihre Zeichenreihenfolge zu ändern, den dar-zustellenden Realwelt-Ausschnitt zu verändern und weitere Informationen zu bestimmtenGeoobjekten anzufordern (siehe Kapitel 4.2.2). Im folgenden sollen Struktur und Funk-tionalität dieser Nutzer-Schnittstelle beschrieben werden. Der Begri� �Layer� wird hierwieder eingeführt und im weiteren genutzt für die Gesamtheit der durch eine Regel de�-nierten Repräsentations-Objekte.

Das Kartennutzer-GUI besteht aus einem Hauptfenster, das sich beim Start des Pro-gramms MapGENeric ö�net (Abb. 6.8). Dieses Fenster ist unterteilt in zwei Bereiche,Bereich A (schmaler Bereich auf der linken Seite) und Bereich B (breiter Bereich auf derrechten Seite). Über diesen zwei Bereichen ist das Hauptmenü zu �nden. Dieses Menü istunterteilt in �User�, �Administration� und �Help�. Über �User� ist der Punkt �Select DB�zu erreichen. Ein Klick auf diesen Menüpunkt ö�net ein Dateiauswahlfenster, mit dessenHilfe der Nutzer eine Datenbank ö�nen kann. Handelt es sich bei der Datenbank um eineGeodatenbank, die verschiedene zuvor von einem Kartenautor erstellte Kon�gurationenbeinhaltet, so werden diese Kon�gurationen zur Auswahl angeboten. Entscheidet sich derNutzer für eine dieser Kon�gurationen, dann wird in Bereich B des Hauptfensters dieKarte mit dieser Kon�guration dargestellt. Die Darstellung der Karte kann der Nutzerauf unterschiedliche Weise beein�ussen, wie bei der Modellierung von MapGENeric unter�Interaktion� gefordert wird. Zu diesen Interaktions-Möglichkeiten gehören Inforetrieval,Navigation, Zooming und Layermanipulation.

6.3.1 Layout

Beim Layout der Nutzer-Schnittstelle wurden die Vorgaben aus Kapitel 4.2.2 berück-sichtigt. Bereich A lässt sich unterteilen in Zooming-, Info- und Layer-Abschnitte (Abb.6.9). Im Zooming-Abschnitt sind drei Schalt�ächen vorhanden, die aus zwei unterschied-lich groÿen Globen und einem gebogenen Pfeil zwischen diesen beiden bestehen. ImInfo-Abschnitt unter �Coordinates� ist Platz für Längen- und Breitengradwerte. DieseKoordinaten beziehen sich auf die Position des Mauszeigers über der Karte in Bereich

6.3 Nutzer-Schnittstelle 91

Abbildung 6.8: Nutzer-Schnittstelle

B. Die dargestellten Werte stammen aus dem Wertebereich des jeweiligen Projektions-Koordinatensystem (in MapGENeric wurde beispielhaft die Peters-Projektion umgesetzt).Der letzte Abschnitt unter �Layer� stellt Listen- und Schalt�ächen bereit. In der Listesind Layer aufgeführt, die in Bereich B zu einer Karte zusammengelegt dargestellt wer-den. Durch einen Klick mit der linken Maustaste auf einen Layernamen in dieser Liste istes möglich, diesen Layer auszuwählen. Der ausgewählte Layer wird angezeigt durch Hin-terlegen des Namens mit einem blauen Balken (siehe Layer �Grün�ächen� in Abbildung6.9). Vor den Layernamen sind jeweils Boxen mit und ohne Häkchen, die anzeigen, obder jeweilige Layer auf der Karte sichtbar ist oder nicht. Die drei Schalt�ächen unter derLayerliste dienen zur Layermanipulation und werden im zugehörigen Unterkapitel nähererläutert werden.

Der wesentlich gröÿere Bereich B dient zur Darstellung der Bildschirmkarte, derenVorgaben in dieser Arbeit durch Kartentitel, Maÿstab und Layerkonzept de�niert wur-den (siehe Kapitel 4.2.2 - Layout). Der Kartentitel ist auf einer dunklen Fläche über dereigentlichen Karte dargestellt (im Beispiel �Musterhausen-Touristenkarte�). Der Karten-titel hat einen rein informativen Charakter. Der Maÿstab wird links unten auf der Kartedargestellt und verdeutlicht die Länge, die der Maÿstab selber auf dem aktuell sichtba-ren Kartenausschnitt einnimmt. Das Layerkonzept repräsentiert die Bildschirmkarte, die


Abbildung 6.9: Nutzer-GUI Bereich A

durch den Map Generator erstellt wird, indem Geoobjekte unter Berücksichtigung derVisualisierungs-Regeln auf verschiedenen Layern gezeichnet und diese wiederum aufein-andergelegt dargestellt werden. Um diese Bildschirmkarte herum ist ein Rahmen, der alsSchalt�äche für die Navigation dient.

6.3.2 Inforetrieval

Inforetrieval bezeichnet die Möglichkeit, die dem Nutzer geboten wird, verschiedene nicht-graphisch dargestellte Informationen zu Geoobjekten auf der Karte anzufordern. DieseFunktionalität steht durch einen Klick mit der rechten Maustaste auf die graphische Dar-stellung eines Geoobjekts im Bereich B auf der Karte zur Verfügung. Dabei ist zu be-


Abbildung 6.10: Nutzer-GUI Bereich B

achten, dass ausschlieÿlich Geoobjekte angeklickt werden können, die gezeichnet sind aufdem Layer, der im Layer-Abschnitt von Bereich A ausgewählt wurde. In Abbildung 6.9wären dies beispielsweise Geoobjekte auf dem Layer �Grün�ächen�. Wird mit der rechtenMaustaste auf die Karte geklickt, ohne vorher ein Layer gewählt zu haben, erscheint einHinweisfenster mit der Au�orderung dies nachzuholen.

Der Begri� �Repräsentations-Objekt� bezeichnet im folgenden die jeweilige graphischeDarstellung eines Geoobjekts aus der realen Welt innerhalb der Bildschirmkarte. WelcheRepräsentations-Objekte anklickbar sind und welche nicht ist abhängig von der Kon�-guration des Kartenautors. Generell sind alle Repräsentations-Objekte auf dem jeweilsausgewählten Layer anklickbar.

Punktförmige Geoobjekte

Im Touristik/Umwelt-Beispiel sind Straÿenbahnhaltestellen und Museen als punktförmigeGeoobjekte der Realwelt mit einem Koordinatenpaar de�niert. Wird die Beispielkon�gu-ration für dieses Beispiel aus Kapitel 6.2 betrachtet, so ist beispielsweise festzustellen,dass die Visualisierungs-Regel für die Darstellung von Straÿenbahnhaltestellen vorsieht,diese als blaue Kreise darzustellen. Möchte ein Nutzer z.B. weitere Informationen zu ei-ner bestimmten Haltestelle, so kann er in Bereich A den Layer �Straÿenbahnhaltestellen�wählen und diese blauen Kreise mit der rechten Maustaste anklicken, vorausgesetzt der


Layer ist sichtbar. Dies hat zur Folge, dass evtl. vorhandene Attribute (z.B.: Haltestellen-name) in einem separaten Fenster dargestellt werden. Die anklickbare Fläche beschränktsich dabei auf den dargestellten Kreis. Wird beispielsweise ein Pixel neben diesem Kreisangeklickt, ist keine Informationsdarstellung zu erwarten, weshalb bei der Kon�gurations-De�nition darauf zu achten ist, nicht zu kleine Darstellungsformen zu erstellen. Die Gröÿeder Darstellungsformen sollte vom Kartenautor unter Berücksichtigung der Kartennutzerde�niert werden. Beispielsweise wären für Kleinkinder und Menschen in hohem Alter be-sonders groÿe Darstellungsformen praktisch.

Bei der Darstellung von punktförmigen Geoobjekten durch Bitmaps, die ebenfalls mög-lich ist und im Touristik/Umwelt-Beispiel für Museen angewandt wurde, ist der anklick-bare Bereich ein anderer. Die Darstellung von Museen ist im Unterschied zu Hotels di�e-renziert zu betrachten, weil hier zwei verschiedene Bitmap-Arten genutzt wurden. Werdenbeide Bitmaps betrachtet, kann festgestellt werden, dass die Hoteldarstellung rechteckigist und die Museendarstellung eine andere Form aufweist. Nach der Beschreibung im letz-ten Absatz könnte der Anschein erweckt worden sein, dass wenn nicht auf die Form desMuseums geklickt wird sondern beispielsweise knapp unter dem Dach, wie zuvor keineReaktion zu erwarten ist (siehe Abbildung 6.11). Jedoch ö�net sich trotzdem ein Fenstermit den Informationen zu diesem Museum.

Abbildung 6.11: Extrem vergröÿerte Darstellung

Dieses Phänomen lässt sich dadurch erklären, dass vorde�nierte Darstellungsformenwie Ellipse, Dreieck und Rechteck für die Darstellung von punktförmigen Geoobjektenals Vektoren dargestellt werden und tatsächlich diese Formen annehmen (siehe Kapitel4.2.1). Die Form von Bitmaps jedoch ist immer rechteckig, auch wenn es wie bei derMuseumsdarstellung nicht so aussieht. Hier wurde die Form eines Gebäudes lediglichdurch den Einsatz von durchsichtigen Pixeln erreicht, die sozusagen den klickbaren Bereichmitde�nieren.

Linienförmige Geoobjekte

�Linienförmige Geoobjekte� sind Realweltobjekte, die modelliert sind mit zwei oder mehrKoordinatenpaaren. Das Informationretrieval über die Darstellung dieser Geoobjekte hängtauch von der Modellierung und Kon�guration des Kartenautors ab. Bei Geoobjekten, diedurch zwei Koordinatenpaare de�niert werden (im Beispiel Straÿenbahnteilstrecken) undauf der Karte durch eine Linie dargestellt werden, ist es gleichgültig, wo auf dieser Liniegeklickt wird, die Information zu dieser Teilstrecke zu erwarten. Es könnte evtl. erwartetwerden, dass wenn auf eine der beiden Enden einer Linie geklickt wird, Informationenzu dem jeweiligen Punkt, der dieses Ende de�niert, angezeigt werden. Auf eine solcheFunktionalität wurde bewusst verzichtet, da die Kon�guration einer solchen Funktiona-lität für den Kartenautor zu kompliziert werden würde. Ferner muss eine solche Linie


nicht durch zwei Geoobjekte mit je einem Koordinatenpaar (z.B.: Straÿenbahnhaltestel-len) de�niert sein, sondern könnte lediglich durch Koordinatenpaare de�niert worden sein.Die gleiche Erwartung ist auch bei Zwischenpunkten von linienförmigen Geoobjekten, diedurch mehr als zwei Koordinatenpaare de�niert werden (Linienzüge), denkbar, genausowie bei sich schneidenden Linien der Schnittpunkt. Falls diese Endpunkte, Zwischenpunk-te und Schnittpunkte eine besondere Bedeutung für die Anwendung haben, müssen sie inder Geodatenbank als punktförmige Geoobjekte modelliert vorliegen. Wenn dies der Fallist, können sie durch den Karten-Autor auch durch eine Visualisierungs-Regel besondershervorgehoben und somit anklickbar gemacht werden.

Flächenförmige Geoobjekte

Grün�ächen im Touristik/Umwelt-Beispiel beispielsweise stellen �ächenförmige Geoobjek-te dar. Die Flächen solcher Geoobjekte werden durch Linienzüge begrenzt, die auch fürihre Repräsentations-Objekte Form und Gröÿe de�nieren. Um Informationen zu solchenGeoobjekten zu erhalten, ist es möglich, auf jede Stelle ihres Repräsentations-Objekts zuklicken und somit die Funktionalität des Inforetrieval zu erhalten.

6.3.3 Navigation

Die Interaktions-Möglichkeiten der Nutzer-Schnittstelle lassen sich unterteilen in Infore-trieval und Kartenmanipulation (Navigation, Zooming und Layermanipulation). Die Kar-tenmanipulation kann als eine zweite Art der Kon�guration von MapGENeric betrachtetwerden. Der Unterschied zur Kon�gurationsmöglichkeit des Kartenautors, die dauerhaftin der Datenbank gespeichert wird, ist der, dass die Kon�guration durch den Kartennutzeraktuelle Wünsche des Kartennutzers wiedergibt und Parameter für die Kartengenerierungdurch den Map Generator in Echtzeit anpasst.

Navigation ist die erste dieser Echtzeitkon�gurations-Arten. Aus Gründen der E�zienzwurde in Kapitel 4.2.2 die Entscheidung, welche Navigationsart umgesetzt werden soll,zugunsten der Rahmen-Navigation getro�en. Diese Form der Navigation ist dem Nutzerüber den Rahmen um die Karte in Bereich B möglich. Bewegt er die Maus über diesenRahmen, so erscheint je nach Position auf dem Rahmen die Richtung, in die durch einenKlick mit der linken Maustaste der Ausschnitt verschoben werden kann. Der Navigations-Rahmen unterstützt acht Richtungen. Diese sind im Uhrzeigersinn: Nord, Nord/Ost, Ost,Süd/Ost, Süd, Süd/West, West, Nord/West. Würde der Mauszeiger beispielsweise auf dierechte obere Ecke des Navigations-Rahmens bewegt werden, so würde sich die Darstellungder Maus in einen Pfeil ändern, der von links unten nach rechts oben zeigt. Würde nundie linke Maustaste betätigt, so würde der Kartenausschnitt in diese Richtung bewegt,und die Karte neu gezeichnet.

6.3.4 Zooming

Das Zooming ist aufzufassen als Veränderung des dargestellten Realweltausschnitts. Fürdiese Funktionalität stehen verschiedene Möglichkeiten zur Verfügung. Bei der ersten Dar-stellung der Bildschirmkarte nach Auswahl der Datenbank und der Kon�guration ist der


Realweltausschnitt so gewählt, dass alle darzustellenden Geoobjekte sichtbar sind. DerKartennutzer hat daraufhin die Möglichkeit, diesen Ausschnitt über die beiden verschiedengroÿen Globen im Zooming-Abschnitt des Bereichs A (siehe Abbildung 6.9) zu verändern.Der kleine Globus dient zum herauszoomen, wobei der Realweltausschnitt vergröÿert wirdund dadurch die Darstellung verkleinert. Der groÿe Globus hat den gegenteiligen E�ekt.Um komfortabel wieder zum ursprünglichen Realweltausschnitt zurückkehren zu können,dient der Pfeil unter diesen Globen.

Eine weitere Möglichkeit ist gegeben durch das Markieren eines Ausschnitts auf derKarte selber. Dabei wird mit gedrückter linker Maustaste durch Bewegen der Maus biszum Loslassen der Maustaste ein Bereich markiert (Abb. 6.12). Auf diese Weise ist ledig-lich das Hineinzoomen (Verkleinern des Realweltausschnitts) möglich.

Beim Zooming ändern sich die durch die Visualisierungs-Regeln bestimmten Gröÿenfür die Darstellungsformen nicht. Die Karte wird lediglich für den neuen Realweltaus-schnitt mit den gleichen Darstellungsformen in den Visualisierungs-Regeln gezeichnet.Wird beispielsweise in die Karte hineingezoomt, so wird eine höhere Detaillierung derdargestellten Karte erreicht. Dies sei am folgenden Beispiel einer Deutschlandkarte ver-deutlicht, die lediglich Bahnhöfe einiger Städte als Punkte darstellt, und das Teilstück derAutobahn A3 innerhalb von NRW (siehe Abbildungen 6.12, 6.13, 6.14). Die Darstellungs-form für �Deutschland� ist beige, die für �Bahnhöfe� ist schwarz mit 25 Pixel Durchmesser,und für �Autobahn� ist die Darstellungsform eine schwarze Linie mit 10 Pixel Breite.

Abbildung 6.12: Gesamtansicht

In einem kleinen Maÿstab überdecken einige Darstellungsformen der Bahnhöfe die Au-tobahn. Ferner ist die Autobahn bis auf eine Biegung nahezu gradlinig (Abb. 6.12). Wirddurch die in der Abbildung sichtbare Selektion eines neuen Ausschnitts der Maÿstab ver-


Abbildung 6.13: Zoom 1 � NRW

Abbildung 6.14: Zoom 2 � Köln und Umgebung


gröÿert, so ist in der nächsten Abbildung 6.13 zu erkennen, dass die Bahnhöfe nicht mehrauf der Autobahn liegen. Der Trugschluss, dass die Autobahn bis auf eine Biegung gradli-nig ist, ist in diesem Maÿstab ebenfalls nicht mehr haltbar. Je weiter hineingezoomt wird,desto mehr Details werden sichtbar, vorausgesetzt die Karte ist aus einer detailreicherenGeodatenbank generiert worden (Abb. 6.14). Auf diesen drei Abbildungen ist ganz klarzu erkennen, dass sich die Darstellungsformen beim Zooming nicht geändert haben, denndie Autobahn ist auf allen dreien noch immer 10 Pixel breit und die Kreise für Bahnhöfe25 Pixel.

Wäre diese Anwendung in der Datenbank noch detaillierter modelliert worden, bei-spielsweise Autobahnen und Bahnhöfe als �ächenhafte Geoobjekte, so würden diese Geo-objekte beim Hineinzoomen mitwachsen wie auch das �ächenhafte Geoobjekt Deutschlandin den Abbildungen.

6.3.5 Layermanipulation

Es ist dem Kartennutzer möglich, die Zeichenreihenfolge oder die Sichtbarkeit der einzel-nen Layer zu ändern. Diese Funktionalität wird zur Verfügung gestellt, weil Kartenautorennicht wirklich für jeden Nutzer eine eigene Kon�guration erstellen können. Jede Nutzer-gruppe, für die ein Kartenautor Kon�gurationen erstellt, könnte weiter unterteilt werden.Diese Funktionalitäten hingegen ermöglichen es jedem Nutzer die Darstellung der Karteseinen persönlichen Wünschen anzupassen. Beispielsweise ist es im Touristik/Umwelt-Beispiel denkbar, dass auf einer Vergnügungsmeile viele Restaurants und Cafés eng bei-einander liegen (siehe Abbildung 6.15). Ein Tourist könnte sich nun in der Layerlisteeine Rangfolge erstellen, in der er seine Fast-Food-Restaurantauswahl tri�t. Diese Rang-folge könnte so aussehen, dass er die Fast-Food-Kette Subway, dann Burger King undzuletzt McDonald`s bevorzugt. Nun wäre es ihm neben dem optischen Vorteil auch mög-lich, einfacher auf das Symbol für Subway zu klicken, um beispielsweise Ö�nungszeiten inErfahrung zu bringen. Angenommen ein weiterer Tourist lehnt es strikt ab, in bestimm-ten Fast-Food-Ketten zu essen. Die Funktionalität Sichtbarkeit einzelner Layer ändern zukönnen, würde diesem Tourist mehr Überblick auf der Karte verscha�en, indem er dieLayer mit den unerwünschten Restaurants ausblenden könnte.

Um die Zeichenreihenfolge der Layer ändern zu können, muss in der Listendarstellungim Layer-Abschnitt von Bereich A ein Layer selektiert werden. Dieser Layer kann nun(mit den Pfeiltasten links unter der Liste) in der Zeichenreihenfolge nach unten oder obenverschoben werden, wobei Layer weiter oben früher gezeichnet werden als Layer weiterunten. Die auf diese Weise veränderte Karte wird bei jedem Klick neu aufgebaut, so dassder E�ekt der Reihenfolgeänderung in Echtzeit verfolgt werden kann.

Vor den Layern in dieser Liste stehen CheckBoxes, die die Sichtbarkeit der jeweiligenLayer bestimmen. Ist ein Häkchen in einer solchen Box, so ist der Layer sichtbar, andern-falls ist er unsichtbar. Sind die Sichtbarkeiten bestimmt, kann der Kartennutzer über die�Redraw�-Taste veranlassen, dass die Karte nach seinen persönlichen Einstellungen neugezeichnet wird. Die �Redraw�-Taste liegt auf der rechten Seite unter der Layerliste.


Abbildung 6.15: Karten- und Layerausschnitt (vergröÿerte Darstellung)

Bei der Änderung von Sichtbarkeiten wurde auf eine direkte Darstellung des Ergebnis-ses (wie zuvor bei Änderung der Zeichenreihenfolge) aus E�zenzgründen verzichtet. Diedirekte Darstellung bei Änderung der Zeichenreihenfolge ist möglich, da die Karte dabeilediglich durch Übereinanderlegen der fertig gezeichneten Layer in der neuen Reihenfolgeerzeugt wird. In MapGENeric werden lediglich Layer gezeichnet, die sichtbar sein sollen.Diese fertig gezeichneten Layer werden in einem Zwischenspeicher als Bitmaps bereitge-halten. Das Darstellen der Karte, die durch das Übereinanderlegen dieser Bitmaps in einerneuen Reihenfolge erzeugt wird, geht sehr schnell. Jedoch werden ausgeblendete Layer ausdiesem Zwischenspeicher gelöscht, so dass sie aufwendig neu gezeichnet werden müssen,wenn sie wieder eingeblendet werden. Da es aber oft vorkommen kann, dass mehrere aus-geblendete Layer eingeblendet werden sollen, wurde auf die Technik zurückgegri�en, dassNeuzeichnung erst auf Anforderung erfolgt.

Kapitel 7

Implementierung

In diesem Kapitel werden Teilprobleme der Implementierung von MapGENeric nähererläutert werden. Dazu wird die hierarchische Struktur von MapGENeric genutzt, umdie Detaillierung der Erläuterungen zu erhöhen bis in Codeebene. Dabei werden Kompo-nenten dargestellt, die bei der Modellierung und Implementierung eine besondere Stellungeingenommen haben, sei es die Funktionalität oder die Architektur betre�end. Die Haupt-komponente �Map Generator� in Abbildung 6.1 stellt die erste Stufe in der hierarchischenBetrachtung dar. Der Komponente �Map Generator� folgt ihre Teilkomponente �LayerGe-nerator�, in der die Generierung der Zeichen�äche, Abbildung der Realweltkoordinaten aufBildschirmkoordinaten und das Zeichnen der Repräsentations-Objekte interessant sind.

7.1 Map Generator

Der �Map Generator� ist die Hauptkomponente von MapGENeric, denn sie ist für dasErstellen der Karte zuständig. Sie agiert zwischen der Datenbank-Schnittstelle und demNutzer der Anwendung. Diese Komponente ist für die Regelverarbeitung und die Erstel-lung der daraus resultierenden Karte zuständig. Der Abbildung 7.1 ist zu entnehmen,dass �Map Generator� eine sequenziell arbeitende Komponente ist. Sie führt verschie-dene Schritte aus, die von einer Geodatenbank zu einer fertigen 2D-Bildschirmkarte inForm eines Bitmaps führen. Die dazu nötigen Schritte können unterteilt werden in �LadeKon�guration� (Con�guration Loader), �Lade Geoobjekte� (Geoobject Loader), �Proji-ziere Koordinaten� und �Erstelle Layer�. Die letzten beiden Schritte wurden ausgelagertin Teilkomponenten �Projection Transformer� und �Layer Generator�, um eine modulareArchitektur zu erreichen, die bei Bedarf leicht angepasst werden kann. Durch diese Mo-dularität ist beispielsweise die Projektions-Komponente beliebig austauschbar.

Der Map Generator erwartet über das Nutzer-GUI die Auswahl einer Geodatenbankmit Kon�gurationsdaten für MapGENeric, wie in Kapitel 6.2 beispielhaft für das Tou-ristik/Umwelt-Beispiel erstellt. Genauer erwartet nicht clsMapGenerator diese Geodaten-bank, sondern der DataManager über den der Map Generator Kon�gurationsdaten aus derGeodatenbank anfordert. Zu diesen Daten gehören Kon�gurationen, Darstellungsformen,Geoobjektklassen-De�nitionen und Visualisierungs-Regeln, die durch den DataManagerin systeminterne Strukturen umgewandelt und an Map Generator übergeben werden.

100

7.1 Map Generator 101

Abbildung 7.1: Map Generator

Anhand der ausgewählten Kon�guration werden im nächsten Schritt über den Data-Manager die darzustellenden Geoobjekte angefordert. Diese werden vom DataManagerauch in interne Strukturen umgewandelt und mit ihren Darstellungsformen an die jeweili-gen systeminternen Layerstrukturen übergeben. Diese Layer wurden im vorangegangenenSchritt durch den DataManger für jede Visualisierungs-Regel erzeugt, die für die aktu-elle Kon�guration als sichtbar de�niert wurde. Dabei wird der Kartenausschnitt initialan Hand der eingelesenen Geoobjektkoordinaten bestimmt und de�niert den zu Beginndarzustellenden Realweltausschnitt �OriginWorldViewRange�, der alle Koordinaten derdarzustellenden Geoobjekte umfasst.

Im dritten Schritt werden über eine weitere Komponente (ProjectionTransformer) dieKoordinaten dieser Geoobjekte durch die jeweilige Projektion in dessen Koordinatensys-tem projiziert. Beispielhaft wurde hier die Peters-Projektion umgesetzt, die für Weltkar-tendarstellung eine �ächentreue Darstellung bietet. In der letzten Komponente (LayerGenerator) werden diese systeminternen Strukturen für Geoobjekte auf Layern darge-stellt. Jeder Layer wird für sich auf einem eigenen Bitmap gezeichnet. Zusammengelegtzu einem einzelnen Bitmap (in der durch die Kon�guration vorgegebenen Reihenfolge)stellen sie die Ausgabe des Map Generators dar.

7.1.1 Con�guration und Geoobject Loader

Die Kon�guration des Map Generators wurde in Kapitel 4.4.1 modelliert als eine Mengevon Regeln, die jeweils eine Kombination aus Geoobjektklassen und Darstellungsformendarstellen. Diese Regeln haben eine Reihenfolge in der sie der Kon�guration zugewiesen

102 Kapitel 7. Implementierung

Abbildung 7.2: Flussdiagramm für Map Generator (1)

sind. Um die durch den Kartennutzer gewählte Kon�guration zu laden, greift Map Ge-nerator als erstes lesend über die DB-Schnittstelle auf die Regeln zu, die der gewähltenKon�guration zugewiesen sind.

In Kapitel 6.3 wurde die Gesamtheit der Repräsentations-Objekte, der durch eineRegel de�nierten Geoobjekte als �Layer� bezeichnet. Dies wird im folgenden genauer spe-zi�ziert: Eine Regel bestimmt eine Menge von Geoobjekten, die durch eine bestimmteDarstellungsform dargestellt werden sollen. Die Beziehung, die Regeln mit einer Kon�gu-ration bilden, enthält ihre Position in der Abarbeitungsreihenfolge und die Sichtbarkeitfür die jeweilige Kon�guration. Das in Kapitel 4.4.1 vorgestellte Anschauungsbild fürLayer (�Layer können angesehen werden als durchsichtige Folien, auf denen Geoobjekteder selben Klasse durch die gleiche Darstellungsform dargestellt sind. Diese Folien müsseneine Position haben in der Reihenfolge in der sie übereinander gelegt werden.�) führt beigenauer Betrachtung zu einer Ähnlichkeit mit Regeln, genauer noch zu der Erkenntnis,dass Regeln Layer de�nieren.

Aus diesem Grund werden Regeln durch die DB-Schnittstelle zu clsLayer -Objektenmit den Eigenschaften Name, Position in Reihenfolge und Sichtbarkeit transformiert. Beider Sichtbarkeit muss jedoch unterschieden werden zwischen �aktueller� und �gewünsch-ter� Sichtbarkeit. Das liegt daran, dass die Sichtbarkeit von Regeln durch den Karten-autor initial vorgegeben, jedoch während der Programmlaufzeit durch den Nutzer verän-dert werden können. Dabei wird beim Laden der Kon�guration die gewünschte Sichtbar-keit mit dem Wert aus der Datenbank gesetzt. Zusammengefasst in einem clsLayerList-Containerobjekt werden diese clsLayer-Objekte dem zuvor instanziierten clsMap-Objektübergeben. An dieser Stelle kommt ein geordnetes Containerobjekt zum Einsatz, das dieLayer in der Reihenfolge speichert, in der sie gezeichnet werden sollen.


Als nächstes werden alle Darstellungsformen für die drei Basisklassen Punkt, Linieund Fläche aus der Datenbank ausgelesen. Dies geschieht durch die DB-Schnittstellen-Komponente clsViewshapeDBReader. Die Darstellungsformen werden je nach Typ um-gewandelt in Objekte der Klassen clsViewshapePoint, clsViewshapeLine und clsViewsha-peArea. Für einen schnellen Zugri� werden diese Darstellungsformen in separaten Hashta-bellen (für jeden Typ � PunktDF, LinieDF und FlächeDF� eine Hashtabelle) gespeichert,aus denen sie bei Bedarf an Hand ihrer IDs ausgelesen werden können. Diese Hashtabellenwerden auch dem clsMap-Objekt übergeben.

Abhängig von der Reihenfolge und der Sichtbarkeit der zuvor erstellten Layer-Objektewerden nun in einem zweiten Schritt Geoobjekte eingelesen. Dazu dient die Methode �ll-Layers in der Klasse clsMapObjectDBReader, die als Parameter das Objekt der Contai-nerklasse clsMap erwartet. Die in clsMap enthaltene Layerliste wird abgearbeitet, wobeifür jede als sichtbar de�nierte Regel (clsLayer-Objekt) die Geoobjekt-Sichten über dieDB-Schnittstelle ausgeführt werden. Geoobjekte der Ergebnismenge dieser Sichten wer-den umgewandelt in clsMapObject-Instanzen. Diese Objekte erhalten die Geoobjekt-ID,ihre Basisklasse, ihre Darstellungsform, ihre Realweltkoordinaten und die Attribut-Sicht,die ihre zusätzlichen Eigenschaften repräsentiert. Die auf diese Weise entstandenen cls-MapObject-Instanzen werden den clsLayer -Objekten übergeben, die sie gruppieren. DieclsLayer -Objekte wiederum sind im clsMap-Objekt.

Um den Kartenausschnitt immer so zu wählen, dass alle eingelesenen Geoobjekte dar-gestellt werden können, müssen die Eckkoordinaten bestimmt werden. Dazu werden beijeder Regel über eine Methode die minimalen und maximalen Koordinaten der durchdiese Regel de�nierten Geoobjekte ermittelt. Dabei gilt die am weitesten links unten ste-hende Koordinate als minimale und die am weitesten rechts oben stehende als maximaleKoordinate. Die Längen- und Breitengrade dieser zwei Koordinaten werden mit den zu-vor ermittelten verglichen. Wenn sich bei diesem Vergleich herausstellt, dass der Längen-oder Breitengrad auÿerhalb des bisherigen WorldViewRange liegt, wird diese Gradanga-be in das aktuelle WorldViewRange übernommen. Wenn alle darzustellenden Geoobjektegeladen wurden, wird der auf diese Weise ermittelte WorldViewRange als �OriginWorld-ViewRange� gespeichert. Dadurch ist es möglich, jederzeit wieder zu dem ursprünglichenRealweltausschnitt zurückzukehren, der alle eingelesenen Geoobjekte beinhaltet.

7.1.2 Projection Transformer

Das nun um Geoobjekte mit Darstellungsform und dem zu visualisierenden Realweltaus-schnitt (WorldViewRange) erweiterte clsMap-Objekt wird an die Komponente �Projec-tionTransformer� übergeben (siehe Abbildung 7.2), die eine Kartenprojektion berechnet,wie in Kapitel 2.1.2 beschrieben. Der ProjectionTransformer ist als ein Visual Basic Inter-face verwirklicht, so dass später weitere Projektionen implementiert und in MapGENericgenutzt werden können. Dazu muss der jeweilige Transformator clsProjectionInterface be-erben und ihre Methoden convert, dispose und convertLongAndLat überschreiben. Dabeierwartet convert als Parameter ein clsMap-Objekt und transformiert alle darin enthalte-nen Koordinaten in die jeweilige Projektion. Dazu durchläuft die convert-Methode alle in


clsMap vorhandenen Layer, in denen die darzustellenden Geoobjekte mit ihren Koordina-ten gespeichert sind. Auf diese Koordinaten wird die Projektion angewendet. Beispielhaftwurde in dieser Arbeit die Peters-Projektion implementiert, die für Weltkarten eine �ä-chentreue Darstellung liefert.

7.1.3 Layer Generator

Das clsMap-Objekt wird im nächsten Schritt an den Layer Generator übergeben, derdie Layer in der Liste (clsLayerList) zeichnet. Die clsLayer -Objekte in dieser Liste lie-gen in der vom Kartenautor de�nierten oder vom Kartennutzer angepassten Reihenfolgevor (siehe Kapitel 4.2.2). Zum Zeichnen der Layer wird jeweils ein Bitmap erzeugt, aufdem die Geoobjekte mit der ihnen zugewiesenen Darstellungsform (Viewshape) gezeichnetwerden. Dass Bitmaps genutzt werden, hat einige Vorteile wie beispielsweise das Cachingvon Layern. Dadurch braucht der Layer beispielsweise nicht erneut gezeichnet zu werden,wenn die Layerreihenfolge über das Nutzer-GUI verändert wird oder Layer ein- bzw. aus-geblendet werden.

Die Generierung der Layer erfolgt in der Klasse clsLayerGenerator. Genauer gesagtin der Methode drawLayer, die clsMap mit einer Gröÿenangabe in Pixeln als Parametererwartet. Diese Gröÿenangabe (Höhe x Breite) bezieht sich auf die Gröÿe der zu generie-renden Bildschirmkarte. Die Layerliste in clsMap wird abgearbeitet, und für jeden Layer,der als sichtbar de�niert ist, wird ein leeres Bitmap erstellt. Weiter werden alle Geoobjek-te aus dem aktuellen Layer ausgelesen und abhängig vom Basistyp (Punkt, Linie, Fläche)durch die jeweilige Methode drawPoints, drawLines oder drawAreas auf diesem leerenBitmap gezeichnet. Dazu müssen die Geoobjektkoordinaten noch einmal transformiertwerden, denn die Kartenprojektion bildet in ein eigenes Koordinatensystem ab, wie inKapitel 2.1.2 zu sehen ist. Die Karte bzw. Geoobjekte der Karte müssen aus diesem Ko-ordinatensystem auf das Bitmap abgebildet werden. Hierzu wird für jedes Geoobjekt dieFunktion world2screen aufgerufen, die diese einfache Umrechnung ausführt. Es gibt aucheine Funktion screen2world, die in die umgekehrte Richtung wandelt. Diese Funktion istnötig, um von der Karte auf Realweltkoordinaten zurückschlieÿen zu können, beispiels-weise für das Zooming durch Ausschnittwahl.

Die Methoden zum Zeichnen der Geoobjekte werden abhängig von ihrem Basistyp auf-gerufen. Diese Methoden erstellen an Hand der Darstellungsformen, die den Geoobjektenzuvor zugewiesen wurden, VisualBasic-Pens und -Brushes (vgl. 3.2.3). Pens und Brusheswerden benötigt, um graphische Objekte mit VisualBasic zu zeichnen.

Soll ein Punktobjekt gezeichnet werden, so wird erst einmal in der diesem Objektzugewiesenen Darstellungsform (Viewshape) ausgelesen, ob ein Bitmap zugewiesen wur-de, durch das das Punktobjekt dargestellt werden soll. Wenn dies der Fall ist, wird dasBitmap geladen und in der Gröÿe, wie sie in der Darstellungsform de�niert ist, auf dasaktuelle Layer gezeichnet. Ist dies jedoch nicht der Fall wird kontrolliert, ob eine vorde�-nierte Form (Punkt, Dreieck, Quadrat) gewünscht ist. In diesem Fall wird das Objekt inder vorde�nierten Form gezeichnet. Wenn auch dieser Fall nicht zutri�t, wird die vorde-�nierte Form �Punkt� genutzt, um das Geoobjekt darzustellen. In den Fällen, in denen


Abbildung 7.3: Flussdiagramm für Map Generator (2)

vorde�nierte Formen genutzt werden, wird aus der Farbe, die in der Darstellungsformgespeichert ist, ein SolidBrush erstellt, mit dem die Geoobjekte gezeichnet werden. Auchbeim Zeichnen der vorde�nierten Formen wird die Gröÿe in der Darstellungsform beachtet.

Bei Linienobjekten ist die De�nition der Darstellungsform etwas aufwendiger (sieheAbbildung 4.13). Hier sind einige weitere Parameter zu beachten, weshalb es auch notwen-dig wird, ein Pen zu nutzen und kein Brush, die bei Punkt- und Flächenobjekten (hierzusiehe 3.2.3) genutzt werden. In VisualBasic ist es nur mit Pens möglich, Linien ein Muster(vgl. durchgehende, gestrichelte, gepunktete Linien in Kapitel 4.2.1) zu verleihen. Pensbieten auch die Möglichkeit, die geforderten Enden für Linien zu gestalten, beispielsweisedurch eine Pfeilspitze für Einbahnstraÿen.

Flächenobjekte werden durch ihre Begrenzungspunkte de�niert und können mit ei-ner Farbe oder einem Muster gefüllt werden. Um ein Flächenobjekt mit einer Farbezu befüllen, werden auch SolidBrushes angewendet. Ist jedoch in der ihr zugewiesenenDarstellungsform ein Musterbitmap de�niert, so wird ein TextureBrush eingesetzt. Tex-tureBrushes nutzen Bitmaps zum Zeichnen oder Befüllen der graphischen Objekte an


deren Zeichenmethode sie übergeben werden. Wenn zusätzlich in der Darstellungsformgewünscht ist, dass die Fläche durch eine Linie umrandet ist, wird die Methode für Li-nienobjekte mit den gleichen Koordinaten für die Fläche aufgerufen. Die auf diese Weiseerstellten Layerbitmaps werden gespeichert und können über eine weitere Methode (draw-Map) in der richtigen Reihenfolge übereinander auf einem endgültigen Bitmap gezeichnetwerden, der das Resultat der Anwendung des Map Generators darstellt.

7.2 Module des Layer Generator

7.2.1 Generierung der Zeichen�äche - Layer

Der Layer Generator (clsLayerGenerator) ist die Komponente, in der die Umwandlungalphanumerischer Daten in graphische Objekte einer Bildschirmkarte vonstatten geht. InAbbildung 7.3 ist zu sehen, dass in der Methode drawLayer() für jeden sichtbaren Layerin der Liste ein neues �Layerbitmap� erzeugt wird, auf dem wiederum die graphische Dar-stellung der Geoobjekte gezeichnet werden. Für die Darstellung von Layern eignet sichdas GDI+ Objekt Bitmap. Wie auch das Layer-Modell sind Bitmap-Objekte durchsichtigde�niert und bieten eine Zeichen�äche. Für jeden darzustellenden Layer wird folgenderCode wiederholt ausgeführt:

'neues Layerbitmap instanziieren

Dim layerBitmap As Bitmap

layerBitmap = New Bitmap(width, height)

'Zeichenfläche des Bitmap-Objekts holen

Dim g As Graphics

g = Graphics.FromImage(layerBitmap)

'get layer to draw

Dim layer As clsLayer

layer = map.layerList.item(i)

Dim mapObjectList As ArrayList

mapObjectList = layer.mapObjects

Dim mapObject As clsMapObject

For Each mapObject In mapObjectList

Dim coordinates(mapObject.coordList.Length - 1) As PointF

mapObject.copyCoordList(coordinates)

For ir As Integer = 0 To coordinates.Length - 1

' map realWorldCoordinates to screen

coordinates(ir) = world2screen(coordinates(ir))

Next

7.2 Module des Layer Generator 107

Select Case mapObject.geoObjectBaseClass

Case clsMap.enumGeoObjBaseClass.AREA

drawAreas(coordinates, mapObject.viewshapeID, g)

Exit Select

Case clsMap.enumGeoObjBaseClass.LINE

drawLines(coordinates, mapObject.viewshapeID, g)

Exit Select

Case clsMap.enumGeoObjBaseClass.POINT

drawPoints(coordinates, mapObject.viewshapeID, g)

End Select

Next

Auf der Zeichen�äche des jeweiligen LayerBitmap sollen die Geoobjekte der realenWelt abgebildet werden. Die Zeichen�äche bietet ein eigenes Koordinatensystem, das linksoben ihren Ursprung (0,0) hat. Bei der Instanziierung des Bitmap-Objekts wird nach rechtsder Wertebereich dieses Koordinatensystems begrenzt durch width und nach unten durchheight. Da das Koordinatensystem, in dem die Geoobjekte modelliert sind, in der Regelein anderes ist, ist eine Transformation notwendig. Diese Transformation muss Koordina-ten der Geoobjekte umwandeln in Koordinaten der Zeichen�äche. Dabei ist diese Trans-formation nicht mit der Projektion zu verwechseln, die geographische Koordinaten derdreidimensionalen Erdober�äche in ein zweidimensionales Koordinatensystem transfor-miert. Es ist vielmehr eine Transformation, die aus diesem zweidimensionalen Koordina-tensystem in das zweidimensionale Koordinatensystem des LayerBitmaps transformiert.Damit Realweltkoordinaten der mapObjects nicht verfälscht werden, werden sie für dieseTransformation kopiert (mapObject.copyCoordList(coordinates), siehe Code zuvor). Ei-ne Verfälschung in den den internen Strukturen würde nach sich ziehen, dass für jedeDarstellungsänderung durch Zooming, Navigation oder ähnlichem die Daten erneut ausder Geodatenbank ausgelesen werden müssten. Da diese Transformation ausschlieÿlichim Layer Generator genutzt wird, ist sie als eine Methode der Klasse clsLayerGeneratorumgesetzt worden, dessen Notwendigkeit und Architektur im folgenden an einem Beispielerläutert werden soll.

7.2.2 World To Screen - Koordinatentransformation

Im Beispiel aus der Abbildung 7.4 ist der darzustellende Bereich sieben Einheiten breitund vier Einheiten hoch. Der Bereich hingegen, auf dem dargestellt werden soll (Abb.7.5), ist 800 Einheiten breit und 600 Einheiten hoch. Würden nun die Koordinaten derPunkte aus dem linken Bereich 1:1 auf den rechten Bereich übertragen, so wäre dies indiesem Fall zwar möglich, jedoch wäre die Darstellung sehr klein. Wäre der Wertebereichder darzustellenden Welt gröÿer als die der Fläche, auf der abgebildet werden soll, sowürden viele Punkte nicht dargestellt werden können. Aus diesen Gegebenheiten folgtdie Notwendigkeit einer Funktion, die Koordinatenwerte aus der darzustellenden Ebene(Realweltausschnitt) in die Ebene transformiert, auf die abgebildet werden soll (Bitmap-


zeichen�äche). Von einer Ebene kann in beiden Fällen deshalb gesprochen werden, weilRealweltkoordinaten durch die Projektion bereits auf eine Ebene transformiert vorliegenund die Darstellung auf Bildschirmen zweidimensional erfolgt.

Abbildung 7.4: Realweltausschnitt Abbildung 7.5: Zeichen�äche

Um eine �ächenfüllende Abbildung des Realweltausschnitts (Abb. 7.4 grün umrandeteFläche) auf der Zeichen�äche (Abb. 7.5 grün umrandete Fläche) zu erhalten, muss ein Fak-tor ermittelt werden, mit dem Koordinaten von Geoobjekten aus dem Realweltausschnittmultipliziert die entsprechenden Koordinaten im Koordinatensystem der Zeichen�ächeergeben. Diese Funktionalität nennt sich Skalierung. Ein solcher Faktor kann aus der Di-vision der Breite der Zeichen�äche durch die Breite des abzubildenden Ausschnitts fürdie X-Achse und aus der Division der Zeichen�ächen-Höhe durch die Ausschnitts-Höhefür die Y-Achse gewonnen werden. Aus den beiden Abbildungen 7.4 und 7.5 ist leichtersichtlich, dass das Seitenverhältnis der beiden Bereiche ungleich ist. Der Realweltaus-schnitt hat ein Seitenverhältnis von 7:4 und die Zeichen�äche 4:3. Soll nun der gesamteRealweltausschnitt die gesamte Zeichen�äche ausfüllen, sind für die beiden Achsen X undY unterschiedliche Faktoren notwendig:

Breite Zeichenflache

Breite Realweltausschnitt=

800

7= 114, 29...

Hohe Zeichenflache

Hohe Realweltausschnitt=

600

4= 150

O�ensichtlich führen unterschiedliche Faktoren zu Verzerrungen der Realität in der Dar-stellung. Aus diesem Grund ist es erforderlich, sich für einen dieser Faktoren zu entschei-den. Fällt die Entscheidung zugunsten des gröÿeren Faktors, d.h. im Beispiel für denFaktor der Y-Achse, so wird die abzubildende Fläche gröÿer als die Zeichen�äche. Da-durch würden Punkte wie P(7,8|5) auÿerhalb des sichtbaren Bereichs der Zeichen�äche


gezeichnet. Sinnvoller ist daher die Wahl des jeweils kleineren Faktors.

Ein weiteres Problem ergibt sich aus der Möglichkeit, Realweltausschnitte frei wählenzu können. Würde der Faktor mit den Koordinatenwerten der realen Wert multipliziert, sowürde beispielsweise der Punkt P(7,8|5) noch immer auÿerhalb des sichtbaren Bereichs ge-zeichnet (in Abb. 7.5 rot dargestellt). Das hängt damit zusammen, dass der Ursprung (0|0)des Ausschnitts nicht mit dem der Zeichen�äche übereinstimmt. Es muss eine Korrekturerfolgen, die den Abstand der zu transformierenden Koordinaten zu ihrem Ursprung aufbeiden Achsen reduziert. Eine Schwierigkeit dabei ist, dass Realweltkoordinaten aus derMenge des Kartesischen Produkts der reellen Zahlen (R×R) stammen und die Zeichen�ä-che aus der Menge des Kartesischen Produkts der positiven natürlichen Zahlen (N ×N),d.h. es muss aus der Menge der reellen Zahlen in die Menge der positiven natürlichen Zah-len transformiert werden. Die Funktion hierfür soll im folgenden an Hand der X-Achseerläutert werden. Es gibt drei Möglichkeiten, wie der darzustellende Bereich (D-Bereich)de�niert sein kann, wobei uG ∈ R die untere Grenze des D-Bereichs darstellt und oG ∈ Rdie obere Grenze:

1. uG < 0 und oG < 0

2. uG < 0 und oG ≥ 0

3. uG ≥ 0 und oG ≥ 0

Im ersten Fall muss die X-Achse um die untere Grenze des D-Bereichs (roter Distanz-pfeil in Abb. 7.6) verschoben werden, dann hat der Punkt (roter Punkt in Abb. 7.6) dengleichen Abstand zum Null-Punkt wie zuvor zur unteren Grenze. Derselbe E�ekt kannerreicht werden, wenn diese Distanz und die Punkt-Koordinate addiert werden.

Abbildung 7.6: Achsenkorrektur - Fall 1

Im zweiten Fall kann ebenfalls durch eine Addition der Distanz zur Punkt-Koordinatedie nötige Achsenverschiebung erreicht werden. Jedoch muss im letzten Fall die Distanzsubtrahiert werden, damit der Punkt denselben Abstand zum Null-Punkt einnimmt wiezuvor zur unteren Grenze des D-Bereichs (Abb. 7.7).

Diese Erkenntnisse gelten analog für die Y-Achse und zusammen für die Ebene immathematischen Sinne. In Ebenen erfolgt die Bestimmung eines rechteckigen Ausschnittsdurch zwei gegenüberliegende Eckpunkte dieses Ausschnitts. In R×R ist es sinnvoll dieseEckpunkte so zu wählen, dass sie die linke untere Ecke und die rechte obere Ecke de-�nieren. Auf diese Weise de�niert der linke untere Eckpunkt (LeftBottomCorner - lbc)


Abbildung 7.7: Achsenkorrektur - Fall 3

für alle darzustellenden Punkte die untere Grenze ihrer X- und Y-Koordinaten, wohin-gegen der obere rechte Eckpunkt (RightUpperCorner - ruc) ihre obere Grenze de�niert.WorldVisRange bezeichne im folgenden den darzustellenden Realweltausschnitt, wPointeinen Punkt aus diesem Ausschnitt und sPoint die Entsprechung des wPoints auf der Zei-chen�äche. Dann lässt sich der achsenverschobene sPoint in der Ebene folgendermaÿenberechnen:

sPoint.X = wPoint.X −WorldV isRange.lbc.X

sPoint.Y = wPoint.Y −WorldV isRange.lbc.Y

Durch diese einfache Funktion werden alle drei Fälle abgedeckt. In den ersten beidenFällen, in denen die Distanz zur unteren Grenze des D-Bereichs addiert werden soll, sinddiese unteren Grenzen negativ. Werden diese negativen Werte in die Formel eingesetzthat dies eine Addition zur Folge. Im dritten Fall, ist eine Subtraktion der Distanz erfor-derlich, die durch diese Funktion o�ensichtlich gegeben ist. Der Faktor für die Skalierung(scaleFactor) erfordert folgende Berechnungen, um in obiger Funktion eingesetzt werdenzu können (D-Bereich als dRange, Funktion Min(x,y) zur Bestimmung der kleineren Zahlvon x und y, zWidth und zHeight für die Breite und Höhe der Zeichen�äche):

dRange.Width = WorldV isRange.ruc.X −WorldV isRange.lbc.X

dRange.Height = mWorldV isRange.ruc.Y −mWorldV isRange.lbc.Y

scaleFactor = Min

(zWidth

dRange.Width,

zHeight

dRange.Height

)

Werden die X- und Y-Koordinatenwerte von sPoint mit scaleFactor multipliziert, soentsteht die gewünschte Abbildung der Koordinatenpaare aus dem darzustellenden Real-weltausschnitt in die Zeichen�äche. Eine Eigenart, die GDI+ mitbringt und in Abbildung7.5 zu sehen ist, wurde jedoch in den bisherigen Lösungen nicht berücksichtigt. GDI+de�niert den Ursprung auf Zeichen�ächen links oben. Bei der bisher erarbeiteten Funkti-on würde somit eine horizontal gespiegelte Darstellung auf der Zeichen�äche folgen. Umauch diese Fehldarstellung zu korrigieren, reicht es, den Y-Wert jeweils von der Höhe derZeichen�äche abzuziehen, so dass endgültig folgende Funktion in Codeform resultiert:


Private Function world2screen(ByVal wPoint As PointF) As PointF

'ermittle Ausschnitt-Gröÿe

Dim dRange.Width As Single = mWorldVisRange.ruc.X - mWorldVisRange.lbc.X

Dim dRange.Height As Single = mWorldVisRange.ruc.Y - mWorldVisRange.lbc.Y

'berechne beide Faktoren und wähle den Kleineren

Dim scaleFactor As Single = Math.Min((zWidth / dRange.Width, zHeight / dRange.Height)

Dim sPoint As New PointF

sPoint.X = ((wPoint.X - mWorldVisRange.lbc.X) * (scaleFactor))

sPoint.Y = (((wPoint.Y - mWorldVisRange.lbc.Y) * (scaleFactor)) * -1) + zHeight

Return sPoint

End Function

7.2.3 Zeichnen der Repräsentations-Objekte

Das Zeichnen der Geoobjekte erfolgt abhängig von ihrer Basisklasse, denn zum Zeichnenvon Geoobjekten unterschiedlicher Basisklassen eignen sich unterschiedliche Zeichenme-thoden von GDI+. Da die unterschiedlichen Zeichenmethoden von GDI+ wiederum unter-schiedliche Parameter und Vorbereitungen benötigen, wurde der Aufruf dieser Methodenin MapGENeric ausgelagert zu drawPoints(...), drawLines(...) und drawAreas(...).

drawPoints(...)

Die Abbildung eines als punkthaft modellierten Geoobjekts auf einer Bildschirmkarte er-fordert lediglich ein Koordinatenpaar mit Breiten- und Längengrad. Wie zuvor erläutert,wird dieses Koordinatenpaar durch die Methode world2screen(...) umgewandelt in einKoordinatenpaar, das einen Punkt auf der Zeichen�äche des LayerBitmaps repräsentiert.Damit gezeichnet werden kann, benötigt die Methode jedoch neben dem Koordinatenpaardie Zeichen�äche, auf der gezeichnet werden soll, und die Darstellungsform, durch die dasObjekt dargestellt werden soll. In Kapitel 4.2.1 wurde für die Darstellung eines punkthaftmodellierten Geoobjekts ein Bitmap oder ein vorde�niertes graphisches Objekt vorgese-hen. Ist die der Methode übergebene Darstellungsform de�niert durch ein Bitmap, wirdauf der Zeichen�äche dieses Bitmap durch die GDI+interne Methode der Zeichen�ächenDrawImage gezeichnet.

Private Sub drawPoints(ByRef coords As PointF(), _

ByRef viewshapeID As Integer, _

ByRef g As Graphics)

If coords.Length > 0 Then

Dim myViewshape As clsViewshapePoint = _

CType(mMap.viewshapePointList.Item(viewshapeID), clsViewshapePoint)

'center pointIcon to pointCoordinates and draw image

If Not myViewshape.getBitmap Is Nothing Then

g.DrawImage(myPen.getBitmap, _

New PointF(coords(0).X _

- CType((myViewshape.getBitmap.Width / 2), Single), _

coords(0).Y _

- CType((myViewshape.getBitmap.Width / 2), Single)))

Else

...


Die Methode DrawImage hat die Eigenart, dass sie Bitmaps so zeichnet, dass aufdem übergebenen Koordinatenpaar die linke obere Ecke des Bitmaps platziert wird. Ausdiesem Grund ist eine Korrektur der Koordinaten notwendig, um das Bitmap so zu plat-zieren, dass dessen Zentrum über dem Koordinatenpaar liegt. Diese Korrektur ist nichtmit der Korrektur der Achsenverschiebung aus dem vorangegangenen Abschnitt zu ver-wechseln. Bei der Achsenkorrektur handelte es sich um ein Darstellungsproblem wegender Transformation, bei dieser Korrektur hingegen handelt es sich um ein Darstellungs-problem, das hervorgerufen wird durch eine GDI+interne Methodenimplementierung. Fürdiese Korrektur wird ermittelt, wie die Ausmaÿe des Bitmaps sind, und das Bitmap wirdum die Hälfte dieser Ausmaÿe versetzt gezeichnet (siehe Codeabschnitt zuvor).

Ist die Darstellungsform jedoch nicht de�niert durch ein Bitmap, so wird geprüft,ob der Alpha-Kanal der in der Darstellungsform gespeicherten Farbe gröÿer ist als 0.Denn wäre der Alpha-Kanal 0, dann wäre das zu zeichnende graphische Objekt absoluttransparent und somit nicht sichtbar. Auf das Zeichnen eines unsichtbaren Objekts kannverzichtet werden, weshalb eine solche Überprüfung direkt zu Beginn durchgeführt wird.Abhängig vom Typ der Darstellungsform (siehe 4.2.1 - vorde�nierte Formen Kreis, Drei-eck und Rechteck) werden verschiedene GDI+-Methoden FillPolygon, FillRectangleund FillEllipse genutzt. Diese Methoden erwarten als Parameter Brush-Objekte (siehe3.2.3). Diese werden zuvor aus der Farbe, die in der Darstellungsform (Viewshape) de�-niert ist, erzeugt. Da für ein dreieckiges Objekt keine spezielle GDI+-Methode existiert,wird die Methode für Polygone genutzt. Dazu werden drei Eckpunkte für ein Dreieck miteiner Gröÿe, wie sie in der Darstellungsform de�niert ist, berechnet. Diese drei Punktewerden der FillPolygon-Methode übergeben, die das Dreieck mit dem zuvor erzeug-ten Brush zeichnet. Siehe hierzu folgenden Codeausschnitt, der den Rest des vorherigenCodeausschnitts zeigt:

...

If myViewshape.colorARGB.A > 0 Then

Dim myBrush As SolidBrush = New SolidBrush(myViewshape.colorARGB)

Select Case myViewshape.getPointType

Case myViewshape.PointType.Rectangle

'center pointIcon to pointCoordinates

Dim cPoint As New PointF(coords(0).X - CType((myViewshape.getWidth / 2), Single), _

coords(0).Y - CType((myPen.getHeight / 2), Single))

g.FillRectangle(myBrush, cPoint.X, cPoint.Y, _

myViewshape.getWidth, myViewshape.getHeight)

Case myViewshape.PointType.Triangle

' tmp Points for triangle

Dim tmpPointsTriangle(2) As PointF

' topcorner

tmpPointsTriangle(0) = _

New PointF(coords(0).X, _

coords(0).Y - CType((myViewshape.getHeight / 2), Single))

' leftcorner


New PointF(coords(0).X - CType((myViewshape.getWidth / 2), Single), _

coords(0).Y + CType((myViewshape.getHeight / 2), Single))


' rightcorner


New PointF(coords(0).X + CType((myViewshape.getWidth / 2), Single), _

coords(0).Y + CType((myViewshape.getHeight / 2), Single))

'draw triangle

g.FillPolygon(myBrush, tmpPointsTriangle)

Case Else

'center pointIcon to pointCoordinates

Dim cPoint As New PointF(coords(0).X - CType((myViewshape.getWidth / 2), Single), _

coords(0).Y - CType((myViewshape.getHeight / 2), Single))

g.FillEllipse(myBrush, cPoint.X, cPoint.Y, _

myViewshape.getWidth, myViewshape.getHeight)

End Select

End If 'of If myViewshape.colorARGB.A > 0 Then ...

End If 'of If Not myViewshape.getBitmap Is Nothing Then ...

End If 'of If coords.Length > 0 Then ...

End Sub

drawLines(...)

Linienhaft modellierte Geoobjekte benötigen mindestens zwei Koordinatenpaare, die ih-re Länge de�nieren. Diese Koordinatenpaare erwartet die drawLines(...)-Methode in derdurch world2screen(...) transformierten Version. Anhand der Eigenschaften des Viewsha-pes wird ein Pen-Objekt instanziiert, mit dem die Linie daraufhin durch die MethodeDrawLines der Zeichen�äche gezeichnet wird:

Private Sub drawLines(ByRef coords As PointF(), _



Dim myViewshape As clsViewshapeLine = _

CType(mMap.viewshapeLineList.Item(viewshapeID), clsViewshapeLine)

If coords.Length > 1 And myViewshape.colorARGB.A > 0 Then

Dim drawingPen As Pen = New Pen(myViewshape.colorARGB)

drawingPen.DashStyle = myViewshape.dashStyle

drawingPen.StartCap = myViewshape.startLineCap

drawingPen.EndCap = myViewshape.endLineCap

drawingPen.DashCap = myViewshape.dashCap

drawingPen.Width = myViewshape.getWidth

g.DrawLines(drawingPen, coords)

End If

End Sub

Die DrawLines-Methode wurde hier eingesetzt, da bei der Modellierung kein Unter-schied gemacht wurde zwischen Linien und Linienzügen (siehe Kapitel 4). Um das lini-enhafte Objekt zeichnen zu können, benötigt die DrawLines-Methode ein sogenanntesPen-Objekt, womit die Linie gezeichnet werden soll. Linien lassen sich ausschlieÿlich mitdiesem Objekt zeichnen, das mehr Eigenschaften bietet und den ermittelten Bedürfnissenfür die Darstellung linienhaft modellierter Geoobjekte genügt. Diese Eigenschaften zurGestaltung der Farbe (.colorARGB), Gröÿe (.Width), Form (.DashCap), Muster (.Das-hStyle) und Richtung (.StartCap / .EndCap) werden gesetzt durch die entsprechenden


Eigenschaften der in dieser Arbeit modellierten Darstellungsformen für Linien (siehe 4.2.1und 4.4.1). Da es keinen Sinn macht eine Linie zu zeichnen, die nur eine Koordinate hatoder gar unsichtbar ist, wird die Zeichenmethode bedingt durch eine Abfrage zur Anzahlder Koordinatenpaare und der Transparenz der Darstellungsform ausgeführt:

If coords.Length > 1 And myViewshape.colorARGB.A > 0 Then

...

End If

Um eine falsche Darstellung von linienhaften Geoobjekten zu vermeiden, die durchmehr als zwei Koordinatenpaare de�niert sind, müssen die in coords enthaltenen Koor-dinatenpaare in der richtigen Reihenfolge vorliegen. Darauf wird schon beim Einlesen derGeoobjektdaten aus der Datenbank geachtet, indem die SQL-Anfrage mit ORDER BYseqPos sortiert gestellt wird.

drawAreas(...)

Bei der Entwicklung des MapGENeric-Systems wurde es für sinnvoll erachtet, Flächendarzustellen durch eine Farbfüllung, Texturfüllung oder Umrandung. Dabei sollen dieseFüllungen sich nicht gegenseitig ausschlieÿen, sondern miteinander kombinieren lassen. Beider Kombination ist auch eine feste Reihenfolge sinnvoll, die einzuhalten ist: 1. Farbfül-lung, 2. Texturfüllung und 3. Umrandung. Diese Reihenfolge ergibt sich aus den folgendenÜberlegungen:

Die Darstellung einer Linie in GDI+ erfolgt durch ein sogenanntes Pen-Objekt. DiesesPen-Objekt kann bildlich als ein Stift aufgefasst werden, der neben weiteren Eigenschafteneine Farbe und eine Dicke hat. Soll nun eine Linie, die durch zwei Koordinatenpaarede�niert ist, mit diesem Stift dargestellt werden, so erfolgt dies durch eine zentrierteVerbindung dieser beiden Koordinatenpaare, d.h. ist dieser Stift beispielsweise zehn Pixelbreit de�niert, so liegen fünf dieser Pixel auf der einen Seite der Linie und fünf auf deranderen Seite.

Private Sub drawAreas(ByRef coords As PointF(), _



If coordinates.Length > 2 Then

Dim myViewshape As clsViewshapeArea =

CType(mMap.viewshapeAreaList.Item(viewshapeID), clsViewshapeArea)

If myViewshape.colorARGB.A > 0 Then

Dim myBrush As SolidBrush = New SolidBrush(myViewshape.colorARGB)

g.FillPolygon(myBrush, coords, Drawing2D.FillMode.Alternate)

End If

If Not myViewshape.getBitmap Is Nothing Then

Dim myTextureBrush As TextureBrush = New TextureBrush(myViewshape.getBitmap)

g.FillPolygon(myTextureBrush, coords, Drawing2D.FillMode.Alternate)

End If

If Not myViewshape.border Is Nothing Then ' myViewshape.border includes

drawLines(coords, myViewshape.border, g) ' a viewshapeLineID

End If

End If

End Sub


Eine Fläche wird in GDI+ de�niert durch eine Grenzlinie, die durch eine geordneteFolge von Koordinatenpaaren de�niert wird. Die Darstellung einer solchen Fläche durcheine Farbfüllung kann beschrieben werden durch die Vorstellung, dass ein Eimer Farbe indiese Fläche gegossen wird, und diese Farbe an der Grenzlinie nicht nach Auÿen �ieÿenkann. Genauso ist auch die Texturfüllung nur bis zu dieser Grenzlinie möglich. Angenom-men diese Grenzlinie würde durch ein Pen-Objekt gezeichnet und daraufhin erst die Flächedurch eine Farb- oder Texturfüllung dargestellt werden, so würde die zuvor gezeichneteGrenzlinie bis zur Hälfte ihrer Breite überdeckt werden. Dies war der Anlass dafür, dieUmrandung erst als letztes zeichnen zu lassen. Die Kombination einer Umrandung vonFlächen mit ihrer Füllung ergibt sich aus der Überlegung, dass gleichartige Flächen (bei-spielsweise Bundesländer der BRD) nicht unterscheidbar wären, wenn eine Anwendungverlangen würde diese in einer einheitlichen Farbe oder einem einheitlichen Muster dar-zustellen. Durch eine Umrandung der Flächen würden Grenzen sichtbar gemacht werdenkönnen, so dass die Flächen wieder unterscheidbar würden.

Der Grund für die Darstellung einer Texturfüllung erst nach einer Farbfüllung ist, dasssich dadurch weitere Möglichkeiten ergeben. Da für die Textur Bitmaps zugelassen sind,die auch transparente Bereiche aufweisen dürfen, ist es sinnvoll die Fläche erst mit einerFarbe zu befüllen und später das teilweise transparente Muster darüber zu legen. Dadurchkönnen Anwendungen genüge getan werden, die dasselbe Muster über verschieden gefärbteFlächen darstellen möchten, um beispielsweise bundeslandübergreifende Gegebenheitendarzustellen.

Kapitel 8

Zusammenfassung und Ausblick

8.1 Zusammenfassung

Ziel dieser Arbeit war es, einen generischen 2D-Kartengenerator auf Basis relationalerGeodatenbanken zu entwerfen und zu implementieren, der unabhängig von Datenbank-schema und DBMS arbeitet. Dazu notwendige Grundlagen aus der Geographie und derInformatik wurden ausgewählt und erläutert im Hinblick auf eine zeit- und technologiege-mäÿe Bearbeitung der Aufgabenstellung. Beispielsweise wurde die Programmierplattform.NET eingesetzt, weil diese unter anderem das Programmieren mit aktuellen Softwaretech-nologischen Konzepten wie Namespaces, Schnittstellen, Kapselung, Vererbung, Polymor-phismus und Exception-Handling unterstützt. Ferner bietet .NET mit ADO.NET eineSchnittstelle zu vielen Datenquellen, wie beispielsweise verschiedene DBMS und XML-Dateien. Diese Eigenschaft der .NET-Plattform war ausschlaggebend bei der Anbindungdes MapGENeric-Systems an verschiedene DBMS, von denen ausschlieÿlich die Anbin-dung von Microsoft R© Access exemplarisch implementiert wurde. Jedoch wurde das Ge-samtsystem so entworfen, dass es einfach möglich ist, Schnittstellen für weitere DBMS zuimplementieren. Dies wurde durch einen komponentenbasierten Entwurf ermöglicht.

Mit dem Wissen aus den Grundlagen zur Kartographie und zu Geoinformationssys-temen wurde ein Beispiel erstellt, das die Anforderungen an das zu entwickelnde Systemzur Darstellung von Bildschirmkarten repräsentierte. Notwendige Darstellungsvariablenzur Darstellung von Geoobjekten wurden intensiv diskutiert. In dieser Diskussion konntenKombinationen von Darstellungsvariablen für jede Geoobjekt-Basisklasse (Punkt, Linieund Fläche) identi�ziert werden, anhand derer eine möglichst hohe Darstellungsvielfalterreicht wurde, die wiederum die Darstellungsmöglichkeiten aktueller Kartengeneratorennahe zu ganz erreicht. Diese wurden leider nicht ganz erreicht, da beispielsweise die Kom-bination aus mehreren Linien, wie sie zur Darstellung von Autobahnen in herkömmlichenProgrammen genutzt wird (gelbe Linie mit je einer dünneren roten Linie auf beiden Sei-ten), nicht möglich ist. Auf solche Darstellungsmöglichkeiten musste verzichtet werden,da der Schwerpunkt der Arbeit in der generellen Machbarkeit eines generischen Karten-generators lag und beides aus Zeitmangel nicht miteinander vereinbart werden konnte.

116

8.1 Zusammenfassung 117

Grundlage einer weiteren Diskussion war die Darstellung von Bildschirmkarten mitihren Randangaben und ihren Funktionalitäten bzw. Interaktionsmöglichkeiten, die beider Entwicklung eines Kartengenerators für ein solches System beachtet werden müssen.Dabei wurden zu entwickelnde Randangaben und Funktionalitäten bestimmt, wie Karten-titel, Maÿstab, Zooming, Navigation und mehr, die in die Implementierung einge�ossensind.

In diesen Diskussionen wurde festgestellt, dass drei Komponenten bei der Kartenge-nerierung existieren: Gruppierung ähnlicher Geoobjekte (Klassi�kation), graphische Dar-stellung dieser Geoobjekte (Darstellungsformen) und die Zuordnung zwischen Geoobjek-ten und Darstellungsform (Mapping). Einen entscheidenden Teil des Entwurfs und derKonzeption hat die Dynamisierung dieser bis dato statischen Komponenten bisherigerKartengeneratoren eingenommen. Diese Komponenten wurden einzeln bezüglich Dyna-misierungsmöglichkeiten diskutiert. Dabei wurden Stärken und Schwächen verschiedenerMöglichkeiten ermittelt und dargestellt. Die Zusammenführung der einzeln ermitteltenDynamisierungsmöglichkeiten wurde durch ein regelbasiertes Modell erreicht. Dies warmöglich, weil eine ausschlieÿlich automatische Klassi�kation von Geoobjekten grundsätz-lich auszuschlieÿen ist, so dass ein Akteur (Kapitel 4.4) notwendig wird, der Geoobjektebestimmt und ihre Darstellungsformen de�niert. Bei der Erstellung von analogen Kartensind hierfür Kartographen bzw. Kartenautoren zuständig, deren redaktionelle Arbeit undKreativität die Güte einer Karte ausmachen. Bei der Entwicklung bisheriger Kartengene-ratoren sind ebenfalls Kartenautoren beteiligt, jedoch werden diese zu Rate gezogen bevorein Kartengenerator erstellt wird, damit dieser Darstellungsformen entwerfen kann für eine"gute"Bildschirmkartendarstellung. Werden im Nachhinein Änderungen notwendig, sinddiese kompliziert mit Hilfe der Programmierer der Kartengeneratoren im Quellcode zuverwirklichen. Durch das regelbasierte Modell, das zuvor genannt wurde, ist es möglichGeoobjektklassen aus Geodatenbanken zu de�nieren, deren Schema dem MapGENeric-System nicht bekannt ist, die Darstellungsform dieser Geoobjektklassen zu de�nieren undsie einander zuzuordnen. Des weiteren wurde es ermöglicht mehrere VM-Regeln zu ei-ner Kon�guration des Systems zu bündeln, so dass mit unterschiedlichen Kon�gurationenverschiedene Anwendungen auf derselben Geodatenbank möglich sind. Dazu war es not-wendig eine Regelsprache zu de�nieren, die diese Eigenschaften ermöglicht und somit diedrei identi�zierten Komponenten elegant zusammenführt.

Ein Schwerpunkt bildete bei der Regelsprache die Klassi�kationskomponente, die fürdie Gruppierung von Geoobjekten notwendig ist. Da diese unabhängig von Datenbank-schema und Datenbanksystem zu sein hatte, wurde nach einer Möglichkeit gesucht, diedurch den Groÿteil existierender Datenbanksysteme unterstütz wird. In SQL wurde eineeinfache jedoch sehr e�ektive Lösung gefunden, die von den meisten DBMS unterstütztwird. Basierend auf Sichtde�nitionen in SQL, wurde die Regelsprache so de�niert, dasses mit ihr möglich ist, eine Klassi�kation durch De�nition einer Sicht auf Geoobjekte zuverwirklichen. Diese Sichtde�nitionen müssen ein bestimmtes Schema haben, damit Map-GENeric die für die Darstellung der Geoobjekte notwendigen Geometriedaten erhält.

118 Kapitel 8. Zusammenfassung und Ausblick

Für Bildschirmkarten, die durch MapGENeric erzeugt werden sollen, ist in den vor-angegangenen Diskussionen der Wunsch entstanden, dass diese interaktiv sind, d.h. zubestimmten dargestellten Geoobjekten sollten weitere nicht-graphische Eigenschaften an-gefordert werden können. Dies ist ebenfalls möglich mit einer weiteren Sichtde�nition, diedieselbe Menge der Geoobjekte de�niert, wie die Sichtde�nition zur Klassi�kation, jedochin ihren Spalten nicht-graphische Eigenschaften zu diesen Geoobjekten enthält. Map-GENeric kann auf diese Sicht eine SQL-Anfrage mit der ID des ausgewählten Geoobjektsstellen und erhält die durch diese Sicht de�nierten nicht-graphischen Eigenschaften.

Eine der Komponenten, die durch die Regelsprache mitbedacht werden musste, ist dieDe�nition der Darstellungsformen für die jeweiligen Geoobjekte. In den vorangegangenenDiskussionen ausgearbeitete Kombinationen von Darstellungsvariablen, die für die Dar-stellung der Geoobjekte einer Basisklasse dienen, mussten in diese Regelsprache mitinte-griert werden. Die Regelsprache mit den zuvor genannten Eigenschaften wurde abkürzendVRL genannt und ihre Grundkonzepte anhand eines ER-Diagramms näher erläutert. Diestrug zum besseren Verständnis der Beziehungen zwischen den Sprachelementen bei, diedaraufhin formal durch die BNF-Notation de�niert wurden.

Nachdem für MapGENeric notwendige Komponenten modelliert worden sind, wur-de eine Gesamtarchitektur für MapGENeric vorgestellt, die zu implementieren war. Indieser Gesamtarchitektur wurde der Kartengenerator als zentrale Komponente model-liert. Um die Leistungsfähigkeit des Kartengenerators darstellen zu können, wurde einegraphische Nutzer-Schnittstelle implementiert. Diese bietet die Funktionalitäten, die voneinem modernen System zur Darstellung von Bildschirmkarten erwartet werden kann. Siestellt neben der Bildschirmkarte ihren Kartentitel und ihren Maÿstab dar. Des weiterenermöglicht sie verschiedene Manipulationen an der Kartendarstellung, durch Zooming,Navigation, Ein-/Ausblendemöglichkeiten der Layer. Weiterreichende Informationen ne-ben der Karte stellt sie ebenfalls dar, wie Realweltkoordinaten der Mausposition auf derKarte und zuvor erwähnte nicht-graphische Eigenschaften zu einem Geoobjekt auf Anfor-derung des Nutzers per Mausklick.

Um eine komfortable Eingabe der VM-Regeln bieten zu können wurde auch eineSchnittstelle für Kartenautoren implementiert. Diese bietet durch unterstützende Hil-festellungen textueller Form zu allen Elementen des VRL (Visualisierungs-Regelsprache)eine intuitiv zu bedienende Eingabemaske. Schritt für Schritt ist es dem Kartenautordadurch möglich, Kon�gurationen für verschiedene Anwendungen auf derselben Geoda-tenbank zu erstellen. Dabei wurden alle syntaktischen und semantischen Restriktionen desVRL berücksichtigt, so dass bei Fehleingaben erläuternde Fehlerhinweise darauf hinweisen.

Bei der Modellierung der Hauptkomponente des MapGENeric, dem Kartengenerator,wurde, wie auch bei der Gesamtarchitektur, groÿen Wert darauf gelegt, diese Modular zugestalten, so dass diese im Nachhinein durch evtl. leistungsfähigere Module ausgetauschtwerden können. Zu diesen Modulen gehören, Con�guration Loader, Geoobject Loader,Projection Transformer und Layer Generator. Diese Module wurden genauer betrachtet,um die Implementierung des Systems darzustellen. Je interessanter die Techniken bei derImplementierung wurden, umso detaillierter wurde ihre Darstellung.

8.2 Ausblick 119

In den Grundlagen ist zu sehen, dass ein weiterer wichtiger Aspekt bei der Generierungvon Karten aus Geodatenbanken die Kartenprojektion darstellt. Da die Kartenprojektionjedoch lediglich eine Umsetzung einer bereits vorhandenen Funktion darstellt, wurde siein der Implementierungsdarstellung weniger detailliert erläutert. Da jedoch für verschie-dene Anwendungen die eine oder andere Kartenprojektion besser geeignet ist, wurde dieKartenprojektion in ein eigenes Modul ausgelagert (Projection Transformer). Dadurchist eine weitere Dynamik des Gesamtsystems entstanden, weil die Kartenprojektion jenach Bedarf durch eine andere ersetzt werden kann. Dazu ist es ausreichend, die Imple-mentierung der neuen Kartenprojektion an die Schnittstelle des MapGENeric-Systemsanzupassen.

Der Layer Generator ist für die Generierung der Layer und der darauf gezeichnetenRepräsentations-Objekte zuständig, weshalb ihre Implementierung besonders hervorgeho-ben wurde. Dabei wurde auf Teilprobleme dieses Moduls bis in Codeebene eingegangen.Um jedoch den Rahmen dieser Diplomarbeit nicht zu stark auszudehnen, musste nebenvielen anderen beispielsweise auf die Darstellung des voll ausgeschöpften technologischenSpektrums von ADO.NET bei der Schnittstellen- und Kartenautor-GUI-Implementierungverzichtet werden.

8.2 Ausblick

Diese Arbeit hat einen Einblick in die Bildschirmkartengenerierung gegeben und es wurdeein Konzept erarbeitet und implementiert, das die generische Kartengenerierung erlaubt.Diese Arbeit stellt einen guten Ausgangspunkt für weitere Forschungen in der generischenKartengenerierung dar.

Ein umfangreiches Teilgebiet der Darstellung von Bildschirmkarten wurde in dieser Ar-beit nicht bearbeitet. Dieses Teilgebiet ist die Darstellung der Topologie, die Beziehungenzwischen Geoobjekten beschreibt. Damit ist nicht die visuelle Beziehung von Geoobjektengemeint, die in dieser Arbeit wieder zu �nden ist. Beispielsweise wäre es wünschenswertin einem Bahnnetz einen Bahnhof anklicken zu können, um zu erfahren, welche Zugliniendiesen passieren oder, ob es eine direkte Verbindung zum Zielbahnhof gibt, bei der esnicht notwendig ist umzusteigen. Dieses Beispiel bezieht sich auf eine in der Geodaten-bank speziell modellierte Topologie. Jedoch sind durch geometrische Analysen auch nichtmodellierte Topologien darstellbar. Folgend seien einige aufgezählt:

• Kürzeste Wege in einem Netzwerk

• Liegt ein Punkt auf einer Geraden?

• Liegt ein Punkt in einer Fläche oder auÿerhalb?

• Wie groÿ ist die Fläche?

• Wie weit sind zwei Punkte voneinander?

120 Kapitel 8. Zusammenfassung und Ausblick

Wenn die Darstellung einer Bildschirmkarte auf Papier ausgegeben werden soll, istbei herkömmlichen Programmen eine exakte Abbildung der Bildschirmkarte auf Papiervorgesehen. Wie in dieser Arbeit jedoch gezeigt wurde, ist das Medium Papier für diegleichzeitige Darstellung von mehr Informationen besser geeignet als der Bildschirm. Ausdiesen Beobachtungen heraus bietet es sich an, die Regelsprache VRL, die in dieser Ar-beit de�niert wurde, weiter auszubauen für die Zusätzliche De�nition der Darstellungeiner Karte auf Papier.

Mit dem in dieser Arbeit entstandenen System wurde es einem potentiellen Kartenau-tor ermöglicht, die Darstellung von Geoobjekten mit ihrer Zeichenreihenfolge auch nochim Nachhinein zu gestalten, ohne auf einen Programmierer angewiesen zu sein. Beispiels-weise könnte die Möglichkeit weiter ausgearbeitet werden, die gesamte Kartendarstellungmit ihren Randangaben (Maÿstab, Kartentitel, . . . ) und Funktionalitäten (Navigation,Zooming) zu manipulieren, damit ein Kartenautor Karten noch besser an Nutzerkreiseund Anwendungen anpassen kann. Denkbar wäre hier eine Templatearchitektur, in der diefreie Positionierung und Gestaltung dieser Elemente und Schalt�ächen ermöglicht werdenwürde.

Denkbar für die Weiterentwicklung eines generischen Kartengenerators wäre auch dieKombinationsmöglichkeit von Vektordarstellung mit der Rasterdarstellung (siehe Kapitel2.2.3) nach dem Vorbild "Google Earth"(http://earth.google.com/), der durch seine 3D-Engine auch Probleme der Kartenprojektion umgeht, indem die Sicht auf den Erdgeoidim dreidimensionalen Raum berechnet wird.

Das in dieser Diplomarbeit entworfene und implementierte GesamtsystemMapGENericist trotz der aufgezählten Erweiterungsmöglichkeiten in der Lage einem Bildschirmkarten-Autor viele Möglichkeiten der Gestalltung zu bieten. In einer Zeit, in der die Entwick-lungskosten für Software immer höher steigen, ist ein Werkzeug wie MapGENeric nichtmehr wegzudenken.

Anhang A

VRL

A.1 Grammatik

<Konfigurationen> ::= <Konfiguration> |

<Konfiguration> <Konfigurationen>

<Konfiguration> ::= KONFIGURATION ( " <Name> " ) { <Konfig> }

<Konfig> ::= <VMRegel> | <Konfig> <VMRegel>

<VMRegel> ::= VMREGEL ( " <Name> " , <RegelPos> , <Sichtbarkeit> )


<Sichtbarkeit> ::= on | off

<Darstellungsform> ::= <PunktDF> | <LinieDF> | <FlaecheDF>

<PunktDF> ::= PUNKTDF ( <Laenge> , <Breite> )

{<Farbe> <PForm> <Bitmap>}

<Farbe> ::= FARBE ( ) |

FARBE ( <Alpha> , <Rot> , <Gruen> , <Blau> )

<Alpha> ::= [0..255]

<Rot> ::= [0..255]

<Gruen> ::= [0..255]

<Blau> ::= [0..255]

<PForm> ::= PFORM( ) |

PFORM(Ellipse) |

PFORM(Dreieck) |

PFORM(Rechteck)

121

122 Kapitel A. VRL

<Bitmap> ::= BITMAP ( ) |

BITMAP ( " <AbsoluterPfad> " )

<LinieDF> ::= LINIEDF ( <Breite> , <Muster> , <Anfang> , <Ende> )

{ <Farbe> <LForm> }

<Muster> ::= solid | dash | dot | dashdot | dashdotdot

<Anfang> ::= <Anchor>

<Ende> ::= <Anchor>

<Anchor> ::= ArrowAnchor | RoundAnchor | SquareAnchor | NoAnchor

<LForm> ::= LFORM( ) |

LFORM(flat) |

LFORM(round) |

LFORM(triangle)

<FlaecheDF> ::= FLAECHEDF { <Farbe> <Bitmap> <Umrandung> }

<Umrandung> ::= <LinieDF>

<Geoobjektklasse> ::= GEOOBJEKTKLASSE( " <Name> " , <BasisKlasse> )

{ <GeoObjSicht> <AttribSicht> }

<BasisKlasse> ::= Punkt | Linie | Flaeche

<GeoObjSicht> ::= GEOOBJEKTE ( <PunktGeoObjSicht> ) |

GEOOBJEKTE ( <SonstGeoObjSicht> )

<PunktGeoObjSicht> ::= SELECT

<Attr1> AS mge_id,


<Attr3> AS mge_lat,


FROM

<Tablist>

WHERE

<Bedingung>

<SonstGeoObjSicht> ::= SELECT

<Attr1> AS mge_id,


<Attr3> AS mge_lat,

A.2 Beispiel 123


<Attr5> AS mge_seqpos

FROM

<Tablist>

WHERE

<Bedingung>

A.2 Beispiel

Das folgende Beispiel ist nur ein Auszug aus der Kon�guration für das Touristik/Umwelt-Beispiel, weshalb am Ende drei Punkte untereinander andeuten sollen, dass es an derStelle weitergehen muss.

KONFIGURATION ("Touristenkarte I"){VMREGEL ("Hotels", 3, on){

GEOOBJEKTKLASSE ("Hotels > 200 Betten", Punkt){GEOOBJEKTE (

SELECTid AS mge_id,laengengrad AS mge_long,breitengrad AS mge_lat,name AS mge_label

FROMhotels

WHEREanzahl_zimmer > 200

)ATTRIBUTE (

SELECTid AS mge_id,'ID: ',id,'Name: ',name,'Zimmeranzahl: ',anzahl_zimmer,'Günstigstes Zimmer (Euro): ',preis

FROMhotels

)PUNKTDF (15, 15){

FARBE()FORM ()BITMAP("C:\Bilder\HotelIconKlein.gif")

124 Kapitel A. VRL

}}

}

VMREGEL ("Straÿenbahnhaltestellen", 4, on){GEOOBJEKTKLASSE("Straÿenbahnhaltestellen", Punkt){GEOOBJEKTE (

SELECTid AS mge_id,Laengengrad AS mge_long,Breitengrad AS mge_lat,'' AS mge_label

FROMstrassenbahnhaltestellen

)ATTRIBUTE (

SELECTid AS mge_id,'ID: ',id,'Name: ',name,'Kapazität: ',kapazitaet,'Linienanzahl: ',anzahl_linien


)PUNKTDF (5, 5){

FARBE(255, 34, 32, 209)FORM (Ellipse)BITMAP()

}}

}

VMREGEL ("Einbahnstraÿen", 2, on){GEOOBJEKTKLASSE("Straÿen", Linie){GEOOBJEKTE (

SELECTid AS mge_id,Laengengrad AS mge_long,Breitengrad AS mge_lat,Name AS mge_label


)

A.2 Beispiel 125

ATTRIBUTE (SELECT

id AS mge_id,'ID: ',id,'Name: ',name,'Kapazität: ',kapazitaet,'Linienanzahl: ',anzahl_linien


)LINIEDF (3, solid, NoAnchor, ArrowAnchor){

FARBE (255, 255, 255, 255)FORM (RECTANGLE)

}}

}

VMREGEL (Land, 1, on){

GEOOBJEKTKLASSE("Laubwald", Fläche){

.

.

.}

Anhang B

DB-Schnittstelle

Die MapGENeric-DB-Schnittstelle besteht aus einer Sammlung der Klassen clsConnecti-on, clsLayerDBReader, clsMapObjectsDBReader, clsViewshapeDBReader und clsAttribu-tesDBReader. Diese wiederum nutzen Klassen der ADO.NET, die mit Hilfe der MicrosoftJet Database Engine und eines OLEDB-Datenproviders den Zugri� auf die Geodatenban-ken gestatten.

B.1 clsConnection

Die Klasse clsConnection baut die Verbindung zu einer über das GUI ausgewählten,Access-Geodatenbank auf. Da keine weiteren Verbindungen benötigt werden, wurde dieseKlasse nach dem Singleton-Pattern entworfen. Design Patterns, zu denen das Singleton-Pattern zählt, sind Muster bzw. Schablonen für oft wiederkehrende Klassenarchitekturenund beschleunigen die Entwicklung solcher Klassen. Das Singleton-Pattern sichert ab, dasseine Klasse genau ein Exemplar besitzt und stellt einen globalen Zugri� darauf bereit. DieKlasse clsConnection dient während der gesamten Laufzeit allen anderen Komponentender Datenbank-Schnittstelle als zentraler Zugri�spunkt. Sie holen sich über die MethodegetConnection das eine Exemplar, um die Verbindung zur Datenbank aufzubauen.

B.2 clsLayerDBReader

Die clsLayerDBReader -Klasse wird einmal beim Auslesen der Layerliste benötigt, direktnachdem entweder über das Nutzer-GUI oder über den Kon�gurations-Assistenten eineDatenbank ausgewählt wurde. Sie überführt in der Datenbank vorliegende Layer in eineinterne Objektstruktur. Als Ergebnis liefert sie daraufhin eine Liste dieser systeminternenLayer-Objekte.

B.3 clsMapObjectsDBReader

Die zuvor erstellte systeminterne Liste von Layer-Objekten dient der clsMapObjectsD-BReader -Klasse als Vorlage, welche Geoobjektdaten dargestellt werden sollen und somitaus der Datenbank ausgelesen werden müssen. Dazu werden alle Visualisierungs-Regeln

126

B.4 clsViewshapeDBReader 127

aus der Datenbank ausgelesen, die mit Layern verknüpft sind, die wiederum in der syste-minternen Layer-Objekte-Liste als sichtbar de�niert sind. Daraufhin werden Geoobjektefür sichtbare Layer in dieser Liste ausgelesen, und in den jeweiligen Layern gespeichert.Jedes Geoobjekt erhält neben ihren Geometriedaten ihre Darstellungsform, die durch dieVisualisierungs-Regel de�niert wird. Ferner erhält jedes Geoobjekt die Sichtde�nition aufihre weiteren Eigenschaften.

Eine weitere Aufgabe die die clsMapObjectsDBReader -Klasse übernimmt ist das Er-mitteln der �OriginWorldViewRange� (siehe Kapitel ??). Hierzu wird beim Einlesen derGeoobjektdaten ermittelt, ob ihre Koordinaten innerhalb oder auÿerhalb des aktuellen�OriginWorldViewRange� liegen. Wenn sie auÿerhalb liegen, wird der aktuelle �Origin-WorldViewRange� angepasst.

B.4 clsViewshapeDBReader

Die Komponente clsViewshapeDBReader der DB-Schnittstelle dient zum auslesen derDarstellungsformen, und wird wie auch andere Komponenten die zur Kon�guration desSystems benötigt werden direkt nach der Auswahl der Datenbank ausgeführt. Für jedeTabelle mit Darstellungsformen (es gibt drei, für jede Basisklasse eine) wird eine syste-minterne Liste erstellt, in die die jeweiligen Darstellungsformen eingelesen werden.

B.5 clsAttributesDBReader

Um weitere Eigenschaften eines Geoobjektes anzeigen zu können, müssen diese ersteinmalausgelesen werden. Dies übernimmt die DB-Schnittstellen-Komponente clsAttributesD-BReader. Bei Anforderung durch den Nutzer über den Karten-Bereich des Nutzer-GUIwird das ausgewählte Geoobjekt übergeben, woraus sich die Komponente die Sichtde�-nition für Attribute ausliest und diese mit der ID des Geoobjekts ergänzt. Die auf dieseWeise entstehende Select-Anweisung wird daraufhin auf die Datenbank angewandt.

Literaturverzeichnis

[Ber74] BERTIN, J.: Graphische Semiologie. Berlin-New York, 1974

[BF94] Bill, R., und Fritsch: Grundlagen der Geo-Informationssysteme, Band 1: Hardwa-re, Software und Daten:Wichmann, 1994

[BK01] Bollmann u. Koch (Hrsg.): Lexikon der Kartographie und Geomatik, SpektrumVerlag, ISBN382741055X, 2001

[Bol05] Bollmann, J.: Einführung in die Kartographie; WS 2004/2005 http://kws01.uni-trier.de:8000/p/d/skript0405.pdf

[Cha03] Chand, Mahesh: Graphics Programming with GDI+, Addison Wesley, ISBN :0-321-16077-0, 2003

[Den99] Dent, B. D.: Cartography, Thematic Map Design; 5th Edition, McGraw-Hill,1999

[DZ99] Dickmann, F. und Zehner, K.: Computerkartographie und GIS, 1. Au�age, Wes-termann Verlag, 1999

[FS00] Fowler, M. und Scott, K.: UML konzentriert, 2. Au�age, Deutsche Übersetzung,Addison-Wesley Verlag, 2000

[Grü95] Grünreich, D.: Development of Computer-Assisted Generalization on the Basisof Cartographic Model Theory, in Müller, Lagrange u. Weibel, Seiten 47�55, 1995

[HG94] Hake, G.; Grünreich, D. : Kartographie; 7. Au�age, de Gruyter, Berlin, 1994

[Hey01] Heyn, Jürgen : http://www.heliheyn.de/Maps/Merca.html (03.06.2005)

[Imh72] Imhof, E.: Thematische Kartographie; Lehrbuch der Allgemeinen Geographie,Band 10; de Gruyter, Berlin, 1972

[JDF02] Joshi, Bipin et al.: Professional ADO.NET; ISBN 186100527X, Wrox Press Ltd2002

[KE01] Kemper, A. und Eickler, A.: Datenbanksysteme, 4. Au�age, Oldenbourg Wissen-schaftsverlag, 2001

128

Literaturverzeichnis 129

[Kri99] KRIZ, K.: Perspektiven in der Kartographie. In: KRETSCHMER, I., KRIZ,K.(Hrsg.): 25 Jahre Studienzweig Kartographie. Wien, Institut für Geographie derUniversität Wien, 1999 (=Wiener Schriften zur Geographie und Kartographie, Band12).

[Lin98] LINKE, W.: Orientierung mit Karte, Kompaÿ, GPS: Grundwissen - Verfahren �Übungen. Herford, Busse Seewald, 1998, 9. Au�age, 256 Seiten

[Man99] Prof. Dr. Rainer Manthey: Skript zu Informationssysteme; Rheinische FriedrichWilhelm Universität Bonn; WS99/00

[Mat97] MATTHIAS, E.: Nutzungsmöglichkeiten der neuen Ausgabeformen. In: DEUT-SCHE GESELLSCHAFT FÜR KARTOGRAPHIE E.V. (Hrsg.): Digitale Karten-technologie. 21. Arbeitskurs Niederdollendorf 29.9. bis 2.10.1997. Königslutter amElm. Bonn, Kirschbaum Verlag (= Kartographische Schriften, Band 3). 1997

[Mit05] http://www.mittelalter-server.de/Mittelalter-Karten/Das-Mittelalter_ma_karten.html (14.04.2005)

[MB89] Carl Moreland and David Bannister: Antique Maps; Third edition 1989; PhaidonPress Limited; c© Carl Moreland and David Bannister 1983 JSBN 07148 2954

[MSEnc] Microsoft Encarta Weltatlas, Software-Atlas des Unternehmens Microsoft

[Pto05] http://wwwuser.gwdg.de/ fhasele/ptolemaeus/index.html (14.04.2005)

[Rae05] Rätsel der Menschheit: http://rdmteam.piranho.at/artefakte/pirireis/pirireis.htm(14.04.2005)

[Rob93] ROBINSON, G.: The NERC Marine Atlas demonstrator: the development ofan electronic atlas. In: THE BRITISH CARTOGRAPHIC SOCIETY (Hrsg.): TheCartographic Journal. Blackpool, BPCC Blackpool Ltd., Volume 30., 1993

[RP96] Ruas, A. and Plazanet, C.: Strategies for automated generalization, in Kraak undMolenaar (1996), Seiten 6.1�6.18.

[Sce02] David Sceppa: Microsoft ADO.NET (core reference), Microsoft Press, Redmond,Washington 98052-6399, 2002

[Str02] Strathern, Paul: Archimedes u. der Hebel, Frankfurt am Main 2002. ISBN3596141176

[Str05] Streit, Ulrich: Skript zur Vorlesung �Einführung in die Geoinformatik� an derUniversität Münster im WS 2005

[Töp92] Töpfer, F.: Zur Bedeutung der kartographischen Generalisierung für Geo-Informationssysteme, Kartographische Nachrichten Heft 42(1), 12�20, 1992

[Wag62] Karlheinz Wagner, Kartographische Netzentwürfe, Bibliographisches InstitutMannheim, 2. Au�age 1962

130 Literaturverzeichnis

[WD04] Worboys, M. and Duckham, M.: GIS - A Computing Perspective, Second Edition,CRC Press, ISBN 0-415-28375-2, 2004

[WikiTopo] http://de.wikipedia.org/wiki/Topographie (15.04.2005)

[WikiGeoDat] http://de.wikipedia.org/wiki/Geodaten (17.04.2005)

Erklärung

Bonn, 13. September 2005

Hiermit erkläre ich, dass ich vorliegende Diplomarbeit selbständig durchgeführt undkeine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlichgemacht habe.

Ahmet Devrim

entwurf und implementierung eines ... - idb.uni-bonn.de · rheinische...

Documents