Entwurf und Implementierung eines ... - idb.uni-bonn.de ?· Rheinische riedricFh-Wilhelms-Universität…

Download Entwurf und Implementierung eines ... - idb.uni-bonn.de ?· Rheinische riedricFh-Wilhelms-Universität…

Post on 18-Sep-2018

212 views

Category:

Documents

0 download

TRANSCRIPT

Rheinische Friedrich-Wilhelms-Universitt BonnInstitut fr Informatik IIIDiplomarbeitEntwurf und Implementierung eines generischen2D-Kartengenerators basierend auf relationalenGeodatenbankenAhmet Devrim13. September 2005Erstgutachter: Prof. Dr. Rainer MantheyDanksagungIch mchte 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 whrend meiner gesamten schulischen und akademischenLaufbahn in unterschiedlicher Form untersttzt haben. Ein ganz besonderer Dank gilt Herrn Prof. Dr. Manthey fr seine einzigartige undintensive Betreuung ber die gesamte Diplomarbeitsphase. Insbesondere haben un-zhlige fachliche Diskussionen mit ihm zu einer fortwhrend positiven Entwicklungder Arbeit beigetragen. Ein besonderer Dank gebhrt meiner Frau Fatma Poyraz-Devrim ebenfalls, die mirwhrend meines Studiums liebevoll zur Seite gestanden hat und ohne die ich meineZiele niemals erreicht htte. Fatma - mein Schatz ich liebe Dich! Bedanken mchte ich mich auch bei meinen Gymnasial-Lehrern Herrn MichaelMannheims und Herrn Karheinz Damerow, die mehr Freund als Lehrer waren, frihr persnliches Engagement whrend meiner Zeit auf dem Humboldt-Gymnasiumin Kln. Auch bei meiner Grundschullehrerin Frau Eva Kortmann mchte ich mich rechtherzlich bedanken, die meinen Start in das Schulleben htte nicht angenehmer undfrdernder gestalten knnen. Zu guter letzt mchte ich mich bei meiner Familie - Mehmet Devrim mein Vater,Fikriye Devrim meine Mutter und Glzar Devrim meine Schwester - bedanken, diemir all dies ermglicht haben, indem sie mich so viele Jahre in vielen Dingen auchneben Schule und Studium untersttzt und motiviert haben.Vielen lieben Dank!Ahmet DevrimInhaltsverzeichnis1 Einleitung 12 Grundlagen aus der Geographie 32.1 Kartographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Karten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Geoinformationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Geoobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Geodaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Grundlagen aus der Informatik 203.1 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.2 Entity-Relationship-Modell . . . . . . . . . . . . . . . . . . . . . . . 213.1.3 Relationales Datenmodell . . . . . . . . . . . . . . . . . . . . . . . 223.1.4 Relationale Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.5 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 GDI+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Entwurf - Methodologie - Konzept 364.1 Generische Visualisierung von 2D-Geoobjekten . . . . . . . . . . . . . . . . 364.1.1 Beispiel - Touristik/Umwelt . . . . . . . . . . . . . . . . . . . . . . 384.2 Visualisierung in MapGENeric . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1 Darstellung von Geoobjekten . . . . . . . . . . . . . . . . . . . . . 444.2.2 Bildschirmkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Visualisierungs-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.1 Bestandteile des Visualisierungs-Mappings . . . . . . . . . . . . . . 514.3.2 Dynamisierung des Visualisierungs-Mappings . . . . . . . . . . . . . 534.4 Regelbasierter Ansatz fr dasVisualisierungs-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4.1 Grundkonzepte der Regelsprache . . . . . . . . . . . . . . . . . . . 58iii Inhaltsverzeichnis5 Syntax und Semantik derRegelsprache VRL 655.1 VM-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 Kongurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 Darstellungsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.1 PunktDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.2 LinieDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.3.3 FlaecheDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.4 Geoobjektklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4.1 Punktfrmige Geoobjekte . . . . . . . . . . . . . . . . . . . . . . . 705.4.2 Flchenfrmige Geoobjekte . . . . . . . . . . . . . . . . . . . . . . 736 Architektur und Funktionalitt von MapGENeric 776.1 MapGENeric-Architektur im Kontext . . . . . . . . . . . . . . . . . . . . . 776.2 Autoren-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2.1 Geodatenbank whlen . . . . . . . . . . . . . . . . . . . . . . . . . 796.2.2 Geoobjektklassen erstellen/bearbeiten . . . . . . . . . . . . . . . . 816.2.3 Darstellungsformen erstellen/bearbeiten . . . . . . . . . . . . . . . 856.2.4 Visualisierungs-Regeln erstellen/bearbeiten . . . . . . . . . . . . . . 876.2.5 Kongurationen erstellen/bearbeiten . . . . . . . . . . . . . . . . . 886.3 Nutzer-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.3.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.3.2 Inforetrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.3.4 Zooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.3.5 Layermanipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 987 Implementierung 1007.1 Map Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.1.1 Conguration und Geoobject Loader . . . . . . . . . . . . . . . . . 1017.1.2 Projection Transformer . . . . . . . . . . . . . . . . . . . . . . . . . 1037.1.3 Layer Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.2 Module des Layer Generator . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.2.1 Generierung der Zeichenche - Layer . . . . . . . . . . . . . . . . . 1067.2.2 World To Screen - Koordinatentransformation . . . . . . . . . . . . 1077.2.3 Zeichnen der Reprsentations-Objekte . . . . . . . . . . . . . . . . 1118 Zusammenfassung und Ausblick 1168.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A VRL 121A.1 Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Inhaltsverzeichnis iiiB DB-Schnittstelle 126B.1 clsConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.2 clsLayerDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.3 clsMapObjectsDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.4 clsViewshapeDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127B.5 clsAttributesDBReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Kapitel 1EinleitungAuf Karten werden menschlicheWahrnehmungs- und Kognitionsfhigkeiten genutzt, groeInformationsmengen und komplexe Zusammenhnge visuell in graphischer Form schnellaufnehmen zu knnen. Mit dem Inhalt und der Darstellung von Karten beschftigt sich dieKartographie unter Bercksichtigung von Anwendung und Nutzerkreis der zu erstellendenKarte. Um eine Karte fr eine spezielle Anwendung und einen bestimmten Nutzerkreiserstellen zu knnen, muss ein Kartenautor redaktionelle Arbeit leisten. Dies ist Notwen-dig, da die Verstndlichkeit einer Karte unter anderem vom gegebenen Umfeld und demVorwissen des Nutzers abhngt. Herkmmliche Karten stellen Datenspeicher und visuel-le Darstellung in nur einem Medium dar. Von der Gte der redaktionellen Arbeit undden Erfahrungen des Kartenautors, beim Entwurf von Karten diesen begrenzten Spei-cher optimal auszunutzen und geeignete Techniken fr Darstellungen einzusetzen, wirddie Qualitt einer Karte in hohem Mae beeinusst.Im digitalen Zeitalter von grakfhigen Computern mit immer mehr Speicherkapazittknnen immer fter moderne Formen der herkmmlichen Karte angetroen werden, diemehr Informationen bieten als gedruckte Karten. Diese so genannten Bildschirmkarten, diehauptschlich im Rahmen von Navigationssystemen oder Internet-Informationssystemenvorzunden 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 prsentieren zuknnen. Da Bildschirmkarten im Vergleich zu herkmmlichen Karten auf Papier wesent-lich weniger Platz und Detailmglichkeiten bieten, knnen sie die Darstellung von mehrInformationen lediglich durch eine interaktive Schnittstelle zum Nutzer erreichen. Zurgraphischen Prsentation dieser Daten in Form von Bildschirmkarten werden unter an-derem in den oben genannten Programmen (Navigationssysteme, Internet-IS, GIS, usw.)kartengenerierende Softwarekomponenten (Kartengeneratoren) bentigt. Diese Kartenge-neratoren werden bisher anwendungs- und nutzerkreisbezogen entwickelt und basieren aufanwendungsbezogen modellierten Geodaten. Ferner ist bis dato fr die Entwicklung einessolchen Kartengenerators die Zusammenarbeit von Softwareentwicklern und Kartenauto-ren unerlsslich, um die Qualitt der Karte zu gewhrleisten. Ergibt sich im nachhinein,dass die Darstellung von Geoobjekten anders erfolgen soll oder dass sich die Struktur der12 Kapitel 1. EinleitungGeodaten gendert hat, so muss die Software durch den Entwickler diesen Gegebenheitenangepasst werden. Wnschenswert ist stattdessen ein generischer Kartengenerator, derunabhngig von Daten und Darstellung arbeitet, so dass eine Trennung von Daten, Logikund Design erreicht wird.Nach der Identizierung der vom Kartengenerator darzustellenden Geoobjektartenanhand eines Beispiels, sollen in dieser Arbeit notwendige Eigenschaften fr die Darstel-lung dieser Geoobjektarten ermittelt werden. Ferner sollen Bildschirmkarten im Hinblickauf Funktion, Layout und Interaktion diskutiert werden, um dabei feststellen zu knnen,welche dieser Eigenschaften in das zu entwickelnde System integriert werden sollen. Essollen ebenfalls statische Komponenten identiziert werden, die fr die Entwicklung einesgenerischen Kartengenerators dynamisiert werden mssen. 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 Systemmglichst unabhngig von einem bestimmten Datenbanksystem zu entwickeln. Exempla-risch wird eine Schnittstelle fr Microsoft Access implementiert werden. Eine graphischeNutzer-Schnittstelle sollte zur Demonstration der Leistungsfhigkeit ebenfalls implemen-tiert werden, die Interaktionen und Darstellungsmglichkeiten moderner Bildschirmkartenuntersttzt. Ferner wre ein Kongurationsassistent wnschenswert, der die komfortableEingabe von Regeln fr die Konguration des Kartengenerators erlaubt.In Kapitel 2 sind Grundlagen zum Kontext der Arbeit errtert. Nach einem histori-schen berblick ber Kartographie wird eine Einfhrung in deren Grundlagen gegeben,um ein Gefhl fr 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 Identizierung von Basisstrukturen die-nen. Grundlagen fr die Entwicklung des Systems werden in Kapitel 3 gegeben. Hierwerden Datenbanken und die Programmierumgebung .NET vorgestellt. Dadurch sollenTechniken vermittelt werden, die fr die Modellierung und Implementierung des Systemsnotwendig sind. Die Identizierung 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 Interaktionsmg-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 fr Visualisierungskonventionen imVordergrund. Im Verlauf des gesamten Kapitels kristallisiert sich dabei die Modellierungdes zu entwickelnden Systems heraus. Kapitel 5 dient zur Denition der Regelsprache, diewiederum zur Konguration des Systems dient. Die Struktur und Funktionalitt, des inKapitel 4 modellierten Systems, wird in Kapitel 6 dargestellt. Dabei wird detailliert aufden Kartengenerator, die Nutzer-Schnittstelle und den Kongurationsassistenten einge-gangen. Kapitel 7 erlutert 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 mgliche Weiterentwicklungen.Kapitel 2Grundlagen aus der Geographie2.1 KartographieEin Fachgebiet, dass sich beschftigt 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 Mastab und Informationsgehalt bzw.Informationsart.2.1.1 HistorieSeit Menschengedenken versprten Menschen den Drang, ihre Umgebung kartographischzu erfassen, um Entdecktes weitergeben zu knnen und um es ggf. wieder zu nden. Kar-ten machten auf Gebirge aufmerksam, die evtl. unberquerbar waren, sie zeigten auf, wodie letzte Jagd erfolgreich verlaufen war und wo das Meer beginnt oder nach damaligerAnsicht die Welt aufhrt. 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, Hlzern undhnlichen anderen Hilfsmitteln wurden zur Orientierung im Gelnde Wege markiert. Sp-ter zur Mitte der Altsteinzeit hin wurden Gelndemodelle erstellt, die zur Vororientierungdienten. Gegen Ende der Altsteinzeit (vor 20.000 bis 10.000 Jahren) entwickelten sich erstegraphisch-stationre Karten an Felswnden. Sie bildeten das Gelnde erstmals mit graphi-schen Zeichen ab. Graphisch-transportable Karten kennt die Menschheit seit ca. 10.000Jahren.34 Kapitel 2. Grundlagen aus der GeographieDie lteste Karte in der uns bekannten Form der Landkarte bzw. Umgebungskarteist in Anatolien gefunden worden und stellt eine graphisch-stationre Karte dar [MB89].Diese ca. 250 cm groe Karte (Abbildung 2.1) bildet die Stadt atal Hyk in der jetzigenTrkei ab und wird datiert auf ca. 6.200 v. Chr.Abbildung 2.1: atal Hyk - original oben, nachgezeichnet untenMit 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 Jahrespter stellte Aristoteles (384* - 322 v. Chr.) die These auf, dass die Erde eine Kugel-form besitzen wrde. Ca. 100 Jahre spter 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 km2.1 Kartographie 5Abbildung 2.2: Nubische Goldminenkarteauf PapyrusAbbildung 2.3: BabylonischeWeltkarte auf Tontafelwar 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, Hhenmes-sungen und Projektion. Die wohl erste komplexere Karte mit einem Koordinatensystemstammt ursprnglich von dem griechischen Geographen, Astronomen und MathematikerClaudius Ptolemus (150 n. Chr.) (Abbildung 2.5). Zeichnungen von Karten dieser Epo-che haben den Untergang der jeweiligen Weltmacht nicht berlebt und wurden spter mitHilfe detaillierter schriftlicher Aufzeichnungen nachgezeichnet. Ptolemus' Karten weisenEinsse der rmischer Kartographen auf, die eher praktische als wissenschaftliche Kartenzeichneten. Straennetze, Wegekarten, Kstenverlufe, Grundstckskarten und Weltkar-ten zeichneten die Rmer zu jener Zeit (ca. 250 n. Chr.) anhand von Vermessungsergeb-Abbildung 2.4: Weltkarte des Eratosthenes, rekonstruiertnach den Angaben Strabons im 2. Buch der Geographika6 Kapitel 2. Grundlagen aus der Geographienissen. Im Mittelalter wurde das Interesse an Karten bei den Arabern angeregt durch eingroes Handelsaufkommen mit fernen Lndern. Al Idrisi zeichnete ca. 1.200 n. Chr. seineWeltkarte auf einer zwei Meter groen Silberscheibe. Diese und weitere 70 Karten fassteer zu einem Atlas zusammen.Spter sollte die Kartographie einen groen Rckschritt erleiden, da die mglichst ex-akte Darstellung der Erde zugunsten einer religisen Weltanschauung eingetauscht wurde[Mit05]. Um 1275 stellte Richard von Haldingham eine Weltkarte (Mappa Mundi) herbasierend auf dem damaligen geographischen Wissen ber die Erde beeinusst durch dieKirche. Im Zentrum der Karte bendet sich Jerusalem, das fr Christen den damaligenMittelpunkt der Welt darstellte. Durch den groen Einuss der Kirche hielt sich dieseAnsicht weit bis ins 16. Jahrhundert, da Karten hauptschlich von Mnchen gezeichnetwurden. Mit der Erndung des Kupferstichs (ein Druckverfahren) wurden Unikatkartenimmer seltener.Begelt durch die immer strker 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 (fr die Kriegsfhrung) und auf deranderen Seite mglichst viel von der gesamten Welt zeigen (fr die Kolonialisierung). Dar-unter war auch die Weltkarte des Piri Reis aus dem Jahre 1513. Er war ein Admiral derOsmanischen Seeotte 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 Kstenkarten. Man entfernte sich mit der Zeit auch von den Fehlern Ptolemus'Abbildung 2.5: Hier 5. Europakarte des Ptolemus, gezeichnetim Jahr 1541 in Wien durch Martin Waldseemller2.1 Kartographie 7und ersetzte bislang herbeifantasierte Ausfllungen 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 Shnen. Er entwickeltezu seiner Zeit eine Kartenprojektion der Erde, die noch heute unser Weltkartenbild prgt[BK01].Mit Jacques und Csar Cassini, welche 1750 bis 1793 die groe Triangulation vonFrankreich und die darauf begrndete groe topographische Karte vollendeten, beganndie Zeit der genauen topographischen Aufnahmen und der kritischen Bearbeitung vonKarten. Dem Beispiel der Franzosen folgten nun viele Lnder Europas und kartographier-ten den Kontinent. Seit 1972 sind photograsche Abbildungen der Erdtopologie in denVordergrund gerckt 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 zurck, und immer fter treten so genannte Geoinformationssysteme (GIS) in denVordergrund.2.1.2 KartenUnsere wichtigste Orientierungshilfe nach der Sonne ist die Karte [Lin98]Nachdem im historischen Abriss der Kartographie deutlich geworden ist, wie wichtigKarten fr die Menschheit waren und auch heute noch sind, werden im folgenden Kar-ten klassiziert. Des weiteren wird verdeutlicht werden, welche Eigenschaften einer Karteexistieren und wie wichtig sie sind, wenn es um ihre Darstellung geht. Im spteren 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 Verstndlichkeit fr den Nutzer. DerNutzer muss in die Lage versetzt werden, Symbole und Zeichen in der Karte auf die Rea-litt zu beziehen. Anforderungen an eine gute Karte sind geometrische Richtigkeit undGenauigkeit, relative Vollstndigkeit, Zweckmigkeit (Topographie), Klarheit, Verstnd-lichkeit, Lesbarkeit und sthetik.1 Karten haben einige allgemeine Eigenschaften, anhandderer sie gruppiert werden knnen. Hierzu zhlen die Art der Karte, ihr Mastab und ihreProjektion.KartenartMan unterscheidet bei Karten zwei Gruppen. Diese sind topographische und thematischeKarten, die im folgenden nher erlutert werden. Eine exakte Unterscheidung zwischentopographischen- und thematischen Karten ist jedoch nicht mglich, da auch die Topo-graphie einer Karte ein Thema darstellt.1Soweit nicht separat angegeben, sind Ausfhrungen im folgenden Unterkapitel zum grten Teilentnommen aus [HG94] [Den99] [Imh72].8 Kapitel 2. Grundlagen aus der GeographieTopographische Karten Topographie ist ein Teilgebiet der Kartographie und Geo-dsie und befasst sich mit der Vermessung, Darstellung und Beschreibung von Gelnde,Orten und Landschaften. Das Institut fr Angewandte Geodsie deniert 1973 Topogra-phische Karten als jeneKarten in denen Situtation, Gewsser, Gelndeform, Bodenbewachsung undeine Reihe sonstiger zur allgemeinen Orientierung notwendiger oder ausge-zeichneter Erscheinungen den Hauptgegenstand bilden und durch Kartenbe-schriftung eingehend erlutert 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 deniert alsJede 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 fr Thematische Karten sind Straenkarten, 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 DenitionKartengrund). Erscheinungen und Sachverhalte werden explizit eingezeichnet (geologischeKarten) oder besonders hervorgehoben wie bspw. das Schienennetz in den Netzplnen derdeutschen Bundesbahn. Thematische Karten vermgen strker 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 undallgemeingltige 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.MastabKarten knnen auch nach ihrem Mastab gruppiert werden: Karten mit kleinem Mastabkleiner als 1:300000 Karten mit mittlerem Mastab1:10000 - 1:300000 Karten mit groem Mastabgrer als 1:100002.1 Kartographie 9Als Kartenmastab (Mk) gilt das lineare Verkleinerungs- oder Verjngungsverhltnisder Karte gegenber der Natur. Diese Verkleinerung wird beschrieben durch das Verhltniszwischen Kartenstrecke und Naturstrecke, wobei im Zhler die Lngeneinheit 1 verwendetwird (mk = Mastabszahl) :Mk = 1 : mkDer Mastab bestimmt den Grad der Generalisierung auf der Karte. Mit sinkenderMastabszahl sinkt auch die Detaillierung der geometrischen Darstellung von Realwelt-objekten. Je nach Thema resultiert ein Detaillierungsgrad, der wiederum den Mastabder Karte bestimmt.KartenprojektionEine weitere wichtige Eigenschaft von Karten nach der sie auch gruppiert werden knnen,ist die Kartenprojektion, deren Grundlagen im folgenden beschrieben werden.Die Kartenprojektion ist der Versuch einer zweidimensionalen Abbildung der dreidi-mensionalen Erde. Mit dieser Problematik beschftigen sich Mathematiker und Geogra-phen seit der Erkenntnis, dass die Erde keine Scheibe ist. Um nun die Oberche einerKugel (vereinfachte Darstellung der Erde - Abbildung 2.6) auf einer zwei dimensionalenFlche abzubilden, muss diese projiziert werden. Die Erde ist aber auch keine Kugel, son-dern ein Geoid (Abbildung 2.7). Zur Vereinfachung der mathematischen Berechnungenam Erdkrper benutzt man ein sogenanntes Rotationsellipsoid, das annhernd die Formdes Welt-Geoids aufweist.Abbildung 2.6: Erdkugel Abbildung 2.7: Geoid,15000fach berhht gezeichnetKartenprojektionen basieren auf geographischen Koordinatensystemen, die zur Positi-onsangabe auf dem Erdkrper dienen. Diese Koordinatensysteme bestehen aus der soge-nannten geographischen Breite, Lnge und Hhe, die deniert werden durch die quato-rialebene und einer knstlich festgelegten Nord-Sd-Linie, dem Nullmeridian (Abbildung2.9). Eine Gerade, die man sich durch den Nord- und Sdpol denkt, bildet die Erdachse10 Kapitel 2. Grundlagen aus der Geographieum die sich die Erde dreht. Die quatorialebene liegt senkrecht zu dieser Achse in derMitte von Nord- und Sdpol. Sie deniert den Nullpunkt der geographischen Breiten,von der die Entfernung in Richtung Nord- und Sdpol durch das Winkelma angegebenwird. In Nordrichtung wird sie dadurch mit positiven Gradwerten bis 90 deniert undin Sdrichtung durch negative Gradwerte bis -90. Bei geographischen Lngen handelt essich um Lngenkreise, die durch den Nordpol und durch den Sdpol gehen (siehe Abb.2.8). Da es fr Lngen keine Orientierungs- bzw. Denitionshilfe wie den quator fr dieBreiten gibt, wurde dieser bis zum Jahre 1884 unterschiedlich deniert, bis man sich dannauf den aktuellen Nullmeridian durch Greenwich in London einigte. Die Lnge 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 Lnge dar, die gleichzeitig (mit einigen von den betroenen Lndern be-stimmten Abweichungen) die Datumsgrenze bildet. Das Gau-Krger-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 Lngengraden.Abbildung 2.8:geographisches Breiten- u. LngennetzAbbildung 2.9:geographische Breite, Lnge u. HheDie Projektion kann man sich vorstellen als eine Abbildung der Erde die dadurch ent-steht, dass eine Lichtquelle die Erde von innen ausleuchtet oder von auen durchleuchtet.Gewsser 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 auer-halb der Erde parallele Lichtstrahlen wirft, die Erde durchleuchtet und auf eine planeEbene abgebildet. Bei der stereographischen Projektion hingegen sitzt die Lichtquelle ander gegenberliegenden Kugelwand der interessierenden Seite. Gnomonische Projektionenerhlt man dadurch, dass die Lichtquelle im Zentrum der Kugel sitzt und in alle Richtun-gen ausleuchtet. Orthographische Azimutalprojektionen knnen lediglich eine Hemisphredarstellen und verzerren die Realitt besonders zu den Rndern hin. Diese Darstellung2.1 Kartographie 11wird hauptschlich 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 berhrt der Zylin-der den quator. Wenn die beiden Pole durch den Zylinder berhrt werden, handelt essich um eine transversale Zylinderprojektion. Die letzte, weniger gebruchliche Art ist dieschiefachsige Zylinderprojektion.Bei der Kegelprojektion ist der Krper, auf den abgebildet wird, ein Kegel. DerKegel berhrt die Erdkugel in einem Kreis oder schneidet sie in zwei Kreisen. Der Berh-rungskreis und die Form des Kegels entscheiden ber das Aussehen der Projektion.Streckenlngen, Winkel zwischen zwei Linien, Flchenform und -gre sind die Ei-genschaften, die durch verschiedene Projektionen in Mitleidenschaft gezogen werden. Jenach Verwendungszweck und Mastab der Darstellung ist man gezwungen, die jeweilsbeste Projektion zu whlen, da es Projektionen gibt, die zwischen diesen Verflschungenvermitteln aber nicht alle gleichzeitig beheben knnen. Es werden folgende Projektions-verzerrungen unterschieden, die desto grer die abzubildende Flche ist, umso extremerausfallen: quidistantzverzerrungStrecken auf der Karte entsprechen nicht den realen Strecken auf der Erde; keineLngentreue. KonformittsverzerrungWinkel an den Lngengraden auf der Karte geben nicht die gleichen Winkel auf derErde an; keine Winkeltreue. quivalentzverzerrungFlchen werden in ihrer Gre nicht Mastabsgetreu dargestellt; keine Flchentreue.Bei der bekanntesten Projektion der Weltkarte handelt es sich um die Mercatorprojek-tion aus dem Jahre 1569. Sie ist eine quatoriale Zylinderprojektion, die als Berhrungs-kreis den quator hat. Dadurch wird der quator lngentreu dargestellt. In sdlicher undAbbildung 2.10: Planar- bzw. Azimutalprojektionen12 Kapitel 2. Grundlagen aus der Geographienrdlicher Richtung werden die Verflschungen der Lnge immer ausgeprgter. Dadurchist die Mercatorprojektion auch nicht chentreu, die Sowjetunion wird beispielsweise mitihren ca. 22, 4Miokm2 wesentlich grer dargestellt wie der gesamte Kontinent Afrika mitseinen ca. 30Miokm2 (siehe Abbildung 2.11). Dies fhrte auch zu heftigen Diskussionenbei vielen nachfolgenden Kartographen, diese Projektion wrde ein falsches Weltbild ver-mitteln. Jedoch ist sie winkeltreu, was zur damaligen Zeit der Seefahrer eine sehr wichtigeEigenschaft fr Karten war. Eine chentreue Projektion einer Weltkarte bieten uns Gallund Peters. Sie entwickelten unabhngig 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 - Flchenuntreue Darstellung Sowjetunion/AfrikaNachdem 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 nachtrgliche nderung ist nicht erwnscht, oftmals auch nicht mglich [Kri99].Dies stellt eine statische Entwickler- und Nutzer-Beziehung dar, die linear vom Entwick-ler zum Nutzer geht, ohne dass der Nutzer eine Mglichkeit der Manipulation htte.In der heutigen Kartographie steht die Trennung von Haltung und Visualisierunggeographischer Informationen im Vordergrund. Diese Tatsache fhrt immer mehr zur Ver-schmelzung der Kartographie mit der Informatik und somit u.a. zu dem neuen Werkzeugder Geoinformationssysteme.2.2 Geoinformationssysteme 132.2 GeoinformationssystemeEin 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 prsentiert 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 Realitt. 2Abbildung 2.12: Abbildung der realen Welt [Str05]Diese Arbeit konzentriert sich im folgenden auf Grund der Aufgabenstellung haupt-schlich auf die alphanumerische und graphische Prsentation von Geodaten, die in obigerDenition 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 einschlielich 2Dbetrachtet werden.2Soweit nicht explizit angegeben sind die Ausfhrungen aus dem Skript zur Vorlesung Einfhrung indie Geoinformatik von Prof. Dr. Ulrich Streit an der Universitt Mnster ([Str05]) entnommen.14 Kapitel 2. Grundlagen aus der Geographie2.2.1 GeoobjekteEin Geoobjekt (feature) ist das abstrakte Modell eines realen rumlichen Ob-jektes, das hinsichtlich seiner rumlichen Lage (Geometrie), seiner Lagebezie-hungen zu anderen Geoobjekten (Topologie), seiner fachlich relevanten Eigen-schaften (Thematik) und seiner zeitlichen Vernderungen (Dynamik) gegen-ber anderen Geoobjekten unterschieden werden kann. [Str05]Ein solches Geoobjekt wird beschrieben durch seinen Objektidentikator, seineGeometrie /Topologie, seine Thematik und durch seine Dynamik und ist rum-lich eindeutig abgrenzbar. Der Objektidentikator ist ein eindeutiger Schlssel, mit demein direkter Zugri auf das Objekt gewhrleistet 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 knnen, ist ein rumliches Bezugssystem ntig. Man dierenziert dabeiVektordarstellung und Rasterdarstellung. Die Topologie beschreibt rumliche Beziehun-gen zwischen Geoobjekten, wie z.B. Nachbarschaft und berschneidungen. Attribute, diemit dem Geoobjekt verknpft werden (z.B. bei Stadt-Objekten Name, Einwohnerzahl,...) und einem fachlichen Charakter angehren, machen die Thematik aus. Dadurch wirdermglicht 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 Mastab und auchder Raumausschnitt mssen bei allen Schichten gleich sein, damit sie bereinanderdeckungsgleich dargestellt werden knnen.Abbildung 2.13: GIS-Komponenten nach U. Streit2.2 Geoinformationssysteme 152. 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 Vernderungen am Objekt, die ihre Geometrie, Topologie sowie Thematikbetreen knnen, machen die Dynamik aus. Beispielsweise in der Geologie interessierenZeitabschnitte von Tausenden von Jahren, in denen sich auch die Geometrie von Objektenverndern (Stichwort: Kontinentalverschiebung).Modellierung von GeoobjektenWie in der Denition des Begries Geoobjekt beschrieben, werden in der Geoinformatiknicht die realen Raumobjekte selbst betrachtet, sondern ihre gedanklichen Abbilder, alsoModelle der Realitt. Modelle der Realitt werden durch Abstraktion erhalten, d.h. durchVereinfachung der Realitt. Dabei werden nur diejenigen Strukturen, Funktionen und Be-ziehungen betrachtet, die fr die betrachtete Anwendung unbedingt erforderlich sind. Daswichtigste Abstraktionsmittel ist das Zusammenfassen hnlicher Objekte (Klassikation)zu einem bergeordneten Typ (Klasse) unter Vernachlssigung spezieller Eigenschaften(Generalisierung).In GIS werden dabei die Begrie Typ und Klasse hug synonym verwendet. In derInformatik wird mit Klasse die Denition von Attributen und Operationen fr eine Men-ge gleichartiger Objekte bezeichnet, die durch diese Klasse erzeugt werden knnen. Dasheit, dass die Klasse als eine Art Bauplan fr Objekte anzusehen ist. Der Typ-Begri je-doch wird in der Informatik meist allgemeiner verwendet (z.B. Datentypen, Systemtypen).Geoobjekte knnen in verschiedenen Dimensionen modelliert werden. Die Dimensi-on eines Geoobjektes beschreibt die Anzahl voneinander unabhngiger Richtungen desRaumes, die zur geometrischen Modellierung des Raumobjektes verwendet werden. Da-bei stellen Punkte 0-Dimensionale Geoobjekte dar, da sie weder eine Lnge noch eineFlche aufweisen. 1-Dimensionale Geoobjekte werden Linien genannt, die eine endlicheLnge jedoch auch keine Flche aufweisen. 2-Dimensionale Geoobjekte werden bezeich-net als Flchen, 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 Stdte in kleineren Mastben model-liert als Punkte. Strecken, die diese Punkte verbinden, werden als Linien modelliert (1-Dimensionale Geoobjekte) und Bundeslnder als Flchen (2-Dimensionale Geoobjekte).16 Kapitel 2. Grundlagen aus der Geographie2.2.2 GeodatenGeodaten sind formale Beschreibungen der Eigenschaften von Geoobjekten inForm von Ziern und Zeichen zur computergerechten Verarbeitung.[Str05]Geodaten werden interessen- bzw. anwendungsspezisch modelliert und durch Aus-wahl der dazu ntigen Eigenschaften abstrahiert. Objekte knnen dann weiter durch Ge-neralisierung (Weglassen spezieller Eigenschaften) zu Klassen zusammengefasst werden.Beispielsweise kann man Waldchen und Weidechen zusammenfassen zur Klasse derGrnchen. 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 [Gr95], denn das zugrundeliegende Datenmodell be-stimmt Detaillierungsgrad und Ausschnitt der Realitt, wonach Daten erfasst werden. Eskann auch vorkommen, dass aus vorhandenen Daten eines sehr detaillierten Modells Dar-stellungen extrahiert werden mssen, 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 Darstellungsmglichkeit von enormer Wichtigkeit. Bei digitalen Kar-ten, wie sie in GIS dargestellt werden knnen, dient Generalisierung hauptschlich 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 abhngig von verschiedenen Faktoren, wie Frage-stellung, Messtechniken, Analysemethoden, Arbeitsaufwand etc. auf der einen Seite undrumliche Dimension, rumliche Ausung und rumliche Dynamik auf der anderen Seite.Bei der rumlichen Ausung besteht mit dem Kartographischen Mastab (aus demKapitel Grundlagen - Kartographie) eine enge Beziehung. Auch hier ist je nach Fachbe-reich ein bestimmter Mastab zu whlen, wonach sich bei der Modellierung der Detail-lierungsgrad der geographischen und sachlichen Informationen richtet. Desto detaillierterdie Informationen sind, umso grer kann der Mastab gewhlt werden.2.2.3 VisualisierungVisualisierung (im Sinne der Informatik) ist die Transformation von Datenin ein sichtbares Bild zur Untersttzung der Exploration (Erkundung), Kogni-tion (Erkennen) und Explanation (Erklrung) von Strukturen und Prozessen.[Str05]Das menschliche Auge ist mit seinen 126 Millionen Rezeptoren (ca. 120 Mio. Stbchenfr Graustufen, 6,5 Mio. Zpfchen fr Farbsehen) eines der komplexesten Organe desMenschen. Die visuelle Wahrnehmung des Menschen ist geprgt durch Erwartungen undErfahrungen. Wenn das Gesehene nicht den Erwartungen bzw. Erfahrungen entspricht,wird seine Wahrnehmung oder Interpretation schwieriger und somit langsamer. Ziel der2.2 Geoinformationssysteme 17Visualisierung von Geoobjekten oder Visualisierung in GIS sollte es sein, die korrekteWahrnehmung rumlicher Sachverhalte durch die Bercksichtigung von Erwartungen desNutzers zu untersttzen.Bei Geodaten handelt es sich in der Regel um alphanumerische Informationen, derenErkundung und Erkennung wegen der Gre der Datenmenge ohne eine entsprechendeVisualisierung nicht zu bewltigen wre. Aus diesem Grund bedienen sich Geoinforma-tionssysteme der modernen Kartographie. Diese unterscheidet bei der Darstellung vonGeoobjekten vereinfachend die Klassen punkt-, linien- und chenfrmige Geoobjekte.Dabei entscheidet der Generalisierungsgrad, welche Geoobjekte Punkt-, Linien- oder Fl-chenfrmig dargestellt werden mssen. Eine Stadt hat in der Realitt eine chenhafteAusbreitung, doch kann diese, je nach Anwendung, auch punktfrmig dargestellt werden.Punktfrmig dargestellte Geoobjekte auf Karten sind in der Regel Vereinfachungen derRealitt. Fr die Gestaltung einer Karte gibt es sechs Variablen fr die BasiselementePunkt, Linie und Flche, wie sie in Abbildung 2.14 zu sehen sind.Abbildung 2.14: Variablen zur Kartengestalltung nach Bertin [Ber74]BildschirmkartenBei Bildschirmkarten ist Qualitt und Gre der Ausgabe gegenber dem herkmmlichenPapier wesentlich geringer. Sie unterliegen einigen Restriktionen, wie beispielsweise derBildschirmausung, dem Bildschirmformat oder dem hchstmglichen Kontrast, weshalbbei Ihrer Darstellung auf einiges geachtet werden muss, um die Lesbarkeit zu gewhrleis-ten. Hierzu zhlen minimale Strichbreite, minimaler Abstand zwischen Objekten, minima-le Lngen, Flchen und Breiten [RP96]. Bercksichtigt man die Pixelgren (ca. 0,25 mm)eines Bildschirms mit der Darstellungsmglichkeit einer analogen Karte (ca. 0,1 mm), sokann man sagen, dass Bildschirmkarten etwa im doppelten Mastab der jeweiligen analo-gen Karte gezeichnet werden mssen [Tp92]. Bei einer normalen Leseentfernung von ca.18 Kapitel 2. Grundlagen aus der Geographie30 cm vermag das menschliche Auge eine Ausung 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, Mastab, Legende,usw. kommen nun Kontroll- und Steuerungsmechanismen zum Einsatz, die auch nochmalPlatz in Anspruch nehmen, wodurch sich der Raum fr die Darstellung noch einmal verrin-gert [Rob93]. Jedoch knnen diese Nachteile teilweise durch Mglichkeiten der Interaktionund Techniken, wie u.a. kurzzeitiges Herauszoomen zur Orientierung, kompensiert wer-den. Bei der Bildschirmdarstellung sind zu beachten: Kleinmastbige und speziell generalisierte Darstellungenso ist trotz der kleineren Flche, ein hnlicher berblick mglich,wie durch eine gedruckte Karte [Mat97] Zoom- und Scrollmglichkeitenbei Darstellung gromastbiger Karten ntig, um gesamte Karteausschnittsweise anzeigen zu knnenRandangaben knnen auch ausgelagert werden, um den Platz besser auszunutzen, z.B.in ein separates Fenster, dass ber ein Menpunkt erreichbar ist.VektordarstellungEs sei ein kartesisches Koordinatensystem mit euklidischer Metrik vorausgesetzt. Im vor-angegangenen Kapitel wurde fr die Kartographie das Gau-Krger-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-Krger-Koordinatensystem durch seinen Rechts- und Hochwerteindeutig bestimmt: P (r, h). Je nach Thematik und Generalisierungsgrad der anzuzei-genden Geodaten knnen diese Punkte Stdte (bei Weltkarten) oder Raststtten (beiAutobahnkarten) reprsentieren. Zur exakten Beschreibung einer Linie, zur Darstellungeiner Landstrae im geometrischen Sinne wre eine mathematische Formel notwendig, dieeine Verbindung von zwei Punkten darstellt. Da diese in der Regel nicht geradlinig sind,wren solche Formeln recht aufwendig, weshalb man sich in der Geoinformatik einer Ap-proximation bedient. Eine solche Landstrae wird durch eine geordnete Folge von PunktenP1, P2, P3, P4, ... dargestellt, die mit Geraden verbunden werden. Durch die Ordnung inder Folge, ist es auch mglich, gerichtete Linien im topologischen Sinne darzustellen. Mitdieser Technik ist es dann auch einfacher, Flchen wie Bundeslnder 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.RasterdarstellungBei der Rasterdarstellung ist die Ausung, die zugrunde gelegt wird, sehr wichtig. Nachdieser richtet sich die Detaillierung der Daten. Da der Speicherbedarf fr Rasterdaten2.2 Geoinformationssysteme 19Abbildung 2.15: Vektordarstellung Abbildung 2.16: Rasterdarstellungenorm 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 zusammengehrige Objekte nicht sofort als solche er-kannt werden knnen. Durch Optimierungsverfahren ist es mglich den Speicherbedarf zuverkleinern; hier sei das Quadtree-Verfahren erwhnt, bei dem Pixel mit gleichen Wertenzusammengefasst werden. Pixel sind quadratische Gebilde einer bestimmten Gre, diein Zeilen und Spalten angeordnet sind, wie in Abbildung 2.16 dargestellt. Sie sind immergefllt mit nur einer Farbe und kennen keine Unterscheidung zwischen Punkt, Linie oderFlche.Vektor- vs. RasterdarstellungBei der Vektordarstellung von Geometriedaten ist eine sehr gute Modellierung einzelnerGeoobjekte mglich. Sie erlaubt dabei eine beliebig hohe Genauigkeit von Form und Lage,jedoch wchst der Erfassungsaufwand mit steigender Genauigkeit. Ein weiterer wesent-licher Vorteil ist, dass geringere Datenmengen entstehen. Fr chenhafte Verteilungen(Bsp.: Bodenarten von Ackerchen, die nicht durchgehend gleich sind) ist sie jedoch eherungeeignet.Rastermodelle hingegen sind fr solche chenhaften Verteilungen besser geeignet.Rastermodelle zur Darstellung haben den entscheidenden Nachteil, dass jeder Pixel einebestimmte (Teil-)Flche darstellt und somit bei hheren Ansprchen die Ausung wach-sen muss. Mit wachsender Ausung wchst der Speicherbedarf mit.Welches nun das geeignetere Modell zur Darstellung von Geodaten ist, ist abhngigvom Genauigkeitsanspruch des Anwenders bzw. der Anwendung. Bei hohen Ansprchen,wie bei Flurstcksbeschreibungen, 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 3Grundlagen aus der Informatik3.1 DatenbankenA 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 ezienten Bearbeitung von Anfragen zu gespeicherten Daten jeder Art, das Herz-stck eines jeden Geoinformationssystems. Der Begri der Datenbanken wird oft synonymfr Datenbanksysteme genutzt. 13.1.1 DatenbanksystemeDatenbanksysteme bestehen aus anwendungsunabhngiger Verwaltungssoftware (DBMS),die die Gesamtheit aller Programme zur Verwaltung verschiedener Datenbanken aus-macht, und aus anwendungsspezischen Datenbanken [Man99]. DBMS basieren auf ei-nem Datenmodell, mit der die Modellierung der realen Welt mglich wird. Eine solcheModellierung ist in beiden Ebenen des Datenbankentwurfs (konzeptioneller- und physi-scher Entwurf) ntig. Im konzeptuellen Entwurf gibt es u.a. das am hugsten genutzteEntity-Relationship-Modell (ER-Modell), das im Verlauf dieser Arbeit genutzt werdenwird. In der physischen Ebene knnen Netzwerkmodell und hierarchisches Datenmodellals Beispiele angefhrt werden. Relationales Datenmodell, objektorientiertes Datenmodellund deduktives Datenmodell zhlt 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.1Ausfhrungen in diesem Kapitel entstammen aus [Man99], [KE01] und [WD04] soweit nicht explizitetwas Anderes angegeben wird.203.1 Datenbanken 213.1.2 Entity-Relationship-ModellDas Entity-Relationship-Modell soll im folgenden vorgestellt werden, da es ein system-unabhngiges Modell fr den konzeptionellen Entwurf darstellt, und die fast automatischeberfhrung 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 (Gegenstnde) und Relationships (Beziehungen). WeitereStrukturen sind Rollen und Attribute. Entities sind physisch oder gedanklich exis-tierende und wohlunterscheidbare Dinge der zu modellierenden Welt. Gegenstnde mithnlichen oder gleichen Eigenschaften knnen 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 knnen betrachtet werden als Relationen im mathe-matischem Sinne. Dabei knnen 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 - hren). Entities sowie Relationships werden durchAttribute charakterisiert, die durch abgerundete Ksten dargestellt werden, in denen ihreBezeichnung stehen (siehe Abbildung 3.1 - MatrikelNr und Hugkeit). Die Identizie-rung eines bestimmten Entity innerhalb des Entitytyps erfolgt ber einen so genanntenSchlssel. Ein Schlssel ist eine minimale, identizierende Attributskombination. Es istblich ein einzelnes Attribut als Schlsselattribut knstlich zu erzeugen, wenn keine At-tributskombination dieser Forderung gengt. Das Schlsselattribut 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 Universittsverwaltungbeispielhaft dargestellt. Diese enthlt Studenten- und Vorlesungen-Entities und die Rela-tion hren mit den zugehrigen Attributen.Abbildung 3.1: Beispiel fr ER-ModellUm 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 (hauptschlich Attribu-te und Beziehungen) einem gemeinsamen Obertyp zugeordnet. Diese hnlichen Typenwerden als Untertypen bezeichnet. Um die Beziehung zwischen Ober- und Untertypverdeutlichen zu knnen und eine Verwechslung mit den bisher kennengelernten Bezie-22 Kapitel 3. Grundlagen aus der Informatikhungen 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 fr ER-ModellDie berfhrung eines solchen ER-Modells in ein relationales Datenbankschema kannfast automatisch erfolgen durch die Regeln:1. Fr jeden Entitytyp des ER-Modells wird eine Relation (Tabelle) erstellt. DieseRelation enthlt alle Attribute eines Entitytyps.2. Auch fr jeden Relationshiptyp wird eine Relation erstellt. Dabei enthlt die Relati-on als Attribute alle Primrschlssel der beteiligten Entitytypen und alle Attribute,die zu dem Relationshiptyp gehren.3.1.3 Relationales DatenmodellDas relationale Datenmodell basiert im wesentlichen auf Tabellen (Relationen). DieseTabellen knnen 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 fr Attribute knnenaus unterschiedlichen Wertebereichen (Domnen) sein. Die Werte einer Spalte drfen da-bei nur aus dem selben Wertebereich stammen und dabei atomar sein. D.h. sie drfen nuraus einfachen Wertebereichen stammen, die nicht zusammengesetzt, mengenwertig oderrelationenwertig sind. Eine Relation, die dieser Einschrnkung gengt, 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 Schemadenition, die zu Beginn jeder Datenbankmodellierung vorgenommen wird,werden Relationen und ihre Spalten mit Namen benannt.Stadt: {[ Name: string, Einwohnerzahl: integer, Lnge: oat, Breite: oat ]}Es kann ntig sein, dass unterschiedliche Objektklassen modelliert werden mssen, diein einer Beziehung zu einander stehen. Dabei werden drei Beziehungstypen 1:1, 1:n undm:n unterschieden. Gibt es beispielsweise zwei Relationen (Stadt und Oberbrgermeister),3.1 Datenbanken 23so kann folgende 1:1 Beziehung formuliert werden: Stadt x regiert von Oberbrgermeis-ter y, da eine Stadt hchstens von einem Oberbrgermeister regiert werden kann. Umeinzelne Objekte in Relationen eindeutig bestimmen zu knnen, werden ihnen knstlichSchlssel (Primrschlssel) zugewiesen. Mit Hilfe dieser Schlssel ist es mglich, die obengenannten Beziehungen zu verwirklichen. Dabei wird bei 1:1-Beziehungen der Primr-schlssel der einen Relation in der anderen Relation aufgenommen. An dieser Stelle wirder Fremdschlssel genannt.Stadt: {[ Name: string, Einwohnerzahl: integer,Lnge: oat, Breite: oat,regiert_von: integer ]}Bei 1:n-Beziehungen, wie sie gegeben sind bei Stadt x gehrt zu Land y, wird derFremdschlssel in die Relation mitaufgenommen, die die Stelligkeit n hat. Im vorange-gangenen Beispiel wre dies so, dass in die Relation Stadt der Fremdschlssel land_idaufgenommen werden wrde. m:n-Beziehungen bedrfen einer weiteren eigenen Relation,damit keine redundanten Daten gehalten werden mssen. Sie vereinen die Primrschlsselbeider Relationen. Ein Beispiel fr diesen Beziehungstyp wre Partei x regiert Bundeslandy, wenn bei koalitionsregierten Bundeslndern die Speicherung der einzelnen Parteien zu-gelassen wird.Um Informationen aus der Datenbank extrahieren zu knnen, existieren fr das re-lationale Datenmodell zwei formale Anfrage-Sprachen: die relationale Algebra (RA)und der Relationenkalkl. Diese basieren auf mengentheoretischen Operationen, wieVereinigung, Dierenz, Schnitt und Kreuzprodukt.3.1.4 Relationale AlgebraDie relationale Algebra bietet verschieden Operatoren an, die im Folgenden erlutertwerden sollen.SelektionUm eine bestimmte Menge von Tupeln aus einer Relation auswhlen zu knnen, bietetsie beispielsweise die Selektion:(< Relation >)Sie gibt die Tupel der Relation zurck, die das Selektionsprdikat erfllen. Ein Beispielfr die Selektion wre folgende Anfrage:Einwohnerzahl>100000(Stadt)Dadurch wrden alle Stdte mit mehr als 100000 Einwohnern zurckgegeben. Dazu wirdjedes Tupel der Relation Stadt einzeln auf das Prdikat Einwohnerzahl > 100000 geprft.Wenn das Tupel dieses erfllt wird es in eine Ergebnisrelation kopiert.24 Kapitel 3. Grundlagen aus der InformatikProjektionZum extrahieren von bestimmten Spalten (Attributen) aus der Relation wird die Projek-tion genutzt:(< Relation >)Wrde beispielsweise Name, Einwohnerzahl fr Attributliste eingesetzt und die Relationbei Stadt belassen, so wrde die Ergebnisrelation lediglich aus den beiden Spalten Nameund Einwohnerzahl bestehen.VereinigungZwei Relationen mit gleichem Schema (d.h. gleiche Attributnamen und Domnen) knnendurch die Vereinigung zu einer Relation zusammengefasst werden.< Relation >< Relation >Dabei kann auch eine Ergebnisrelation sein, die durch einen RA-Ausdruckdargestellt wird. Zum Beispiel:PersNr, Name(Angestellte) PersNr, Name(Arbeiter)MengendierenzSollen aus zwei Relationen R und S mit gleichem Schema, nur diejenigen Tupel aus Rextrahiert werden, die nicht in S enthalten sind, ist die Mengendierenz anzuwenden:R SKartesisches ProduktAuch das Kreuzprodukt zweier Relationen ist deniert:R SSie 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.UmbenennungWenn eine Relation mehrfach in einer Abfrage genutzt werden soll, bietet die RA denOperator zum Umbenennen der Relation:(< Relationsname alt >)3.1 Datenbanken 25Weitere OperationenMit 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 Relationenkalkl basierend, hat sich die struc-tured query language (SQL), zur Denition und Manipulation von Daten auf relationalenDatenbanken, durchgesetzt.3.1.5 SQLDiese Sprache zur Schemadenition 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 Verfgung gestellt.DatentypenRelationale Datenbanken stellen in der Regel drei fundamentale Datentypen als Attribut-Domnen zur Verfgung: Zahlen, Zeichenketten und einen Datumstyp. Bei Zeichenkettenwerden hauptschlich zwei Typen unterschieden: char(n) oder varchar(n). Dabei repr-sentiert n die maximale Anzahl der Zeichen, die gespeichert werden knnen. Bei char(n)werden Werte immer mit der festen Lnge n abgespeichert. Wird varchar(n) verwendet,so speichert die DBMS bis zu einer Maximallnge von n lediglich mit der genutzten Ln-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.26 Kapitel 3. Grundlagen aus der InformatikSchemadenitionDie Schemadenitionen einer Datenbank werden in dem sogenannten DataDictionary ge-speichert. Dieses enthlt Metadaten, die den Zustand der Datenbank beschreiben. Um dasSchema einer Datenbank zu denieren, das aus Tabellen- und deren Attributdenitionenbesteht, 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 sogenannteIntegrittsbedingung darstellt, die besagt, dass Tupel der Tabelle zwingend Werte fr dieseAttribute haben mssen. Die Angabe der Datentypen gehrt auch zur Integrittsbedin-gung dieser Tabellendenition, denn diese verlangt beispielsweise bei der MatrikelNr eineganze Zahl. Kein anderer Wert wrde hier von dem DBMS akzeptiert werden.SchemavernderungDie Schemadenition kann im nachhinein noch immer verndert werden. Hierfr exis-tiert in der SQL-Denition der Befehl ALTER TABLE. Mit seiner Hilfe ist es mglichTabellen Attribute hinzuzufgen durch ADD:ALTER TABLE StudentenADD (Initialen CHAR(2) );Attribute der Tabelle zu verndern ohne dieNOT NULL-Denition aus der ursprnglichDenition zu berhren:ALTER TABLE StudentenMODIFY (Name VARCHAR(20) );Attribute der Tabelle zu entfernen:ALTER TABLE StudentenDROP COLUMN GebDat;oder die ganze Tabelle zu entfernen:DROP TABLE Studenten ;3.1 Datenbanken 27DatenmanipulationDie Datenmanipulation lsst sich unterteilen in Einfgeoperationen, Anfrageoperationen,nderungsoperationen und Lschoperationen. Fr die Einfgeoperation steht der Be-fehl INSERT INTO zur Verfgung. Um ein Tupel in zuvor erstellte Tabelle einzufgen,wrde der Befehl folgendermaen genutzt werden:INSERT INTO StudentenVALUES (934752, 'Max Mustermann', 1975-03-13 00:00:00, 'MM' ) ;Fr 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 gewnschten 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 Schlsselwort AS und demneuen Tabellennamen eingefgt wird. Der optionale WHERE-Teil ist vergleichbar mitder Selektion aus der RA. Sie dient dazu, die Teilmenge der gewnschten Tupel zu spezi-zieren. Wenn dieser Teil weggelassen wird, gibt die SELECT-Anweisung alle Tupel derangegebenen Relationen zurck. Mit dem letzten optionalen Teil ist eine sortierte Rck-gabe der Tupel mglich. Dafr muss der Attributname, nachdem sortiert werden soll,und eines der Schlsselwrter ASC fr absteigende Sortierung und DESC fr ansteigendeSortierung angegeben werden.SELECT AttributlisteFROM Tabellenliste[WHERE Bedingung ][ORDER BY Attributname ASC | DESC]Im folgenden seien die Mglichkeiten von SQL beispielhaft erlutert. Mit folgender An-frage werden alle Deutschen Stdte sortiert, nach Ihrem Namen, angefordert.SELECT *FROM Stadt, LandWHERE Land.Name = ` deutschland` ANDStadt.gehoert_zu = Land.land_idORDER BY Stadt.name ASC28 Kapitel 3. Grundlagen aus der InformatikAuf diese Weise sind weitere Operatoren, wie sie in Abbildung 3.3 zu sehen sind, konstru-ierbar.Um bestehende Datenstze in den Tabellen ndern zu knnen steht die nderungs-operation UPDATE zur Verfgung. Die Syntax fr diese Operation kann wie folgendbeschrieben werden:UPDATE TabellennameSET Attributname = neuer Attributwert[WHERE Bedingung ]Fr alle Tupel wird der Attributwert des Attributs Attributname in der Tabelle mit demNamen Tabellenname ersetzt durch neuer Attributwert, wenn die Bedingung fr das Tupelerfllt ist.Lschoperationen knnen mit Hilfe des Befehls DELETE FROM ausgefhrt wer-den. Folgendes Beispiel lscht alle Stdte aus der Tabelle, die weniger als 10.000 Einwohnerhaben:DELETE FROM StadtWHERE Einwohnerzahl < 10000 ;SichtenUm Datenbanksysteme an spezielle Bedrfnisse unterschiedlicher Benutzergruppen undAnwendungen anpassen zu knnen, gibt es das Konzept der Sichten (engl. views). WerdenDatenbanken als Mengen von Daten gesehen, so knnen Sichten als eine fr eine bestimm-te Benutzergruppe oder Anwendung interessante Teilmengendenition bezeichnet werden.Das besondere an Sichten ist, dass sie virtuelle Teilmengen (Relationen) bieten. Virtuellsoll dabei verdeutlichen, dass keine neuen Tabellen angelegt werden, sondern bei jedemZugri die, durch diese Sicht denierte, Relation aus vorhandenen Relationen neu berech-net wird. Beispielsweise knnte das letzte SQL-Anfrage-Beispiel als Sicht deniert werden.Dies ist auch in SQL mglich durch CREATE VIEW ... AS ...wie im folgenden zu sehen:CREATE VIEW deutscheStaedte ASSELECT *FROM Stadt, LandWHERE Land.Name = ` deutschland` ANDStadt.gehoert_zu = Land.land_idORDER BY Stadt.name ASC;3.2 .NET 293.2 .NETEine weitere Vorgabe fr diese Diplomarbeit war die Programmiersprache Visual Basic.Um aktuelle Entwicklungen der Softwaretechnologie in den Entwurf und in die Imple-mentierung einieen lassen zu knnen, wurde die aktuelle Version VisualBasic.NETeingesetzt.Die .NET-Plattform gliedert sich in vier voneinander unabhngige Bereiche: Entwicklungswerkzeuge und -BibliothekenHierzu zhlen 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 hauptschlich um kommerzielle Webservices, die Entwicklernzur Verfgung gestellt werden und online genutzt werden knnen. spezielle ServerDiese Server untersttzen .NET-Funktionalitten und APIs. Zu dieser Gruppe vonServern zhlen u.a. SQL-Server und Exchange-Server. HardwareMit Hardware sind keine Desktop-PC gemeint, vielmehr handelt es sich dabei umGerte, die ausschlielich .NET untersttzen, wie einige Spielekonsolen, Handys undPDAs.Das Ziel von .NET ist es, Software plattformunabhngig als reinen Service bereit stel-len zu knnen. D.h. Anwender sollen on demand, wenn sie eine bestimmte Anwendungbentigen, darauf zugreifen knnen. Wichtigste Komponente ist das oben angesprocheneCLR. Es ist vergleichbar mit der Java Virtual Machine und dient zur internen Erstellungvon Objekten, deren Sicherheitschecks, Speichermanagement, Ausfhrung und Garbage-collection (Objekte deren Instanzen nicht mehr bentigt werden, werden aufgesammeltund entsorgt). Wie weiter oben erwhnt, ist es in .NET mglich, in verschiedenen Spra-chen zu programmieren. Da alle diese Sprachen auf dem CLR operieren, ist es mglich,programmiersprachenbergreifend zu arbeiten. D.h. man knnte in VisualBasic.NET aufBibliotheken und APIs zurckgreifen und diese beerben, auch wenn sie ursprnglich inC#, C++ oder in einer anderen von .NET untersttzen Programmiersprache erstellt wor-den sind. Der umgekehrte Weg ist analog auch mglich.3.2.1 Visual Basic .NETVisual Basic (VB) war die erste Programmiersprache, die es ermglichte, 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 frdiese Anwendung reprsentiert. Der Programmierer zeichnet die Benutzerschnittstelleder Anwendung, indem er Eingabefelder, Tasten und hnliches aus einer Toolbox zieht30 Kapitel 3. Grundlagen aus der Informatikund auf der Form platziert. Der Quellcode zu dieser gezeichneten Oberche wird auto-matisch durch den VB-Editor erstellt, wodurch dem Programmierer viel Zeit erspart wird.Aus dieser Funktionalitt heraus ist auch der Name Visual Basic entstanden.Die neue Version von Visual Basic Visual Basic .NET ermglicht das Programmie-ren mit aktuellen Softwaretechnologischen Konzepten wie u.a. Namespaces, Schnittstellen,Kapselung, Vererbung, Polymorphismus und Exception-Handling. Damit untersttzt esstrukturierte, komponentenbasierte und objektorientierte Programmierung. Ein VisualBasic .NET - Compiler erzeugt keinen spezischen Maschinencode sondern einen plattfor-munabhngigen Zwischencode, genauer einen Microsoft Intermediate Language (MSIL) -Code, der wiederum vom CLR bei jedem Aufruf erneut compiliert wird. Zum ausfhrenvon 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.NETZu diesen Bibliotheken gehrt auch ADO.NET2 mit vielen Klassen zum Einfgen, Ausle-sen, Manipulieren und Lschen von Daten auf unterschiedliche Weisen. Als ein wichtigerBestandteil der .NET-Plattform untersttzt ADO.NET viele Eigenschaften dieser Platt-form, wie beispielsweise Sprachunabhngigkeit, Objektorientierung und Garbagecollecti-on. ADO.NET bietet Klassen zur Verbindung mit einer Datenquelle, die bermittlungvon Anfragen und die Verarbeitung von Ergebnissen. Zu den untersttzten Datenquel-len zhlen neben verschiedenen Datenbanken auch XML-Dateien. Das Objektmodell vonADO.NET besteht aus verbundenen und unverbundenen Objekten, die im Verlaufdieses Kapitels nher betrachtet werden. Zu den Verbundenen zhlen 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 Verfgung, die es erlauben Daten im Speicher zu bearbeiten ohne mit derDatenbank verbunden zu sein (Abbildung 3.4).Um diese unverbundenen Objekte befllen zu knnen werden sie der ll -Methodeeines verbundenen Objektes bergeben, der sie dann befllt. 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 ermglichen, Daten-speicher eines bestimmten Typs anzusprechen. Das .NET-Framework bietet hierzu einenfr SQL-Server ab Version 7 an und eines fr Datenbanken, die ber OLE DB-Providerangebunden werden knnen. .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 Klassen2Inhalte dieses Kapitels entstammen hauptschlich aus [Sce02] und [JDF02]3.2 .NET 31instanziiert werden und verschiedene Verbindungsstrings genutzt werden mssen:' ffnen und Schlieen 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 Schlieen einer Verbindung mit dem SQL Client .NET-DatenproviderDim cnSql As NewSqlConnectioncnSql.ConnectionString = "Data Source=(local);" & _"Initial Catalog=Northwind;..."cnSql.Open()...cnSql.Close()Verbundene ObjekteZu diesen zhlen 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 knnen. Mit dem Command-Objekt ist es mglich, Anfragen andie Datenbank zu stellen, gespeicherte Prozeduren aufzurufen oder direkte Abfragen zubermitteln. Dazu ist es ntig, die Connection-Eigenschaft des Command-Objekts aufein zuvor instanziiertes Connection-Objekt zu setzen und die CommandText-Eigenschaftmit der gewnschten Abfrage in SQL (Bsp.: SELECT id, name FROM table1;) zu set-zen. Es ist auch mglich, nur den Tabellennamen in der CommandText-Eigenschaft an-Abbildung 3.4: Verbundene- und Unverbundene ADO-Objekte [Sce02]32 Kapitel 3. Grundlagen aus der Informatikzugeben, was dazu fhrt, dass die gesamte Tabelle als Ergebnis bergeben wird. DasDataReader-Objekt bietet eine ressourcenschonende und schnelle Mglichkeit Abfrage-ergebnisse zeilenweise abzuarbeiten. Es stellt einen sequenziellen und schreibgeschtztenDatenstrom dar. Um eine Reihe von nderungen an einer Datenbank zusammenfassendpropagieren zu knnen, existiert das Transaction-Objekt. Ist es erwnscht Abfragen zuformulieren, die auf einen bestimmten Datensatz prfen, kann man Parameter-Objektenutzen. Beispielsweise knnte eine Anfrage nach einer Person mit der Id 14, die im nor-malen Gebrauch als SELECT * FROM table1 WHERE id=14 formuliert wrde, nun formuliert werdenals SELECT * FROM table1 WHERE id=? . Dies fhrt bei komplizierteren Anfragen weg vom unber-sichtlichen Zusammensetzten. Das DataAdapter-Objekt fungiert mit den ll - und upda-te-Methoden als eine Brcke zwischen der Datenbank und den unverbundenen Objekten.Unverbundene ObjekteADO.NET bietet die unverbundenen Objekte, um Ergebnisse von Abfragen durch-suchen, sortieren oder ndern zu knnen. Zu diesen zhlen DataTable-, DataColumn-, Constraint-, DataRow-, DataSet-, DataRelation- und DataView-Objekt. Es ist mg-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 undknnen dort verarbeitet werden. Das DataColumn-Objekt ist in jeder DataTable mehrfachenthalten (fr jede Spalte einmal). Es enthlt keine Daten aus der DataTable, sondernInformationen ber die Struktur der Spalten (Metadaten). Ein DataTable kann auch eineReihe von Constraint-Objekten haben, in denen Integrittsregeln deniert werden. Eineinfaches Beispiel hierfr wre, dass nur eindeutige Inhalte in einer Spalte zugelassen wer-den. Um auf die Daten zugreifen zu knnen, bietet ADO.NET in einem DataTable-Objekteine Liste mit DataRow-Objekten. Diese besitzt eine Eigenschaft item, ber die es mglichist, auf einzelne Spalten der Datenzeile zuzugreifen. Da item die Standardeigenschaft vonDataRow ist, kann sie implizit genutzt werden:Dim rowAs DataRowrow= MyTable.Rows(0)Console.WriteLine(row(0))Console.WriteLine(row("CustomerID"))Console.WriteLine(row(MyTable.Columns("CustomerID")))Fr nderungen an Daten ist auch das DataRow-Objekt u.a. mit den MethodenBeginEdit, EndEdit und CancelEdit zustndig. Das DataSet-Objekt ist ein Containerfr verschiedene DataTable-Objekte, die zusammengehren. Um nicht den gesamten Da-tensatz bei nderungen zwischen Datenbank und Anwendung transferieren zu mssen,3.2 .NET 33bietet das DataSet-Objekt Methoden an, die nur nderungen herausltern und wei-ter geben. Mit dem DataRelations-Objekt werden Beziehungen zwischen verschiedenenDataTable-Objekten angegeben. Dadurch wird es mglich, ber die GetChilds-Methodedes DataRow-Objekts auf die Verknpften DataRows zuzugreifen. Das DataRelations-Objekt ermglicht es auch, Verknpfungen zwischen DataTable-Objekten anzugeben, dienderungen an dem bergeordneten DataTable weitergeben an die untergeordneten. Fer-ner ist es mglich, wenn ein DataRow im bergeordneten DataTable gelscht wird, diedamit verknpften DataRows in der untergeordneten DataTable mitzulschen. Mit demDataView-Objekt kann, analog zu den Sichten wie sie im Kapitel Datenbanken erlutertwurden, eine Sicht auf DataTable-Objekte deniert 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 grakfhigen Gerten wie Bildschirm,Drucker und hnlichem erlaubt, um menschenlesbare grasche Ausgaben zu erzeugen.Mit Hilfe der GDI+ ist es nicht erforderlich, fr jede Hardware separat Code zu erzeugen.Die Basisklasse von GDI+ ist Graphics, die Methoden und Eigenschaften zum Zeichnenund Befllen von Grakobjekten bietet. Zu den Zeichenmethoden gehren u.a. DrawEl-lipse, DrawImage, DrawLines und DrawPolygon. Um Grakobjekte mit diesen Methodenzeichnen zu knnen, werden Pens oder Brushes bentigt. Pens dienen zum Zeichnen vonLinien und Umrissen. Brushes hingegen denieren die Fllfarbe bzw. das Fllmuster frGrakobjekte. GDI+ bietet fnf verschiedene Brushes an (siehe Abbildung 3.5), von de-nen in dieser Diplomarbeit zwei genutzt werden: SolidBrush und TextureBrush.3SolidBrush kann genutzt werden, um Flchen, die u.a. mit DrawEllipse oder Draw-Polygon gezeichnet wurden, mit einer Farbe zu fllen. TextureBrush erlaubt es, ein Bild(Bitmap) als Brush zu nutzen und Grakobjekte damit zu fllen. Pens haben einige Ei-genschaften mehr als Brushes. Sie befhigen Linien zu zeichnen, die u.a. eine bestimmteBreite und Art haben. Ihrem Anfang und Ende kann unterschiedliches Aussehen verliehenwerden.Pens knnen auch aus einem Brush-Objekt erstellt werden. Somit knnen Linien ge-zeichnet werden, die die gleiche Farbe oder Textur haben wie das Brush-Objekt selber.' erstelle Brush aus einem BitmapDim myImg as Image = new Bitmap("roses.jpg")Dim myTxtrBrush as TextureBrush = new TextureBrush(myImg)' erstelle Pen aus BrushDim myPen as Pen = new Pen(myTxtrBrush, 20)3Inhalte dieses Kapitels entstammen aus [Cha03]34 Kapitel 3. Grundlagen aus der InformatikAbbildung 3.5: GDI+ Brushes [Cha03]Abbildung 3.6: GDI+ Linienarten [Cha03]3.2 .NET 35Die Art einer Linie, die durch ein Pen gezeichnet werden soll, wird in GDI+ durchu.a. folgende vier Eigenschaften deniert: 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 Verfgung. Mitden Werten Flat, Round und Triangle fr die Eigenschaft DashCap besteht die Mglich-keit, die Punkt- und Strichenden gerade, abgerundet oder spitz darzustellen. Der Anfangund das Ende einer Linie kann durch das voneinander unabhngige Setzen der Eigenschaf-ten StartCap und EndCap modiziert werden, fr die auch eine Reihe von Konstantenals Werte zur Verfgung stehen.Zum Zeichnen der in Kapitel 2.2.1 erluterten Geoobjekte, die reduziert werden knnenauf Punkt, Linie und Flche, bietet GDI+ die bereits erwhnten Methoden DrawEllipse,DrawImage, DrawLines und DrawPolygon. Die ersten beiden dienen zur Darstellung vonPunktobjekten und DrawLines zur Darstellung aller Geoobjekte, die linienhaft dargestelltwerden knnen. Zur Darstellung chenhafter Gebilde wie beispielsweise Landesgrenzenoder Grnchen kann DrawPolygon genutzt werden.Kapitel 4Entwurf - Methodologie - KonzeptIn diesem Kapitel wird eine kurze Problembeschreibung der Generierung von Bildschirm-karten auf herkmmliche Art formuliert, um das zu entwerfende System genauer spezi-zieren zu knnen. Es werden berlegungen erlutert, die von einer bisher spezischenKartengenerierung zu einer generischen Kartengenerierung fhren. Dazu wird ein Beispieleingefhrt, mit dessen Hilfe mgliche Teilprobleme identiziert werden. Bei Bedarf wirddas Beispiel sukzessiv ausgebaut und weiter ausdiskutiert. Die Diskussionen umfassenDarstellungen von Geoobjekten auf Bildschirmkarten und das Layout mit Mglichkeitender Interaktion fr diese Bildschirmkarten. Im weiteren Verlauf kristallisiert sich heraus,dass das Hauptproblem von einer spezischen zu einer generischen Kartengenerierung inder Zuordnung von Darstellungsform oder -art zu Geoobjekten liegt. Hierfr wird eineRegelsprache deniert und ein Konzept fr die Implementierung erarbeitet.4.1 Generische Visualisierung von 2D-GeoobjektenBei der herkmmlichen Generierung von Bildschirmkarten ist im Programmcode festge-legt, wie Geoobjekte auf Bildschirmkarten dargestellt werden sollen. Bevor ein Kartenge-nerator fr 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 Mglichkeit einige Darstel-lungsvariablen (Farbe, Muster, ...) zu ndern, jedoch sind diese Mglichkeiten begrenzt.Es ist also fr jede neue Anwendung ein neuer Kartengenerator zu programmieren, dessenFunktionsweise zuvor festgelegt werden muss. Bei nachtrglichen nderungen an der Da-tenstruktur der darzustellenden Geoobjekte oder ihrer Darstellungsform, ist ein Eingriin 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-litt, 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 und364.1 Generische Visualisierung von 2D-Geoobjekten 37ihrer 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 Flexibilitt verleiht. Dadurch entsteht ein universaler undsomit anwendungsunabhngiger Kartengenerator, der die Zusammenarbeit des Karten-autors mit dem Programmierer einer Anwendung berssig macht. Es stellt viel mehrein Werkzeug fr Kartenautoren dar, die in die Lage versetzt werden die Darstellung derGeoobjekte im nachhinein durch Parameter zu bestimmen. Sptere nderungswnschewie die Wahl der darzustellenden Geoobjekte oder die Art ihrer Darstellung sind durchein solches System komfortabel umzusetzen. Es ist dann lediglich ntig, die Zuordnung,die im folgenden Visualisierungs-Mapping genannt werden soll, zu berarbeiten.Als Name fr das neue System wurdeMapGENeric als passend empfunden, der sichaus den englischen Wrtern mapgenerator fr Kartengenerator und generic fr generischzusammensetzt. Der gemeinsame mittlere Teil des Namens kann auch alleine abkrzendfr Generator stehen, weshalb er in Grobuchstaben gehalten wird.MapGENeric gewhrleistet ber ein DBMS Zugri auf eine beliebige relationale Geo-datenbank. Zu den Geodaten in dieser Datenbank ist es mglich, ein Visualisierungs-Mapping zu denieren, anhand dessen das System dann eine interaktive Bildschirmkarteerstellt und ber ein GUI anzeigt. Beliebige Geodatenbank soll ausdrcken, dass das Sche-ma der zu visualisierenden Datenbank beliebig sein darf. Das DBMS ist mit MicrosoftTMAccess vorgegeben.Abbildung 4.1: MapGENericUm ein System wie MapGENeric zu entwerfen, muss zuerst festgelegt werden, welcheTypen von Geoobjekten existieren und welche das System darstellen knnen sollte. Dazuwird ein Beispiel eingefhrt, 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 mssen.Danach wird nach einer Mglichkeit gesucht, das dynamische Visualisierungs-Mapping zuverwirklichen.38 Kapitel 4. Entwurf - Methodologie - KonzeptIm Grundlagenteil ist gezeigt worden, dass Geoobjekte der Realitt durch Abstraktionmodelliert werden knnen als punkt-, linien- und chenfrmige Basisobjekte. Als solchewerden sie auch auf Bildschirmkarten dargestellt. Es ist auch zu bedenken, dass Geoobjek-te eines bestimmten Typs mit unterschiedlichen Basisobjekten dargestellt werden knnen.Beispielsweise knnen Stdte, die in der realen Welt eine chenhafte Ausbreitung haben,auf Bildschirmkarten entweder als chenfrmige oder aber als punktfrmige Abstrak-tionen dargestellt werden. Auch hier bietet es sich an, die Entscheidung, durch welchesBasisobjekt ein Geoobjekt reprsentiert werden soll, in das Visualisierungs-Mapping auf-zunehmen, so dass es einem spteren Nutzer von MapGENeric mglich ist, dies je nachNutzerkreis der Bildschirmkarte bzw. Art der vorliegenden Daten anzupassen.4.1.1 Beispiel - Touristik/UmweltIn diesem Beispiel wird von je einem Reprsentanten zweier Nutzerkreise ausgegangen,einem Touristen und einem Umweltbeauftragten. Der Tourist ist in der Regel interes-siert an verschiedenen Sehenswrdigkeiten und daran, wie diese erreicht werden knnen.Dabei knnen von verschiedenen Touristen unterschiedliche Geoobjekte als Sehenswr-digkeit aufgefasst werden. Fr den Einen knnen kulturelle Aspekte eine Rolle spielen,so dass er sich beispielsweise fr Museen, Opern und alte Gebude interessieren wird.Fr einen Anderen knnen Einkaufs- und sonstige Freizeitaktivitten interessant sein. DaTouristen in der jeweiligen Stadt fremd sind, knnten sie auch bernachtungsmglichkei-ten und Restaurants interessieren (siehe Abbildung 4.2). Der Umweltbeauftragte hingegenwird sich eher fr lokale Umweltbelastungen, wie spezielle Luftverschmutzungen (unterAnderen Feinstaubbelastung, CO2-Konzentration oder Pollenbelastung) und Wasserver-schmutzungen interessieren (siehe Abbildung 4.3). Um auch eventuelle Ursachen fr dieseUmweltbelastungen ausndig machen zu knnen, sind sicherlich vertiefende Informationenzu den Gebuden, Stadtteilen oder sogar fr einzelne Straen, wie Bewohnerzahl, Nut-zungsart (gewerblich oder privat), Verkehrsdichte, Verkehrsampeln und hnliches, vonhohem Interesse.Ein weiteres Szenario, in dem zwischen zwei unterschiedlichen Touristen-Kategoriendierenziert werden wrde, ist auch denkbar. Dies knnten Touristen mit Pkw und Tou-risten ohne Pkw sein, wodurch auf Basis der selben Daten fr Abbildung 4.2 zwei unter-schiedliche Karten gezeichnet werden mssten. Denn es ist notwendig fr Touristen mitPkw, Straen kenntlich zu machen, die ausschlielich fr Fugnger 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 kn-nen, mssen 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 fr beide Nutzerkreise sind erstrangig Straen, dann evtl. Flsseund andere Objekte wie Grnchen oder Gebude. Straen knnen mit zwei und mehrKoordinaten dargestellt werden, weshalb ihre Koordinaten in der Regel in einer solchen4.1 Generische Visualisierung von 2D-Geoobjekten 39Abbildung 4.2: Beispielkarte fr TouristenAbbildung 4.3: Beispielkarte fr Umweltbeauftragte40 Kapitel 4. Entwurf - Methodologie - KonzeptAbbildung 4.4: Beispielkarte II fr TouristenRelation (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 Straen, wie Anzahl der Fahrspuren, Hchstge-schwindigkeit oder das Vorhandensein von Ampeln wird fr den Touristen evtl. nicht in-teressant sein, aber der Umweltbeauftragte knnte mit diesen Informationen, den Einussauf die Umweltbelastung sehen. Es ist auch vorstellbar, dass sogar Straen in gewissenNutzerkreisen (Katasteramt) chenhaft modelliert sein mssen.Auch Flsse die dem Touristen vielleicht lediglich zur Orientierung dienen, knntenfr den Umweltbeauftragten weitere Interessante Informationen bedeuten. Dabei knnensie, 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: Koordinaten4.1 Generische Visualisierung von 2D-Geoobjekten 41id name anzahl_spuren max_speed ampel1 Welschnonnenstr. 4 50 ja2 Belderbergstr. 2 50 nein: : : : :Tabelle 4.2: Straenstrassen_id koord_id1 11 22 42 52 6: :Tabelle 4.3: StraenKoordinatenid name befahrungen min_tiefe max_tiefe1 Rhein 10000 4 92 Sieg 0 0,5 2: : : : :Tabelle 4.4: Fluesseuss_id koord_id1 141 151 19: :Tabelle 4.5: FlussKoordinaten42 Kapitel 4. Entwurf - Methodologie - Konzeptid name kapazitaet anzahl_linien breitengrad laengengrad1 Chlodwigplatz 500 3 7,10616 50,740442 Eifelstrae 400 1 7,10247 50,73996: : : : : :Tabelle 4.6: Straenbahnhaltestellenid haltestelle_id1 haltestelle_id2 max_speed1 1 2 502 2 3 70: : : :Tabelle 4.7: StraenbahnteilstreckeEine dritte linienhafte Darstellung bietet sich an bei Straenbahnnetzen, wie sie in denBeispielkarten durch eine feine blaue Linie mit gleichfarbigen Punkten darauf zu erkennenist. Die Punkte reprsentieren dabei Haltestellen der Straenbahn. Hier ist eine weitereMglichkeit der Modellierung naheliegend, wie anhand der Relationen in Tabelle 4.6 und4.7 zu sehen ist.Gebude wie z.B. Museen oder Hotels werden in der Regel als punktfrmige Geoob-jekte modelliert, jedoch knnen sie auch mit ihren Umrisskoordinaten erfasst vorliegen,wie in diesem Beispiel die Museen (Tabellen 4.8 und 4.9). Bei punktfrmiger Erfassungwerden sie oft, wie in Tabelle 4.10 zu sehen ist, mit ihren Geometrie- und Thematikdatengemeinsam modelliert. Umweltverschmutzungen werden punktuell erfasst aber chen-frmig gespeichert und dargestellt, da die erfassenden Sensoren einen gewissen Radiusabdecken.4.2 Visualisierung in MapGENericIm Grundlagen-Abschnitt 2.2.3 wurde festgestellt, dass zur Darstellung von geographi-schen Objekten auf zweidimensionalen Ebenen diese reduziert werden knnen auf dieBasisobjekte Punkt, Linie und Flche. Im oben genannten Beispiel wurden darzustel-lende bzw. darstellbare Geoobjekte identiziert. Bedacht werden sollte dabei, dass einGeoobjekt je nach Darstellungsziel, Mastab und Erfassung bzw. Modellierung in derDatenbank unterschiedlich gespeichert sein kann. Wie dem Beispiel zu entnehmen ist,knnen interessante Gebude in einem Stadtplan fr Touristen punktfrmig dargestelltwerden (Tabelle 4.10) oder aber mit ihren realen Umrisskoordinaten chenhaft (Tabelle4.8). Flchenhaft knnen sie nur dargestellt werden, wenn sie auch als solche erfasst inid name zeitalter ausstellung1 Rmisch-Germanisches Museum Antike Roma di Cesar2 Auto und Technik Museum 19./20. Jahrhundert : : : :Tabelle 4.8: Museen4.2 Visualisierung in MapGENeric 43museum_id koord_id1 151 161 171 18: :Tabelle 4.9: MuseumKoordinatenid name anzahl_zimmer preis laengengrad breitengrad1 Maritim 159 100 7,09948 50,739572 Luxor 248 199 7,10554 50,73870: : : : : :Tabelle 4.10: Hotelid art verschmutzungsgrad lufttemperatur luftfeuchtigkeit1 CO2-Konzentration 70 22C 52%2 Pollenbelastung 60 23C 50%: : : : :Tabelle 4.11: Umweltbelastungenumweltbelastung_id koord_id1 101 111 12: :Tabelle 4.12: Verschmutzungskoordinaten44 Kapitel 4. Entwurf - Methodologie - Konzeptder Datenbank vorliegen. Punktfrmig knnen sie in beiden Erfassungsformen dargestelltwerden, da fr die Darstellung von Punkten ein Koordinatenpaar ausreicht und bei mehre-ren, wie sie bei chenhafter Erfassung vorliegen wrden, eins von diesen gewhlt werdenkann. Anhand beispielhaft identizierter Geoobjekte wurde hier die Erfordernis fr einSystem deutlich, das alle Geoobjekte der drei Basisklassen darstellen knnen muss.4.2.1 Darstellung von GeoobjektenUm Geoobjekte aus der realen Welt auf Bildschirmkarten abbilden zu knnen, mssen die-se durch visuelle Objekte reprsentiert 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 fr die sptere Implemen-tierung festzustellen. Dabei wird die Notwendigkeit jeder Darstellungsvariable an allendrei Basisklassen fr Geoobjekte diskutiert. Da der Schwerpunkt dieser Arbeit nicht aufder Visualisierung an sich liegt, sondern vielmehr darin, Geodaten unabhngig von ih-rem Schema durch den selben Kartengenerator zu visualisieren, wird von einer intensivenDiskussion Abstand gehalten und nahe liegende Lsungen fr die Visualisierung gewhlt.Ferner soll am Ende jeder Diskussion eine Entscheidung fr das Konzept und somit frdie sptere Implementierung fallen.FarbeViele Geoobjekte assoziiert man mit einer bestimmten Farbe, weil diese auch in der Natureine hnliche Farbe aufweisen oder in der Kartographie standardmig so gezeichnet wer-den. Gewsser werden beispielsweise mit blauen Farbtnen dargestellt, Grnchen allerArt mit unterschiedlichen Grntnen und Gebirge in Brauntnen. Der gelugste Far-braum fr Bildschirmkarten ist der RGB-Farbraum, weil Monitore in der Regel technischmit dem selben Farbraum angesprochen werden. Der RGB-Farbraum wird deniert durchje einen Wert zwischen 0 und 255 fr die Farben rot, grn 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 mglicheinen Transparenzgrad, fr die auf diese Weise denierten Farben, festzulegen. Die Trans-parenz ermglicht es, sich evtl. verdeckende Objekte bis zu einem gewissen Grad trotzdemzu erkennen. Dies hat bei der Darstellung fr den Umweltbeauftragten aus dem Beispielden Vorteil, dass chenhaft darzustellende Luftverschmutzungen ber Geoobjekte gelegtwerden knnen 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 fr die Darstellung aller Geoobjekte mit allen dreiBasisklassen zur Verfgung gestellt werden.Alternative Farbrume existieren mit CMYK-, HSB- und YUV-Farbrumen, jedochknnen diese nicht als echte Alternativen fr Bildschirmkartendarstellungen angesehenwerden. Wie zuvor erwhnt werden Bildschirme aller Art (u.a. CRT Rhrenmonitore4.2 Visualisierung in MapGENeric 45 oder TFT Flssigkristallmonitore ) mit Werten fr rot, grn und blau angesteuert,weshalb eine komplizierte Umrechnung aus einem der oben genannten Farbrume ntigwre. Auerdem sind einige dieser alternativen Farbrume kleiner, d.h. es knnen wenigerFarben dargestellt werden.GreFr jede der Basisklassen hat die Gre eine andere Relevanz und sollte deswegen unter-schiedlich behandelt werden. Bei punktfrmigen Objekten, die durch Symbole reprsenta-tiv dargestellt werden (siehe beispielsweise Hotels, Museen und Restaurants in Abbildung4.2), ist eine Grenangabe in zwei Dimensionen denkbar und naheliegend. Diese sindHhe und Breite, die die Gre der darstellenden Symbole in Pixeln angeben. Fr linien-frmige Objekte, wie Straen und Flsse in den Beispielkarten, hingegen wird die Lngedurch ihre Anfangs- und Endpunkte deniert, wodurch nur die Linienbreite als ausschlag-gebende Darstellungsvariable zu betrachten ist. Bei chenfrmigen Geoobjekten wirddie Gre ausschlielich durch ihre Begrenzungspunkte deniert, weshalb eine separateAngabe der Gre vernachlssigt werden kann.Form - ShapeJe nach Generalisierungsgrad der Darstellung knnen beispielsweise Stdte, Straenkreu-zungen oder Bume reprsentiert werden durch punktfrmige Geoobjekte. In erster Linieist fr ein Punktobjekt die Form ausschlaggebend. Die Form wird in vielen Karten (bei-spielsweise Stadtplnen) genutzt, um allgemein bekannte Objekte wie Sehenswrdigkeitendurch Symbole darzustellen. Hierzu werden Symbole benutzt, die eine direkte Assoziati-on mit den Realweltobjekten erlauben, wie ein rotes Kreuz fr Krankenhuser oder eineminiaturisierte Kirche fr die reale Kirche. Bitmaps haben eine rechteckige Form, in dersie nur bedingt geeignet wren fr die gewnschte Darstellung. Jedoch knnen Bereicheeines Bitmaps transparent deniert 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 bentigt. Auf der Karte inAbbildung 4.2 fr den Touristen sind u.a. Sehenswrdigkeiten, bernachtungsmglich-keiten und Restaurants auf Anhieb erkennbar. So sollte die Darstellung solcher Objektedurch Bitmaps, wie sie auf dieser Karte zu sehen sind, ermglicht werden, da diese jedeerdenkliche Form darstellen knnen. Im Touristik/Umwelt-Beispiel sind wiederkehren-de punktfrmige Objekte wie Straenbahnhaltestellen dargestellt durch hellblaue Kreise.Diese Kreise wurden eingesetzt, weil durch Bitmaps dargestellte Symbole in dieser Anzahlberfrachtend wirken knnten. Aus diesem Grund sollten vordenierte Formen (beispiels-weise Ellipse, Drei- und Rechteck) existieren. Eine solche Manahme wrde ferner dieGeschwindigkeit beim Aufbau der Karte erhhen, da die zeitraubenden Zugrie auf dasSpeichermedium entfallen auf dem die jeweilige Bitmapdatei liegt. Eine weitere Mg-lichkeit fr die Darstellung der Form von punktfrmigen Geoobjekten wre eine eigene46 Kapitel 4. Entwurf - Methodologie - KonzeptSymbolsprache. Eine solche Sprache htte den Vorteil, dass sie erlauben wrde vektorori-entiert Formen zu denieren, die Beispielsweise beim Vergrern des Kartenausschnittsmitwachsen knnte. Da diese berlegungen den zeitlichen Rahmen dieser Arbeit sprengenwrden, wird auf eine weitere Diskussionen verzichtet.Die Form eines linienfrmigen Objektes kann unterschiedlich aufgefasst werden. Indieser Arbeit wird sie deniert als die Darstellung der Elementenden eines linienfrmigenObjektes, wobei diese Enden angelehnt an die vordenierten Formen fr die Darstellungpunktfrmiger Objekte, ach, abgerundet oder spitz sein sollten. Wie auch die Greeines chenfrmigen Objektes wird die Form durch seine Begrenzungspunkte deniertund bedarf deshalb keiner expliziten Betrachtung.Muster - TexturDurch die Entscheidung in Abschnitt Form-Shape Bitmaps fr die Darstellung von punt-frmigen Objekten einzusetzen, wird auch dieser Darstellungsvariable Genge getan. DennBitmaps knnen jede erdenkliche Form annehmen, wie zuvor zu lesen war. Ferner knnendiesen Formen durch Bildbearbeitungsprogramme (AdobeTM Photoshop, u.a.) beliebigeMuster aufgetragen werden, weshalb in dieser Arbeit eine separate Konzeption vernach-lssigt wird.Als Muster fr 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 fr die Darstellung einer Flche in Karten ist nach derForm das Muster. Erst durch diese Eigenschaft wird in den gngigen Karten klar, was frein Geoobjekt die sichtbare Flche darstellt. Fr den Umweltbeauftragten ist es wichtig,wie sich z.B. unterschiedliche Wlder (Laub- oder Nadelwlder) auf Luftverschmutzun-gen auswirken. Eine Darstellung, wie sie auf der Karte in Abbildung 4.3 zu sehen ist,wre durchaus wnschenswert. Da die Menge an darstellbaren chenhaften Geoobjektenunendlich erscheint, ist hier eine entsprechende Umsetzung, die dem gengt, notwendig.Eine solche Mglichkeit fr unterschiedliche Muster bieten ebenfalls Bitmaps, weshalb siein MapGENeric fr die Fllung chenhafter Geoobjekte bereitgestellt werden. Dadurchist eine vielfltige Darstellung von Flchen gewhrleistet.RichtungAuch der Eigenschaft Richtung wird bei der Darstellung von Punkten durch die Mglich-keit der Nutzung von Bitmaps genge getan. In der Beispielkarte fr Touristen (Abbildung4.3) sind beispielsweise Aussichtspunkte dargestellt durch das Symbol in Abbildung 4.6,die dem Nutzer eine schne Aussicht in stlicher Richtung verspricht. Das Symbol in Ab-bildung 4.5 hingegen wrde auf eine Aussicht im Westen hinweisen. Auf diese Weise sindfr punktfrmige Geoobjekte die Darstellung ihrer Richtung mglich.4.2 Visualisierung in MapGENeric 47Abbildung 4.5:Aussichtspunkt nach WestenAbbildung 4.6:Aussichtspunkt nach OstenUm beispielsweise die Flierichtung eines Flusses zu visualisieren oder Einbahnstraenkenntlich zu machen, ist bei Linien die Darstellung einer Richtung unerlsslich. Durch einePfeilspitze am Ende jeder Linie kann eine solche Darstellung erreicht werden, wie einigeEinbahnstraen in den Beispielkarten dargestellt sind. Zur Darstellung von Sackgassen,die unterteilt werden knnen in Sackgassen mit und ohne Wendemglichkeit, sind Kreiseund Rechtecke an den Linienenden vorstellbar. Die Ausbreitungsrichtung von chenhaf-ten Geoobjekten wird durch ihre Begrenzungspunkte deniert, somit ist eine expliziteBetrachtung nicht notwendig.HelligkeitBei Geoobjekten, die unterschiedliche Hhen bzw. Tiefen aufweisen, bedient man sichunterschiedlichen Helligkeitsstufen. Dabei werden hhere Teile eines Berges beispielsweiseheller dargestellt als tiefer liegende Teile. Diese Eigenschaft ist somit fr die Darstellungvon Hhenunterschieden unerlsslich. 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 fr Rot, Grn und Blau ist es mglich, verschie-dene Abstufungen von Farbtnen 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 unerwnschte berdeckungen. Andererseits kann es eingesetzt werden, um er-wnschte berdeckungen zu erzeugen, wie in obigen Beispielkarten die rot dargestelltenLinien. Sie reprsentieren Autobahnen, wie sie in vielen Lndern blich sind. Die Straen,die wei und gelb dargestellt sind, verlaufen unter der Autobahn.4.2.2 BildschirmkarteDer Aufbau einer analogen Karte ist abhngig 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 mglichst groen Nutzerkreisansprechen zu knnen, sollten selbsterklrende Elemente fr den Kartenaufbau und ihreInteraktionen zur Verfgung stehen. Nutzer von Bildschirmkarten erwarten eine Verbes-serung und Erweiterung der Informationen, die eine analoge Karte bietet. Deshalb drfendie bekannten Grundelemente einer Karte wie Titel, Mastabund Kartenausschnitt nichtfehlen, da dies die Verringerung von Informationen bedeuten wrde. Nicht alle Informa-tionen zu Geoobjekten knnen wie ihre Gestaltreprsentation auf einer Bildschirmkartedirekt dargestellt werden. Es werden in Geodatenbanken oft zustzliche Informationen zu48 Kapitel 4. Entwurf - Methodologie - KonzeptGeoobjekten abgelegt, die bei Bedarf angezeigt werden sollten. D.h. eine Interaktion mitdem Benutzer ist zwingend erforderlich, wodurch verschiedene Kontroll- und Steuerungs-mechanismen hinzukommen, die zustzlichen Platz auf dem Bildschirm beanspruchen.LayoutTitel 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 knnte fr die Beispielkarte in Abbildung 4.3 formuliertwerden als Umweltbelastungen der Stadt X in Abhngigkeit 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 mssen. In Bildschirmkarten ist es blich, denTitel in den Rahmen des Fensters zu integrieren, indem die Karte dargestellt bzw. das GUIausgefhrt 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.Mastab Analoge Karten werden in einem bestimmten Mastab gezeichnet, der dannauch auf der Karte als Randangabe verzeichnet ist. Der Mastab dient in erster Linie dazu,Gren von Geoobjekten und ihre Entfernungen zueinander in Relation zur realen Weltdeutlich zu machen. Dadurch erhlt der Nutzer einen berblick ber die Karte und eineVorstellung ber Gren auf dieser Karte. Die Darstellung des Mastabs wird in dieserArbeit bei Bildschirmkarten als noch wichtiger betrachtet, da durch die Mglichkeiten desZooming (Echtzeit Mastabsnderung) der berblick schnell verloren gehen kann. Map-GENeric sollte aus diesem Grund bei nderungen am Mastab den aktuellen Mastabberechnen und dauerhaft einblenden. Der Tourist kann dann beispielsweise abschtzen, obvon seiner aktuellen Standposition aus das nchste Museum zu Fu erreichbar ist oder ober lieber die Straenbahn nehmen sollte. Eine Angabe des Mastabs in der 1:x Notationkann bei Bildschirmkarten vernachlssigt werden, da dies Abhngig ist von der Gre desBildschirms und dessen Ausung bzw. Pixelgre, auf dem die Karte dargestellt wird.Fr die Grenabschtzung auf der Karte sollte ein Mastab wie in Abbildung 4.2 seinenZweck auch erfllen. Dieser Mastab 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 fh-ren, dass der eingezeichnete Mastab nicht in allen Richtungen treu bleibt. Dadurch wirdaber die Notwendigkeit fr ein Mastab nicht berhrt, 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 fr jede Klassevon Geoobjekten eine eigene Ebene erzeugt, auf der Geoobjekte der jeweiligen Klassegezeichnet werden. Die Karte in Abbildung 4.2 wre beispielsweise in den meisten GIS-Anwendungen so modelliert, dass Hotels in einer Ebene, Restaurants in einer anderen Ebe-4.2 Visualisierung in MapGENeric 49ne, Sehenswrdigkeiten in einer weiteren Ebene usw. dargestellt wrden. Durch separateEbenen entsteht die Mglichkeit, eine komfortable Darstellung zu bieten. Die einzelnenEbenen knnen in einer Ebenenliste, in der sie durch ihre Namen identizierbar sind, ein-und ausgeblendet werden, wodurch dem Nutzer die Mglichkeit gegeben wird, nur die frseine Bedrfnisse ntigen Geoobjekte anzeigen zu lassen und somit eine spezielle Kartezu erzeugen. Ein Tourist zum Beispiel, der sein Hotel schon gebucht hat, wird sich nichtmehr fr andere Hotels interessieren. In einem solchen Fall knnte er Hotels ausblenden,wodurch eine bessere bersicht fr die restlichen Geoobjekte von Interesse erreicht wird.Somit ist dieses Konzept auch in MapGENeric wnschenswert.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 knnenInteraktionsmglichkeiten, die eine Bildschirmkarte bieten muss, genutzt werden Darstel-lungen von Geoobjekten zu erlutern, so dass in dieser Arbeit auf die Modellierung undImplementierung einer Legende verzichtet werden kann.InteraktionInforetrieval 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 ntig ist.Diese Mglichkeit macht unter weiteren den Mehrwert einer Bildschirmkarte aus. Fr die-se Art der Interaktion knnte ein Informationsmodus bereitgestellt werden, der zu ausge-whlten graphischen Objekten eine Methode zum Informationsabruf und zur -darstellungzuweist. Zu einem separaten Modus fr diese Funktionalitt muss zurckgegrien wer-den, da verschiedene noch zu beschreibende Funktionen der fertigen Anwendung auf demgleichen Ereignis des Mausklicks basieren und deshalb nicht zu unterscheiden wren.Navigation Eine weitere Interaktion mit der Karte stellt die Navigation auf der Kartedar. Da auf Bildschirmen meistens nur ein Ausschnitt der gesamten Geodaten visualisiertwerden knnen, wie in Abschnitt 2.2.3 erlutert wurde, ist eine Navigation unerlsslich.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 gewnschten Richtung zu verschieben. Zur Navigation gibt es verschiedeneLsungen, wie sie folgend vorgestellt werden.1. Pan-NavigationDabei wird die Karte mit der Maus an einer beliebigen Stelle auf dem sichtbarenKartenausschnitt durch gedrckthalten der Maustaste festgehalten und in die ge-wnschten Richtung gezogen. Diese Navigation kann durch die Vorstellung erlutert50 Kapitel 4. Entwurf - Methodologie - Konzeptwerden, 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 vordenierten Platz auf der Arbeitsche der Anwendung frjede 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 Eekt der ersten beiden Navigationsarten dem Benutzer auch sichtbar machen zuknnen, sollte der Kartenausschnitt in Echtzeit verschoben werden knnen. Das wiederumwrde bedeuten, dass die Karte dreimal so gro wie der aktuelle Ausschnitt immer imSpeicher gezeichnet vorliegen msste. 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 Grnden fllt die Entscheidungfr 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 Mastab der Karte in Echtzeit zu verndern,wodurch der dargestellte Ausschnitt der realen Welt verkleinert oder vergrert wird.In obigem Beispiel ist z.B. denkbar, dass durch herauszoomen der Mastab verkleinertwird und dadurch mehr von der Stadt zu sehen ist als in dem Ausschnitt davor. Hierfrsollten die Standard Aktionen von gngigen Programmen bereitgestellt werden, wozu jeeine Taste fr das Vergrern und Verkleinern des Mastabs zhlt. Zum Zooming kannauch die Auswahl eines neuen Ausschnitts im sichtbaren Kartenausschnitt gezhlt werden.Hierbei wird in der Regel durch gedrckthalten und bewegen der Maustaste ein Bereichmarkiert. Dieser wird dann auf die verfgbare Darstellche der Anwendung gestreckt. Dader auswhlbare Bereich begrenzt ist auf den dargestellten Kartenausschnitt, ist lediglichein vergrern des Mastabs mglich. 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 Gredarstellen zu knnen, werden Koordinaten aller Geoobjekte mit zwei multipliziert.Soll hingegen um die Hlfte verkleinert werden, muss durch zwei dividiert werden.4.3 Visualisierungs-Mapping 512. Kartenausschnitt verndernHierbei werden nur die Koordinaten des Kartenausschnitts verndert. Der Karten-ausschnitt wird bestimmt durch zwei Koordinatenpaare, die ein Rechteck auf derKarte denieren. Diese Koordinatenpaare sind gegenberliegende Eckpunkte desAusschnitts. Dabei knnen diese, linke untere Ecke und rechte obere Ecke sein, oderlinke obere Ecke und rechte untere Ecke. Werden diese Eckkoordinaten nach Auenverschoben vergrern sie den Kartenausschnitt. Da aber der Bereich in dem dieKarte gezeichnet werden soll ihre Gre beibehlt, erscheinen Geoobjekte auf derKarte kleiner. Verschiebt man die Eckkoordinaten nher zueinander, dann wird derAusschnitt kleiner und die Geoobjekte werden grer.In dieser Arbeit wird das Zooming durch das Verndern des Kartenausschnitts verwirk-licht, da weniger Berechnungen ntig sind und die Ezienz somit hher ist.4.3 Visualisierungs-MappingBisher 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 fr 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 wurdeidentiziert, welche Darstellungsvariablen ntig sind und welche Interaktionsmglichkei-ten die GUI, in der die von MapGENeric erstellte Karte dargestellt werden soll, bietenmuss.In diesem Abschnitt soll Schritt fr Schritt eine Methode fr das Visualisierungs-Mapping erarbeitet werden, die den Anforderungen der Flexibilitt gerecht wird. Hierzuwird im folgenden erst einmal analysiert werden, aus welchen Bestandteilen eine Zuord-nung besteht und wie die Darstellung von Geoobjekten auf herkmmliche Weise funktio-niert. Diese Funktionsweise muss daraufhin beschrieben werden, da sie die Basis fr dasVisualizierungs-Mapping stellt. Im Verlauf werden diese Bestandteile dynamisiert werden,um am Ende zu einer Methode fr das Visualisierungs-Mapping zusammengefasst zu wer-den. Ferner wird festgestellt werden mssen, welche Daten ntig sind, um Geoobjekte derdrei Basisklassen darstellen zu knnen.4.3.1 Bestandteile des Visualisierungs-MappingsBei der Visualisierung der realen Welt auf Bildschirmkarten existieren auf der einen Sei-te die darzustellenden Objekte Geoobjekte(Modelle der Realitt) 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 Reprsentations-Objekte genannt werden. Das Aussehen dieser Reprsentations-52 Kapitel 4. Entwurf - Methodologie - KonzeptAbbildung 4.7: Zuordnung Geoobjekt DarstellungsformAbbildung 4.8: Symbol fr HotelsObjekte wird durch eine Menge von Darstellungsvariablen deniert, die im weiteren Dar-stellungsformen genannt werden. Zur Darstellung von GeoObjekten agiert in herkmm-lichen Kartengeneratoren eine Zuordnung zwischen GeoObjekten und Darstellungsformen,aufgrund dieser der Kartengenerator Reprsentations-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 fr die Darstellung weiterer Eigenschaften der Geoobjekte, Rckgrieauf die Datenbank ermglichen zu knnen.An Hand des folgenden Beispiels soll nher betrachtet werden, wie die Zuordnung aufherkmmliche 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) fr die Tabelle mit den Hotels implementiert, die ausge-fhrt wird. Daraufhin werden Geoobjekte aus dieser Tabelle mit dem Symbol aus Ab-bildung 4.8 gezeichnet. Um eine exible Zuordnung verwirklichen zu knnen, 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 wre dieses Mapping, wenn es die Mglichkeit bieten wrde, darzustellende Geoob-jekte zu spezizieren, Darstellungsformen fr diese zu denieren und einander zuzuordnen,wobei alle drei Mglichkeiten dynamisch sein mssten.4.3 Visualisierungs-Mapping 534.3.2 Dynamisierung des Visualisierungs-MappingsIn 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 Erweiterungsmglichkeitdieser 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 wrde die Menge der Dar-stellungsformen dieser Gegebenheit angepasst werden knnen. Die Zuordnung wrde dannals eine mathematische Abbildung z(x) aufgefasst werden knnen, 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 fr MapGENeric bieten. Dabei werdenimplizit Fragen beantwortet wie u.a. Welche Alternativen existieren zum System vonMapGENeric?.Dynamische ZuordnungUnter Bercksichtigung der drei Bestandteile eines Visualisierungs-Mapping ist eine mg-liche Auslagerung der Zuordnung fr einen exibleren Kartengenerator gegeben durchfolgendes System. In einem Kartengenerator sind verschiedene Darstellungsformen frjede Basisklasse von Geoobjekten mit eindeutigen Namen statisch im Quellcode imple-mentiert. Diese knnten fr obiges Beispiel, Hoteldarstellung01, Museumsdarstellung01,Straendarstellung01, Straendarstellung02, ..., lauten und Werte fr die Darstellungsva-riablen fr die jeweilige Basisklasse (Punkt, Linie oder Flche) aus Kapitel 4.2.1 bein-halten wie Farbe, Gre, Muster, usw. Es ist ausreichend, die vorhandene Geodatenbankanzupassen, indem die Beispieltabelle 4.2 der darzustellenden Geoobjekte um eine SpalteDarstellung erweitert und in dieser die oben genannten Namen eingetragen werden, wiein Tabelle 4.13 zu sehen.id name anz_spuren max_speed ampel darstellung1 Welschnonnenstr. 4 50 ja Straendarstellung012 Belderbergstr. 2 50 nein Straendarstellung033 Hubertustr. 4 70 ja Straendarstellung024 St.Georg Str. 1 50 nein Straendarstellung01: : : : : :Tabelle 4.13: Straen mit DarstellungsformDieses System hat den entscheidenden Nachteil, dass fr jedes Geoobjekt explizit an-gegeben werden muss, durch welche Darstellungsform diese darzustellen ist. Ferner ist dieUnabhngigkeit bzgl. der Geodatenbank nicht gegeben, da noch immer geodatenspezischprogrammiert werden muss. Der einzige Vorteil den uns ein solches System bringt, ist der,dass im Nachhinein die Darstellungsform der Geoobjekte gendert werden kann. Natrlich54 Kapitel 4. Entwurf - Methodologie - Konzeptschreibender Zugri fr 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 Mglichkeit derZuordnung entwickelt werden, die die Gruppierung von Geoobjekten Klassikation erlaubt (siehe Kapitel 2.2.1 - Modellierung von Geoobjekten). Eine naive Klassikationknnte im Kartengenerator implizit enthalten sein, so wie die Darstellungsformen im vor-angegangenen System mit eindeutigen Namen. Mit Hilfe eines GUI knnte dem Benutzerdes Systems die Mglichkeit geboten werden, diesen vordenierten Klassen, Darstellungs-formen zuzuordnen, wie in Abbildung 4.9. Gegenber dem vorherigen System wre damitlediglich eine leichtere Zuweisung fr den Benutzer ermglicht durch statische Geoobjekt-gruppen bzw. -klassen, denen die Darstellungsformen zugewiesen werden knnten anstatteinzelnen Geoobjekten. Alle anderen Nachteile (statische Geoobjektklassen und Darstel-lungsformen) wrden erhalten bleiben, weshalb weitere berlegungen gemacht werdenmssen. Jedoch ist in diesem System noch immer die Zuordnung dynamisch.Abbildung 4.9: Mapping ber GUIDynamische DarstellungsformenAls nchstes soll die Dynamisierung der Darstellungsform erarbeitet werden, wobei dieDiskussionen aus Abschnitt 4.2.1 helfen. Dort wurde festgestellt, dass fr verschiedeneBasisklassen unterschiedliche Darstellungsvariablen relevant sind. In Tabelle 4.14 ist eineZusammenfassung der Ergebnisse dieser Diskussion.Eine Dynamisierung wrde erreicht werden durch Auslagerung der Denitionen zuDarstellungsformen aus dem System. Es mssten hierfr Werte fr Darstellungsvaria-blen mit einem eindeutigen Namen durch den Nutzer eingegeben und gespeichert werdenknnen. Das GUI zur Zuordnung, wie sie in Abbildung 4.9 zu sehen ist, wrde in denAuswahlboxen fr Darstellungsformen statt der internen nun die Darstellungsformen ausdieser Speicherung anbieten. Mit der Auslagerung der Darstellungsformen und ihrer De-nition wird die Flexibilitt erhht.4.3 Visualisierungs-Mapping 55Punkt Linie FlcheFarbe + + + + + +Gre + + + + Form + + + + Muster + + + + + +Richtung + + + + Helligkeit + + +Tabelle 4.14: Relevante DarstellungsvariablenZeichenerklrung: ++ erforderlich / + erforderlich, jedoch bereits abgedeckt / nicht erforderlichVorstellbar fr bisher diskutierte Systeme wre auch eine Erweiterung, die eine hier-archische Struktur der Geoobjektklassen zulsst. Dadurch knnte eine Gruppe deniertwerden, die beispielsweise Straen heit und als Unterklassen Autobahn, Landstrae undBundesstraen hat. Dies htte den Vorteil, dass diesen Klassen Werte fr einzelne Dar-stellungsvariablen zugeordnet werden knnten, die bei der Generierung der Karte, je spe-zischer sie sind, andere berschreiben wrden. Fr dieses Beispiel wre denkbar, dassdie Oberklasse Straen einen Wert fr jede Darstellungsvariable erhlt. Autobahn knnteeinen anderen Wert fr Gre erhalten und die Farbe rot zugewiesen bekommen. DerKlasse Landstrae wrde man z.B. nur die Farbe gelb zuweisen. Bei der Generierung derKarte msste sich der Kartengenerator durch diese Klassenhierarchie arbeiten und, wennes bei der Oberklasse Straen beginnt, die Darstellungsvariablen dieser bernehmen. BeiAutobahn angekommen msste er die Linienstrke und Farbe mit den Werten fr Au-tobahn berschreiben und Geoobjekte, die der Geoobjektklasse Autobahn angehren,mit der neuen Darstellungsform zeichnen. Bei Landstraen wrde nur die Darstellungs-variable fr Farbe aus der Oberklasse berschrieben werden und dadurch Landstraenin Gelb dargestellt werden. Bei Bundesstraen, fr die keine Darstellungsvariablen ge-setzt sind, wrde die Darstellungsform der Oberklasse angewendet werden. Jedoch wirdin dieser Arbeit von einer solchen Lsung abgesehen, da fr potentielle Kartenautoren dieMapGENeric nutzen sollen, zu komplizierte Denition entstehen wrden, wodurch derberblick leicht verloren gehen knnte.Dynamische ObjektklassikationBisher wurde die Dynamisierung der Zuordnung und der Denition fr Darstellungsformenerreicht. Jedoch ist noch immer die Gruppierung der darzustellenden Geoobjekte zu einerKlasse (Klassikation siehe Kapitel 2.2.1 - Modellierung von Geoobjekten) mhsam.Ferner soll mit MapGENeric eine Datenbankunabhngigkeit erreicht werden, die in denbisher vorgestellten Systemen nicht ansatzweise vorhanden ist. Im folgenden soll die Fragegeklrt werden, wie denn Geoobjektklassen speziziert werden knnen, denen dynamischeine Darstellungsform zugewiesen werden kann. Bei herkmmlichen 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 knnen56 Kapitel 4. Entwurf - Methodologie - Konzeptoder sollen. Beispielsweise sei eine Klasse Museen gegeben, in der alle Museen aus derTabelle enthalten sind. Wrde nun der Bedarf bestehen, Museen mit Ausstellungen undohne Ausstellungen unterschiedlich darzustellen und dafr in verschiedene Klassen aufzu-teilen, weil dies vorher nicht bedacht wurde, msste die GIS-Anwendung umgeschriebenwerden. In MapGENeric sollen hnliche Aufteilungen oder Neudenitionen mglich sein,ohne MapGENeric umzuprogrammieren. Somit entsteht der Bedarf fr ein System, dasder dynamischen Denition 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. Geoobjekteknnen ber verschiedene Relationen verteilt gespeichert sein. Mit Hilfe einer Relationa-len Anfragesprache wie SQL, die in Kapitel 3.1.5 vorgestellt wurde, ist es mglich, berverschiedene Relationen Anfragen zu stellen, die eine Menge von Geoobjekten als Ergeb-nis zurck gibt. Relationen werden, wie in den Grundlagen zu Datenbanken zu lesen ist,deniert als Mengen; Mengen von Tupeln. Diese berlegungen fhren unweigerlich zurgewnschten Dynamisierung der Objektgruppierung/-klassikation. Denn mit SQL ist esmglich, jede durch Mengenoperatoren herleitbare Menge aus der Menge der in der Daten-bank gegebenen Daten zu denieren. Somit ist, um das Beispiel der Klassenunterteilungvon Museen aufzugreifen, mglich die Klasse Museen, die durch die SQL AnfrageSELECT * FROM museen;deniert wrde, zu unterteilen in zwei SQL Anfragen der FormSELECT * FROM museen WHERE ausstellung = "";undSELECT * FROM museen WHERE NOT ausstellung = "";Die durch SQL auf diese Weise denierten Geoobjektklassen mssten benannt werden,damit sie beispielsweise in einer Anwendung, die eine Zuordnungsmglichkeit bietet, wiesie in Abbildung 4.9 gezeigt wird, in der Spalte Objektgruppe angezeigt werden kann.Solche SQL-Anfragen, die Datenbanken an bestimmte Bedrfnisse anpassen und einenNamen erhalten, werden bezeichnet als Sichten (siehe Kapitel 3.1.5 Sichten). So ist einangepasster Zugri auf die Datenbank mglich. Da SQL von fast allen gngigen DBMSbereitgestellt wird, ist auch gleichzeitig eine datenbankunabhngige Klassizierung derGeoobjekte erreicht.4.4 Regelbasierter Ansatz fr das Visualisierungs-Mapping 574.4 Regelbasierter Ansatz fr dasVisualisierungs-MappingIn diesem Kapitel wurden bisher Lsungen 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 gengt, einen generischen Kartengenerator zu entwickeln.Die Komponente Visualisierungs-Mapping aus der Abbildung 4.1 kann durch eine ge-eignete Zusammenfhrung dieser dynamischen Bestandteile gebildet werden. Dabei solltenjedoch in Kapitel 4.1 und 4.2 identizierte Funktionalitten, wie unter anderem die Zu-weisung von Geoobjektklassen zu bestimmten Layern, verschiedene Kongurationen frdieselbe Geodatenbank und die mglichen Darstellungsvariablen fr Darstellungsformenbercksichtigt werden. Zusammenfassend kann das Visualisierungs-Mapping anhand fol-gender Schritte beschrieben werden: Geoobjektklassen denieren, ihre Darstellungsformdenieren und zuweisen, Layer bestimmen und zuweisen und diese drei einer Kongura-tion zuordnen. Diese Schritte knnen als Schritte einer Anleitung aufgefasst werden, diezu befolgen sind, um die Konguration eines generischen Kartengenerators zu denieren.Anleitungen dieser Art werden Regeln benannt. Eine Regel, die auf diesen Schritten ba-siert und die gewnschte Zuordnung beschreibt, knnte lauten: Stelle Geoobjekte x,y zuKlasse K zusammen und zeichne sie durch Darstellungsform D auf Layer L. Wird dieseRegel einer Konguration zugewiesen, so deckt sie zuvor identizierte 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 abhn-gig von den darzustellenden Daten und ihrer Darstellungen. Der Einsatz dieser Technikbedeutet fr die vorliegende Arbeit, dass eine Anwendungsunabhngigkeit erreichtwerden wrde. Denn Regeln stellen einzelne Bausteine dar, die durch das System derReihe nach abgearbeitet werden knnen, um das gewnschte Ergebnis zu erzielen. Dabeiist es irrelevant fr das System, zu welchem Ergebnis die Regeln fhren, solange sie dievereinbarte Syntax befolgen. Falls Ergebnisse verndert bzw. angepasst werden sollen, istlediglich das Anpassen dieser Konguration erforderlich. Aus diesen Beobachtungen las-sen sich zwei Akteure fr das MapGENeric-System identizieren, wobei ein Akteur einevom Anwender in Bezug auf das System eingenommene Rolle ist [FS00] :1. Der Kartenautorist fr die Konguration 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 verndern58 Kapitel 4. Entwurf - Methodologie - Konzeptund weitere Informationen zu bestimmten Geoobjekten anzufordern. Beispielsweisesind aus dem Touristik/Umwelt-Beispiel, der Tourist und der Umweltbeauftragteals Kartennutzer einzuordnen.4.4.1 Grundkonzepte der RegelspracheVorangegangene Beobachtungen legen nahe, das Visualisierungs-Mapping regelbasiertzu entwickeln. Hierzu ist die Denition einer Regelsprache notwendig. Im folgenden sollenGrundkonzepte einer solchen Regelsprache erarbeitet werden. Dazu werden bisher identi-zierte Bestandteile einer Zuordnung und gewnschte Funktionalitten nher betrachtet.Durch eine Diskussion entsteht Schritt fr Schritt ein Modell fr die Grundkonzepte derSprache, das dargestellt werden wird durch ein EntityRelationship-Diagramm(3.1.2). DasER-Diagramm wurde gewhlt, da es Zusammenhnge leichter verstndlich macht und einesptere berfhrung in ein relationales Datenbankschema nahezu automatisch ermglicht.Die berfhrung in ein relationales Datenbankschema ist insofern notwendig, als die Re-geln, die eine Konguration des MapGENeric-Systems darstellen, dauerhaft gespeichertwerden sollten. Fr jede Anwendung, die durch MapGENeric dargestellt werden soll, wirdeine relationale Datenbank vorausgesetzt, in der die darzustellenden Geodaten gespeichertsind. Da auch fr jede dieser Anwendungen eine Konguration fr MapGENeric erfor-derlich ist, empehlt es sich, einen Schreibzugri auf die darzustellende Datenbank zufordern und die anwendungsspezische Konguration in der jeweiligen Geodatenbank zuspeichern. Sind die Beziehungen zwischen einzelnen Bestandteilen einer Regel fr Map-GENeric erlutert, so wird in einem nchsten Schritt die Modellierung detaillierter aus-gearbeitet.Zusammengefasst soll eine Regelsprache entstehen, durch die Regeln formuliert wer-den knnen, die wiederum die Konguration von MapGENeric ausmachen. VerschiedeneKongurationen sollen zugelassen werden, so dass unterschiedliche Anwendungen undDarstellungen aus derselben Geodatenbank verwirklicht werden knnen. Ferner soll ei-ne Klassizierung verschiedener Geoobjekte zu einer Geoobjektklasse ermglicht werden.Diese sollen auf verschiedenen Layern dargestellt werden. Geoobjekten einer Klasse solleine Darstellungsform zugewiesen werden knnen, 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 denieren zwischen den drei dunkler dargestellten Entities Geoobjekt-klasse, Darstellungsform und Layer knnte ohne ihre Bezeichnung folgendermaen 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 deniert und deshalb als denieren bezeichnetwurde. Jetzt kann die Beziehung gelesen werden als Geoobjekte der Klasse [Geoobjektklas-se] dargestellt durch [Darstellungsform] auf [Layer] denieren [Regeln].4.4 Regelbasierter Ansatz fr das Visualisierungs-Mapping 59Abbildung 4.10: ER-Diagramm der Visualisierungs-Mapping-RegelspracheKongurationenKongurationen sollen mehrere Regeln fr eine bestimmte Anwendung bndeln. Die Zu-weisung von Regeln zu einer bestimmten Konguration erfolgt ber die Beziehung ent-halten. Um zu vermeiden, dass fr verschiedene sich hnelnde Anwendungen, die auf der-selben Geodatenbank basieren, dieselbe Regel mehrfach deniert werden muss, und ausder Forderung, dass verschiedene Regeln zu einer Konguration zusammengestellt wer-den knnen, die Visualisierungskonventionen fr eine bestimmte Anwendung darstellen,ist diese Beziehung als eine n:m-Beziehung modelliert worden. Dadurch wird ermglicht,dass Regeln unterschiedlichen Kongurationen angehren und diese Kongurationen wie-derum aus mehreren Regeln bestehen knnen. Damit Kartenautoren sowie -nutzer Kon-gurationen unterscheiden knnen, wird ein bezeichnendes Attribut notwendig, das Namegenannt wird (Abb. 4.11).LayerLayer stellen im bertragenen Sinn durchsichtige Folien dar, auf denen die darzustel-lenden Geoobjekte gezeichnet werden knnen. Es hat sich (wie auch im Grundlagenteilerlutert) durchgesetzt, dass Geoobjekte einer bestimmten Klasse auf demselben Layergezeichnet werden. Werden diese Folien (gleicher Mastab und Ausschnitt vorausgesetzt)bereinander gelegt, entsteht eine Karte. Durch das bereinanderlegen der Layer kn-nen unerwnschte berdeckungen von Geoobjekten entstehen. Generell werden deshalbchenhafte Objekte als erste, darber linienhafte und zu letzt punkthafte Geoobjektegezeichnet. Trotzdem knnen weiter unerwnschte berdeckungen entstehen. Wenn bei-60 Kapitel 4. Entwurf - Methodologie - Konzeptspielsweise eine berfhrung ber einer anderen Strae dargestellt werden soll, dann istauch die Zeichenreihenfolge unter den linienhaften Geoobjekten relevant. Das Layerkon-zept soll aus zwei Grnden eingefhrt werden:1. Kartenautoren soll die Mglichkeit geboten werden, bei der Erstellung einer Kon-guration, beispielsweise berdeckungsprobleme einfacher zu lsen. Dazu soll derKartenautor die Zeichenreihenfolge von Layern beliebig ndern knnen, um ent-scheiden zu knnen, welche Reihenfolge besser fr die gewnschte Darstellung derKarte geeignet ist.2. Der Kartennutzer dagegen soll Layer, deren Inhalt nicht seinem Interesse entspre-chen, ausblenden knnen (Kapitel 4.2.2).Wenn die bisher nur verbale Regel-Denition betrachtet wird, dann ist ein Layer dieZeichenche fr Geoobjekte, deren Reprsentations-Objekte durch Darstellungsformendeniert 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 vernachlssigt wird(Abb. 4.11).Durch zuvor erluterte berdeckungsprobleme ergibt sich die Notwendigkeit fr einAttribut der Regel, das seine Position in einer Regelbearbeitungsreihenfolge darstellt. Die-ses Attribut ist nicht der Regel selber zuzuordnen, weil eine Konguration aus ein odermehr Regeln besteht und eine Regel mehreren Kongurationen zugewiesen werden kann.Daraus ergibt sich, dass diese Position die Position in der jeweiligen Konguration dar-stellt und somit der Beziehung zwischen Konguration und Regel zuzuordnen ist, wie inAbbildung 4.11 dargestellt.Um bei der Konguration festlegen zu knnen, welche Layer sichtbar und welche nichtsichtbar sein sollen, muss ein weiteres Attribut eingefhrt werden. Dieses wird in Abb.4.11 durch Sichtbar dargestellt und ebenfalls der Beziehung enthalten zugeordnet,weil auch hier die Sichtbarkeit in der jeweiligen Konguration ausschlaggebend ist. Denndie Sichtbarkeit eines Layers in der einen Konguration kann erwnscht, jedoch in eineranderen Konguration nicht erwnscht sein. Fr die sptere Implementation ist ein solcherFlag auch aus Grnden der Performanz wichtig, da dadurch unerwnschte Geoobjektenicht ausgelesen werden mssen. Es ist sicherlich auch wnschenswert Layer zu benennen,um sie bei einer Kongurations-Denition wiedererkennen zu knnen. Dieses AttributName muss aus leicht ersichtlichen Grnden der Regel zugeordnet werden. Dadurcherweitert sich das ER-Diagramm, wie in Abb. 4.11 zu sehen ist.GeoobjektklassenAls nchstes wird das Augenmerk auf die Geoobjekt-Klassendenition gelenkt. Geoobjekt-klassen sollen Geoobjekt-Modelle mit hnlichen Eigenschaften zu einer Klasse gruppieren,damit dieser Klasse komfortabel eine Darstellungsform zugeordnet werden kann, mit der4.4 Regelbasierter Ansatz fr das Visualisierungs-Mapping 61Abbildung 4.11: ER-Diagramm erweitert um Layer-Attributesie gezeichnet wird. Zur Erkennung der jeweiligen Geoobjektklasse bei der Kongurations-Denition durch den Kartenautor sollte ein Bezeichner (Name) fr Geoobjektklassen ein-gefhrt werden.Zuvor in dieser Arbeit wurde gezeigt, dass Geoobjekt-Modelle einer Basisklasse (Punkt,Linie oder Flche) angehren. Um Reprsentations-Objekte dieser Geoobjekte entspre-chend zeichnen zu knnen, muss ein Kartengenerator wissen, welcher dieser Basisklassendas Geoobjekt angehrt, da verschiedene Routinen fr die Darstellung der einzelnen Basis-klassen erforderlich sind. Es knnte ein Kartengenerator entwickelt werden, der an Handder Geodaten analysiert, welcher Basisklasse diese angehren. Jedoch knnen Geoda-ten unabhngig von ihrer Modellierung unterschiedlich dargestellt werden, beispielsweiseknnten mit ihren Umrisskoordinaten modellierte Gebude, anhand eines dieser Umriss-koordinaten punktfrmig durch ein Bitmap dargestellt werden. Um die Flexibilitt vonMapGENeric auf dem hchstmglichen Niveau halten zu knnen, muss aus diesem Grundverlangt werden, dass die Basisklasse der zu spezizierten Geoobjektklasse mitgeteilt wird.Zur Klassikation von Geoobjekten wurde unter Dynamische Objektklassikation(Kapitel 4.3) eine Geoobjekte-Sicht-Denition erarbeitet, die ebenfalls eine Eigenschaftdes Entitytyps Geoobjektklasse darstellt, wie zuvor die Basisklasse. Ferner ist eine wei-tere Sicht-Denition fr die Darstellung der nicht-graphischen Geoobjekt-Eigenschaftenals notwendig befunden worden, die eine weitere Eigenschaft der Geoobjektklasse dar-stellt (Abb. 4.12).62 Kapitel 4. Entwurf - Methodologie - KonzeptAbbildung 4.12: ER-Diagramm erweitert um Geoobjektklassen-AttributeDarstellungsformenGeoobjekte aus der realen Welt knnen auf einer Karte nur durch Reprsentations-Objekte dargestellt werden. Zum Zeichnen eines Reprsentations-Objekts bedarf es ei-niger Werte fr Darstellungsvariablen (Kapitel 2.2.3). Diese Werte bestimmen das Aus-sehen der Reprsentations-Objekte. Geoobjekte derselben Klasse werden durch dasselbeReprsentations-Objekt dargestellt. Es wurde zuvor gezeigt, dass Geoobjekte einer vondrei Basisklassen (Punkt, Linie, Flche) angehren. Auf Seiten der Darstellung werdenauch drei Klassen von Reprsentations-Objekten unterschieden, fr die lt. Diskussionen inKapitel 4.2.1 unterschiedliche Darstellungsvariablen relevant sind. Die Bndelung der Dar-stellungsvariablen zur Denition eines Aussehens fr diese Klassen von Reprsentations-Objekten werden in dieser Arbeit Punkt-, Linien- und Flchen-Darstellungsformen ge-nannt werden. Wenn Geoobjekte, wie im obigen Beispiel als Hotels klassiziert werden,erhalten sie in Regeln eine Punkt-Darstellungsform zugeordnet, die das Aussehen ihresReprsentations-Objekts beschreiben.Auf Grund dieser Beobachtungen wird im folgenden das Modell fr Darstellungsformenentwickelt. Darstellungsformen setzen sich zusammen aus den einzelnen Darstellungsfor-men fr die Basisklassen Punkt, Linie und Flche. In der ER-Diagramm-Darstellung wirddies, wie in Abbildung 4.13 zu sehen ist, durch eine is-a-Generalisierung dargestellt. Dadie Darstellungsvariable Farbe fr alle Darstellungsformen bentigt wird, ordnet man siedem Obertyp zu, in diesem Fall Darstellungsform. Die Untertypen PunktDF, LinieDF undFlcheDF erhalten ihre spezischen Eigenschaften wie Hhe, Breite, Muster, etc. (sieheAbbildung 4.13).4.4 Regelbasierter Ansatz fr das Visualisierungs-Mapping 63Abbildung 4.13: ER-Diagramm fr DarstellungsformenDie Darstellungsform fr Punkte (PunktDF) sollte nach o.g. Beobachtungen neben derFarbe die Gre und eine Form besitzen. Die Gre ist durch die beiden EigenschaftenLnge und Breite modelliert. Die Form bedarf zwei weiterer Variablen, da zuvor festge-stellt wurde, dass Formen durch Bitmaps mglich sind und zur ezienteren Darstellungvon oft vorkommenden Punktobjekten vordenierte Formen bereitgestellt werden sollten.Zur Darstellung von Linien sind einige weitere Eigenschaften notwendig. Bei der Gr-enangabe fr Linien entfllt die Lngenangabe, da diese durch die Begrenzungskoordina-ten der Linie festgelegt werden. Jedoch kommen Muster, Anfang und Ende hinzu. Musterspeziziert dabei, ob eine Linie durchgehend, gepunktet, gestrichelt oder aus Kombina-tionen der letzten beiden dargestellt wird. Anfang und Ende denieren das Aussehen derLinien. Die Form wird bei Linien anders als bei Punkten deniert. Sie deniert bei ge-punkteten und gestrichelten Linien, wie die einzelnen Elemente dieser Linie dargestelltwerden (spitze, runde oder ache Enden).Bei der Darstellungsform fr Flchen (FlchenDF) wurde zuvor gezeigt, dass nebender Farbe noch das Muster von Bedeutung ist, weshalb alle anderen Darstellungsvariablennicht explizit angegeben werden mssen. Daraus resultiert, dass auch im ER-Diagrammkeine weiteren Eigenschaften zugeteilt werden mssen. Um die Grenzen einer Flche deut-lich machen zu knnen, bietet es sich an, diese kenntlich zu machen. Grenzen knnen ambesten durch eine Linie dargestellt werden, wofr eine eigene Darstellungsform existiert.Dies fhrt unweigerlich dazu, dass der FlchenDF eine LinienDF zugewiesen werden soll-te. Im ER-Diagramm in Abbildung 4.13 wird dies als Beziehung umrahmt dargestellt. Dasendgltige Modell der MapGENeric-Visualisierungs-Mapping-Regelsprache ist in Abbil-dung 4.14 zu sehen.64 Kapitel 4. Entwurf - Methodologie - KonzeptAbbildung 4.14: Modell der Visualisierungs-Mapping-RegelspracheKapitel 5Syntax und Semantik derRegelsprache VRLIm letzten Kapiel wurde die Notwendigkeit einer Regelsprache deutlich, die zur Beschrei-bung einer Konguration fr das ebenfalls im letzten Kapitel modellierte MapGENeric-System dient. Eine Konguration ist aufzufassen als eine Menge von Regeln, die die Dar-stellung von Geoobjekten aus einer relationalen Geodatenbank deniert. Ferner wurdenim letzten Kapitel Grundkonzepte einer solchen Regelsprache erlutert, die in diesem Ka-pitel ergnzt werden sollen zu einer formalen Beschreibung dieser Sprache.Im folgenden soll die Syntax der Regelsprache durch eine kontextfreie Grammatikformal deniert werden. Diese Syntax wird Schritt fr 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 deniert ist, gesondert betrachtet. Diese Nonterminale werden imfolgenden nal Nonterminale genannt und mit F-Nonterminal abgekrzt.Im folgenden sollen alle Konventionen getroen werden, die bei der Grammatikbe-schreibung genutzt werden, um die Syntax der Regelsprache VRL zu denieren. Dabeisind diese Konstrukte nicht als Erweiterung der BNF-Notation fr eine bessere bersichtanzusehen, sondern vielmehr als Grammatikeigenschaften der Regelsprache, um Stze derSprache bersichtlicher zu gestalten:1Die in diesem Kapitel schrittweise erarbeitete Grammatik ist mit einem Beispiel in Anhang A dar-gestellt.6566 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 Anfhrungszeichen geschrieben.Die Erweiterung der BNF-Notation durch das Konstrukt [uGrenze .. oGrenze]2,wird eingefhrt, um eine komplizierte Grammatikbeschreibung zu vermeiden und dientzur Darstellung von numerischen Wertebereichen.5.1 VM-RegelnVM-Regeln denieren 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 knnen: ::= VMREGEL ( " " ){ }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. kann aus einer beliebigen Zeichenkette bestehen, jedoch soll deren Lnge aus praktischenGrnden begrenzt werden auf 25 Zeichen. Ferner muss der Name eindeutig vergeben wer-den, da ber ihn auf die Regel zurckgegrien 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 denieren.5.2 KongurationenEine Menge bestimmter VM-Regeln, die zusammengenommen eine Visualisierung vonGeodaten einer Geodatenbank fr eine bestimmte Anwendung denieren, knnen zu einerKonguration zusammengefasst werden. Es wurde zuvor gezeigt, dass es zu unerwnschtenberdeckungen von Geoobjekten kommen kann, wenn eine Konguration aus mehr als ei-ner Regel besteht. Um diese unerwnschten berdeckungen vermeiden zu knnen, mssenVM-Regeln eine Position (RegelPos) in der Reihenfolge der Abarbeitung erhalten. DiesePosition ist fr Regeln einer Konguration eindeutig zu vergeben, d.h. zwei oder mehrVM-Regeln einer Konguration drfen nicht dieselbe RegelPos haben. Positionsangaben2UntereGrenze .. ObereGrenze des Wertebereichs5.3 Darstellungsformen 67werden als positive ganze Zahl deniert. Ferner muss die Sichtbarkeit bercksichtigt wer-den, die bei der Konguration durch den Kartenautor eine initiale Einstellung erhaltensoll. Aus diesen neuen Gegebenheiten folgt, dass die -Denition angepasstwerden muss: ::= VMREGEL ( " " , , ){ } ::= on | offKongurationen haben ebenfalls einen Namen (siehe Abbildung 4.14), durch den sie ein-deutig identiziert werden knnen. Die Kongurations-Denition folgt dem Namen ingeschweiften Klammern. ::= KONFIGURATION ( " " ) { } ::= | Durch bisher denierte Grammatikregeln ist lediglich eine Kongurations-Denition mg-lich, es war jedoch gefordert, fr dieselbe Geodatenbank verschiedene Kongurationendenieren zu knnen. Dies wird erreicht durch: ::= |Das Nonterminal () stellt gleichzeitig das Startsymbol der Grammatikdar.Bisher wurde das Grundgerst der VRL formal beschrieben, in der die Nonterminale und noch undeniert geblieben sind. Die De-nition dieser Nonterminale soll in den folgenden Teilkapiteln erfolgen.5.3 DarstellungsformenDie Beschreibung der Darstellungsformen ist wesentlich komplexer als die der vorangegan-genen Nonterminale. Fr jede der Basisklassen Punkt, Linie und Flche wird eine andereSyntax bentigt, da diese unterschiedliche Darstellungsvariablen bentigen. ::= | | 68 Kapitel 5. Syntax und Semantik der Regelsprache VRL5.3.1 PunktDFPunkt-Darstellungsformen bentigen fr die Reprsentation eines punkthaft modellier-ten Geoobjekts Farbe, Lnge, Breite, Form und Bitmap. Die Farbe wurde modelliert ausje einem Wert fr Alphakanal(Transparenz), Rot, Grn und Blau. Da die Farbvielfaltmit 16,7 Mio. Farben ausreichend erschien, wurden Werte von 0 bis 255 erlaubt. Fr und werden lediglich Zahlen eingesetzt, die in diesem Fall Wertein Pixeln darstellen. Fr die Darstellung von punktfrmigen Geoobjekten, die in groerMenge auftreten und dadurch berfrachtend wirken knnten, wurde es in Kapitel 4.2.1fr sinnvoll befunden, vordenierte Formen bereitzustellen (Ellipse, Dreieck und Recht-eck). Das letzte Nonterminal fr die Denition von ist das Bitmap, das eineZeichenkette beinhalten darf, das wiederum einen absoluten Verzeichnispfad zu einer Bit-mapdatei reprsentiert. Absolut bedeutet dabei, dass beispielsweise fr windowsbasierteDateisysteme der Pfadangabe auch ein Laufwerksbuchstabe vorangestellt sein muss. ::= PUNKTDF ( , ){ } ::= FARBE ( ) |FARBE ( , , , ) ::= [0..255] ::= [0..255] ::= [0..255] ::= [0..255] ::= PFORM( ) |PFORM(Ellipse) |PFORM(Dreieck) |PFORM(Rechteck) ::= BITMAP ( ) |BITMAP ( " " )Darstellungsformen fr punktfrmige Geoobjekte knnen auf zwei Arten deniert werden.Bei der ersten Variante reicht es, neben der Lnge und Breite lediglich einen Pfad zueinem Bitmap zu denieren. In diesem Fall brauchen keine Angaben zu Farbe und Formgemacht werden, weshalb sie in der Grammatikbeschreibung auch leer vorkommen knnen.Umgekehrt verhlt es sich in der zweiten Variante. Wenn eine Punkt-Darstellungsformdeniert wird durch Farbe und Form, so ist eine Bitmap-Angabe berssig.5.3 Darstellungsformen 695.3.2 LinieDFFr die Denition von Linien-Darstellungsformen wird eine grere Anzahl an Darstel-lungsvariablen bentigt als fr die anderen beiden Formklassen. Neben der Farbe sinddies Breite, Muster, Anfang, Ende und Form. Fr Farbe und Breite ist keine spezielleGrammatikregel-Denition notwendig, so dass die zuvor genannten Nonterminale ( und ) hier ebenfalls genutzt werden knnen. Das Muster einer Linie wirddeniert durch eine begrenzte Kombination aus Linienelementen (solid, dash und dot).Um beispielsweise Einbahnstraen, Sackgassen mit und ohne Wendemglichkeit darstel-len zu knnen, wurde es fr notwendig erachtet, Linienanfang und -ende entsprechenddurch eine Pfeilspitze, einen Kreis und ein Rechteck zu markieren. Die begrenzte Kombi-nation aus Linienelementen fr das Muster ist mit seiner Variationmglichkeit durch dieverwendete Programmiersprache Visual Basic als nicht ausreichend befunden worden, sodass durch Hinzunahme der Darstellungsvariable Form eine weitere Variationsmglichkeitentsteht. ::= LINIEDF ( , , , ){ } ::= solid | dash | dot | dashdot | dashdotdot ::= ::= ::= ArrowAnchor | RoundAnchor | SquareAnchor | NoAnchor ::= LFORM( ) |LFORM(flat) |LFORM(round) |LFORM(triangle)5.3.3 FlaecheDFDarstellungsformen fr chenfrmige Geoobjekte haben lediglich drei Eigenschaften, an-hand derer sie die Darstellung von Geoobjekten denieren. Diese sind Farbe, Muster undUmrandung. ::= FLAECHEDF { } ::= Fr die Farbe kann, wie zuvor fr Linien-Darstellungsform, die bisherige Denition ber-nommen werden. Da es sich bei Muster um ein Bitmap handelt (siehe Kapitel 4.2.1), kannhierfr die Denition fr das Nonterminal genutzt werden. Bleibt lediglich dieDenition fr Umrandung, die jedoch deniert wird durch die Darstellungsform-DenitionLinieDF.70 Kapitel 5. Syntax und Semantik der Regelsprache VRL5.4 GeoobjektklasseIn 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-Denition deniert werden mssen (Abbildung 4.12). ::= GEOOBJEKTKLASSE( " " , ){ } ::= Punkt | Linie | FlaecheFr eine graphische Reprsentation 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 punktfrmigen Geoobjekten ein, beilinienfrmigen mindestens zwei und bei chenfrmigen mindestens drei Koordinatenpaa-re bentigt.Zur Geoobjektklassen-Denition wird eine Sichtdenition () auf diezuvor genannten Geometriedaten bentigt. Da eine Unterteilung von Geoobjekten inpunkt-, linien- und chenfrmige Geoobjekte existiert und diese verschiedene Anzah-len von Koordinatenpaaren bentigen, um dargestellt werden zu knnen, mssen diesedierenziert analysiert werden. Dabei soll ermittelt werden, wie eine solche Sichtdeniti-on fr die jeweilige Basisklasse aussehen muss.5.4.1 Punktfrmige GeoobjektePunktfrmige Geoobjekte werden in Datenbanken in der Regel so modelliert, dass in einerTabelle alle punktfrmigen Geoobjekte einer Klasse gespeichert werden. Ein Beispiel hier-fr bildet die Tabelle 4.10, in der alle Hotels gespeichert sind. Jedes Tupel dieser Relationreprsentiert ein Hotel mit dem jeweiligen Koordinatenpaar. Es gibt nicht zuletzt auchdie Mglichkeit, wie sie Tabelle 4.8 darstellt. Hier liegen die Koordinatenpaare in eineranderen Relation. Fr die Darstellung dieser Geoobjekte durch Reprsentations-Objekteinteressiert einzig und allein das jeweilige Koordinatenpaar. Um jedoch weitere Informa-tionen zu den jeweiligen Geoobjekten auf Anforderung darstellen zu knnen, wre dasMitfhren des eindeutigen Schlssel (ID) von groer Bedeutung. Dieser ID identiziertGeoobjekte eindeutig innerhalb der Relation, in der ihre Geodaten gespeichert sind.Damit ein generischer Kartengenerator wie MapGENeric punktfrmige Geoobjektedarstellen kann, muss er Lngen- und Breitengrad dieses Objektes kennen. Da die Spal-ten, in denen diese Informationen in der jeweiligen Geodatenbank gespeichert sind, un-terschiedlich benannt worden sein knnen, muss fr MapGENeric gefordert werden, dassdiese dem System mitgeteilt werden. Eine weitere, bessere Alternative wre, dass Map-GENeric einen bestimmten Namen fr diese Spalten erwartet und die Geodaten bzw.5.4 Geoobjektklasse 71die Sicht auf diese angepasst werden. Dies kann in der zuvor erarbeiteten Dynamisie-rung der Objekklassikation einfach geschehen, da die Objektklassikation durch SQLerfolgt und darin Umbenennungsfunktionen enthalten sind. Soll neben einer Informati-onsdarstellung auf Wunsch auch eine dauerhafte Darstellung eines Attributs ermglichtwerden, so ist dieses Attribut ebenfalls in die Sichtdenition zu integrieren. Eine solchedauerhafte Darstellung wird meistens bei der punktfrmigen Darstellung von Stdten ge-nutzt, bei der unter dem Reprsentations-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 punktfrmigen Geo-objekten in MapGENeric lediglich Lngen- und Breitengrad bentigt werden. Optionalwerden ID (zur Darstellung weiterer Geoobjekt-Eigenschaften) und ein weiteres Attributfr die Bezeichnung bentigt. Die Sichtdenition () muss diese Attributebereitstellen. Damit MapGENeric die Spalten der Relation, die durch die Sicht deniertwird, zuordnen kann, sollten sie diejenigen Namen erhalten, die MapGENeric erwartet.Diese werden deniert als mge_id, mge_long, mge_lat und mge_label. Das Krzelvor den Bezeichnern wird eingesetzt, um evtl. Namenskonikte mit dem DBMS oder derGeodatenbank zu vermeiden. Die erarbeitete Sichtdenition soll am folgenden Beispieldargestellt werden, das aus der in Tabelle 4.10 dargestellten Relation Hotels mit mehr als200 Betten gruppiert und somit eine Geoobjektklassen-Denition darstellt:SELECTid AS mge_id,laengengrad AS mge_long,breitengrad AS mge_lat,name AS mge_labelFROMhotelsWHEREanzahl_zimmer > 200Das Besondere an solchen Klassendenitionen durch Sichten ist, dass alle erdenklichenSQL-Anfragen, die auf der darzustellenden Geodatenbank mglich sind, auch fr solcheSichtdenitionen genutzt werden knnen. Die einzige Restriktion ist, dass der SELECT-Teil zumindest Werte fr mge_long und mge_lat bereitstellen muss.Linienfrmige GeoobjekteLinienfrmige 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 Straenbahn (Tabelle 4.7). Dabei wird ihre Geometrie durch ihre beidenEnden deniert, die in diesem Beispiel der jeweiligen Haltestellen mit ihren Koordi-natenpaaren entsprechen (Tabelle 4.6).72 Kapitel 5. Syntax und Semantik der Regelsprache VRL Linienzgewerden 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 Sichtdenition beispielsweise mge_long1, mge_lat1, mge_long2und mge_lat2 werden.2. Die zwei notwendigen Koordinatenpaare werden aus je einem Tupel erwartet, dieber ihre GeoobjektID als zusammengehrend identiziert werden knnen.Zur Darstellung von Linienzgen hingegen ist lediglich die Variante ber ein Tupelfr jedes Koordinatenpaar mglich. 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 frdie Darstellung eines solchen Linienzugs notwendig, da sonst eine realittsgetreue Dar-stellung nicht mglich wre. In der Schemadenition sorgt das Attribut position fr dieOrdnung der Folge, wodurch erst eine korrekte Darstellung des Flussverlaufs erstellt wer-den kann.Um eine mglichst einheitliche Sichtdenition zu ermglichen, wird die fr beide Li-nienmodelle (einfache Linien und Linienzge) nutzbare Variante ber mehrere Tupel ge-whlt. Durch diese Wahl und vorangegangene Beobachtungen folgt unweigerlich, dass zurDarstellung linienfrmiger Geoobjekte durch MapGENeric ein weiteres Attribut fr dieKlassen-Sicht-Denition zwingend notwendig wird, die die Position des jeweiligen Ko-ordinatenpaares in der Folge wiedergibt. Jedoch ist dieses Attribut fr einfache Linienoptional. Zu beachten ist, dass im Gegensatz zur Sichtdenition der punktfrmigen Geo-objekte hier die ID zwingend erforderlich ist, um zusammengehrige Koordinatenpaareidentizieren zu knnen. Es folgt ein Beispiel fr die Klassen-Sicht-Denition Flsse:SELECTf.id AS mge_id,k.laengengrad AS mge_long,k.breitengrad AS mge_lat,f.name AS mge_labelfk.position AS mge_seqposFROMflusskoordinaten AS fk,fluesse AS fkoordinaten AS kWHEREf.min_tiefe > 10AND f.id = fk.fluss_id5.4 Geoobjektklasse 73Mit dieser SQL-Anfrage wrde eine Relation mit Flssen zurckgegeben werden, die alleFlsse beinhaltet, die eine Mindesttiefe von 10 Metern haben und somit fr groe Schiebefahrbar sind.5.4.2 Flchenfrmige GeoobjekteFlchenfrmige Geoobjekte werden wie Linienzge 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 Linienzgen verlangt wurde, werden Darstellungsfehler vermieden.Fr die Denition einer Geoobjektklasse sind somit zwei Arten von Klassen-Sicht-Denitionen mglich: Geoobjektklassen mit der Basisklasse Punkt und Geoobjektklassen mit den Basisklassen Linie oder Flche . Ausdiesen Beobachtungen lassen sich folgende Grammatikregeln folgern: ::= GEOOBJEKTE ( ) |GEOOBJEKTE ( ) ::= SELECT AS mge_id, AS mge_long, AS mge_lat, AS mge_labelFROMWHERE ::= SELECT AS mge_id, AS mge_long, AS mge_lat, AS mge_label AS mge_seqposFROMWHEREGeoobjektklassen sollten eindeutig deniert werden und Schemaweit eindeutige Na-men besitzen. Die Denition ihrer Sichten ist ein regulrer SQL-Ausdruck, der ber derMenge von Relationen der darzustellenden Geodatenbank deniert ist. Dies ist jedochmit einer kleinen Einschrnkung bzgl. der Attributmenge verbunden, die zurckgegeben74 Kapitel 5. Syntax und Semantik der Regelsprache VRLwird. Die Attribute dieser Menge sind mit Name und erwartetem Typ vorgegeben, wo-bei lediglich die Typen fr mge_seqpos (ganze Zahlen), Lngen- und Breitengrad (reelleZahlen) fest erwartet werden. Fr mge_id ist lediglich gefordert, dass dieses Attribut eineindeutiger Schlssel ist, der das Geoobjekt identiziert unabhngig davon, ob es eineZahl oder ein String ist. Bei mge_label ist es ebenfalls irrelevant, ob Zahl oder String zu-rckgegeben wird. Die Nonterminale bis stellen die Pendants zu diesenerwarteten Attributen dar und mssen durch die Attributnamen der Relationen ersetztwerden, die in stehen, die wiederum aus der darzustellenden Geodatenbankstammen. Dabei ist natrlich zu beachten, dass den eindeutigen Schlssel IDdes Geoobjektes liefert, den Lngengrad, den Breitengrad, den Bezeichner und die Position des Koordinatenpaars in der Folge des Linien-zugs. Fr kann jede in SQL zulssige Bedingung eingetragen werden, dieber die in aufgefhrten Relationen deniert ist.Fr die Geoobjektklassen-Denition ist neben der Geoobjekt-Sicht eine Sicht auf dieAttribute der durch die Geoobjekt-Sicht gruppierten Geoobjekte notwendig. Dies ist einoptionales Element der Geoobjektklassen-Denition, die ausschlielich fr die Interakti-onskomponente des Systems bentigt wird, um weitere nicht-graphische Eigenschafteneines ausgewhlten Geoobjekts auf Anfrage darstellen zu knnen.Die Geoobjekte-Sicht liefert ausschlielich die fr die Darstellung der Reprsentations-Objekte notwendigen Daten. Die Relation, die von dieser Sicht deniert wird, enthlt dieDaten einer Menge von Geoobjekten, die das Kriterium im WHERE-Teil dieser Sicht er-fllen. Sollen auf Anfrage nicht-graphische Attribute dieser Geoobjekte dargestellt werdenknnen, so ist eine Relation mit diesen nicht-graphischen Attributen notwendig, in derdiese Attribute des gewnschten Geoobjekts eindeutig identiziert werden knnen. Dazumuss die Attribut-Sicht eine Spalte enthalten, die einen Fremdschlssel zur Geoobjekte-Sicht darstellt. Auf Wunsch eines Kartennutzers nach mehr Informationen zu einem Geo-objekt, knnte MapGENeric, auf die durch diese Attribut-Sicht denierte Relation, eineSQL-Anfrage stellen mit dem bekannten Schlssel Id des Geoobjekts. Der Spaltennamedieser Attribut-Sicht, der den Fremdschlssel bereithlt, muss MapGENeric bekannt seinund wird deshalb als mge_id vorausgesetzt.Dafr msste die Grammatikregel-Denition fr die Attribut-Sicht folgendermaenaussehen: ::= ATTRIBUTE () |ATTRIBUTE (SELECT AS mge_id,FROM)5.4 Geoobjektklasse 75 msste den Namen der Spalte in der Geodatenbank enthalten, die den Fremd-schlssel darstellt zur Relation, die durch die Geoobjekte-Sicht deniert wurde. Dies sollan einem Beispiel verdeutlicht werden. Dazu soll erneut die Tabelle 4.10 mit den Ho-tels betrachtet werden. Beispielhaft knnte eine Geoobjekte-Sicht, wie folgend deniertwerden, die alle Hotels in dieser Relation gruppiert, die mehr als 200 Betten bieten:GEOOBJEKTE ( SELECTid AS mge_id,laengengrad AS mge_long,breitengrad AS mge_lat,name AS mge_labelFROMhotelsWHEREanzahl_betten > 200)Ein Attribut-Sicht-Beispiel dazu:ATTRIBUTE ( SELECTid AS mge_id, *FROMhotels)Diese Attribut-Sicht deniert eine Relation, die als Fremdschlssel-Spalte mge_id undalle anderen Spalten der Relation hotels hat. Dadurch ist es MapGENeric mglich, aufdiese Relation eine SQL-Anfrage der folgenden Form zu stellen, da der Schlssel des Geo-objekts bekannt ist, der durch den Nutzer ausgewhlt wurde. Ferner ist dem System dieFremdschlssel-Spalte bekannt, da diese in der Grammatik-Denition des Nonterminals deniert wurde:SELECT * FROM ( SELECTid AS mge_id, *FROMhotels)WHERE mge_id = [X];Das im Code-Fragment dargestellte [X] msste von MapGENeric durch die Geoobjekt-IDersetzt werden, die durch die Nutzer-Aktion ermittelt wrde. Dadurch wrde fr diesesBeispiel eine einzeilige Relation entstehen, die beispielsweise wie folgend aussehen wrde:76 Kapitel 5. Syntax und Semantik der Regelsprache VRL2 Luxor 248 199 7,10554 50,73870Wrde diese Tabelle in dieser Form dem Kartennutzer dargestellt werden, wssteer nicht, welcher Wert welche Bedeutung htte. Deshalb muss vom Kartenautor eineDenition fr gefordert werden, die eine Beschreibung der Werte mitsich bringt:ATTRIBUTE ( SELECTid AS mge_id,'Hotelname: ' , name,'Anzahl der Betten: ' , anzahl_betten,'gnstigster Preis: ' , preisFROMhotels)Diese Attribut-Sicht-Denition htte bei zuvor dargestellter SQL-Anfrage durch Map-GENeric folgende Resultat-Relation:2 Hotelname: Luxor Anzahl der Betten: 248 gnstigster Preis: 199Eine solche auch zuvor unbekannte Relation, die einem bestimmten Schema (womitkein Datenbankschema gemeint ist) entspricht, knnte durch ein System wie MapGENerickomfortabel dargestellt werden, indem nach der ID die Werte fr je zwei Spalten neben-einander und darauf ein Zeilenumbruch folgend dargestellt werden (Abbildung 5.1).Abbildung 5.1: Info-Fenster fr nicht-graphische AttributeKapitel 6Architektur und Funktionalitt vonMapGENericIn diesem Kapitel wird zunchst die Gesamtarchitektur des MapGENeric-Systems vor-gestellt werden. Ferner wird die Struktur und die Funktionalitt der Schnittstellen vonMapGENeric diskutiert werden. Hierzu zhlen Autoren- und Nutzer-Schnittstelle mit ih-ren spezischen Funktionalitten, die in Kapitel 4.2.2 erarbeitet wurden. Die schrittweiseKonstruktion einer Karte durch einen Kartenautor wird genutzt, um die Komponentenfr die Autoren-Schnittstelle mit Struktur und Funktionalitt detailliert darzustellen.6.1 MapGENeric-Architektur im KontextIn Kapitel 4 ist ein System entworfen worden, das unabhngig von Anwendung und Daten-bank 2D-Bildschirmkarten generieren kann. Der Map Generator ist die Hauptkomponentein diesem System. Im Rahmen dieser Arbeit wurden des weiteren fr die beiden zuvoridentizierten Akteure (siehe Kapitel 4.4) im MapGENeric-System graphische Ober-chen entwickelt, die deren Bedrfnissen gerecht werden. Da eine Datenbankunabhngigkeitgefordert war, ist eine Schnittstellenarchitektur fr 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 fr unter-schiedliche Anwendungen Daten der darzustellenden Geoobjekte. Mit Anwendungensind unterschiedliche Einsatzgebiete fr MapGENeric gemeint, wie beispielsweise Stras-sennetzkarte fr PKW-Fahrer, Stadtfhrer fr Touristen oder Umweltbelastungsplne frUmweltbeauftragte. Um Geoobjekte anwendungsbezogen durch MapGENeric darstellenzu knnen, muss MapGENeric fr jede Anwendung separat konguriert werden. Dabeiknnen 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-7778 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.1: MapGENeric im Kontexttenkarte II) verschieden dargestellt werden knnen. Diese anwendungsspezischen Kon-gurationen werden vom Kartenautor ber ein Kartenautor-GUI eingegeben und in derjeweiligen Geodatenbank gespeichert.Um das Ergebnis der Konguration sehen zu knnen, steht dem Kartenautor dieNutzer-GUI ebenfalls zur Verfgung. Die Nutzer-GUI stellt die Karte dar, wie sie durchden Map Generator unter Bercksichtigung der Visualisierungs-Regeln erstellt wurde.Ferner dient sie dem Kartennutzer als Eingabemaske fr 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 zurck zum Nutzer-GUI leitet.ber den DataManager kommuniziert MapGENeric mit der externen KomponenteADO.NET, die Klassen fr die Kommunikation mit unterschiedlichen DBMS bereithlt.Ferner untersttzt 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 Konguratio-nen und zum Auslesen der Informationen zum Erstellen der Karte erforderlich sind.Im Kern der vorgestellten Architektur agiert der Map Generator. Dieser ist zustndigfr die Generierung, der durch das Nutzer-GUI angeforderten Bildschirmkarte unter Be-rcksichtigung der ber das Kartenautor-GUI eingegebenen Kongurationen. Dazu wer-den diese Kongurationsdaten ber den DataManager angefordert. Der Map Generatorarrangiert in diesen Kongurationsdaten spezizierte Geoobjektdaten, die ebenfalls berden DataManager angefordert werden, zu einer Bildschirmkarte. Diese Bildschirmkartegelangt daraufhin ber den InteractionManager wieder zum Nutzer-GUI.6.2 Autoren-Schnittstelle 796.2 Autoren-SchnittstelleVon MapGENeric wird erwartet, dass es unabhngig von Datenbankschema Geoobjekteaus relationalen Geodatenbanken als graphische Objekte auf einer Bildschirmkarte dar-stellen kann. Dabei soll es mglich sein, die Darstellungsform der Geoobjekte jederzeitndern zu knnen. Es wurde zuvor in Kapitel 4.3 gezeigt, dass eine Konguration desSystems notwendig ist, um diese Funktionalitt bieten zu knnen. Zu dieser Kongu-ration gehren Geoobjektklassen, Darstellungsformen und Layer (siehe Kapitel 4.4.1).Es wurden zwei Akteure in MapGENeric identiziert, von denen der Kartenautor frdiese anwendungsspezische Konguration zustndig ist. Er ist fr die Denition derGeoobjektklassen, der Layer, der Darstellungsformen und fr die Zuweisung zueinandermit Hilfe der Visualisierungs-Regeln verantwortlich. Diese Denitionen werden ber dasKartenautor-GUI eingegeben und ber den CongManager mit Hilfe des DataManagersin der jeweiligen Geodatenbank gespeichert.Die graphische Benutzeroberche fr Kartenautoren besteht aus einem Hauptfenster,das als so genannter Assistent umgesetzt wurde. Assistenten bndeln einzelne Schritte ei-nes gesamten Ablaufs von zusammenhngenden Interaktionen in einem einzigen Fenster.Diese Schritte werden dann in einer bestimmten Reihenfolge zur Bearbeitung angezeigtund mit erklrenden Texten untersttzt. Im Fall von MapGENeric sind dies die ver-schiedenen Schritte, die zur Konguration des Systems fr eine bestimmte Anwendungnotwendig sind, wie Geodatenbank auswhlen, Konguration erstellen/bearbeiten, usw.(Abb. 6.2). Dieser Assistent wird im folgenden Kongurationsassistent genannt. Strukturund Funktionalitt der Autoren-Schnittstelle wird im folgenden durch die Kongurationvon MapGENeric fr das in Kapitel 4 eingefhrte Touristik/Umwelt-Beispiel beschriebenwerden.6.2.1 Geodatenbank whlenDer erste Schritt der Konguration dient dem Kartenautor zur Identizierung derjeni-gen Geodatenbank, aus der er Geodaten mit Hilfe von Visualisierungs-Regeln zu einerBildschirmkarte arrangieren mchte. Hier steht unter GeoDatabase ein Textfeld zurVerfgung, in dem der Pfad und der Dateiname der zu visualisierenden Geodatenbankeingegeben werden kann (Abb. 6.3). Ferner ist optional die Mglichkeit gegeben, einenBenutzernamen und ein Passwort einzugeben, wenn die Geodatenbank passwortgeschtztist. Die Geodatenbank kann auch komfortabel ber die Select-Taste ausgewhlt werden.Hierzu net sich eine so genannte DialogBox, die es erlaubt, im Dateisystem des Com-puters, auf dem MapGENeric ausgefhrt wird, nach der jeweiligen Geodatenbank (z.B.:TouristikUmweltGeoDB.mdb) zu suchen.Ein Klick auf Next veranlasst eine Prfung der Verbindung zur ausgewhltenGeodatenbank. Bei positivem Ergebnis werden eventuell vorhandene Kongurationsdatenber den Data Manager angefordert. Diese Kongurationsdaten werden im Hauptspei-cher gehalten, um sie den folgenden Komponenten zur Verfgung stellen zu knnen. Beierfolgreichem Abschluss des Kongurationsassistenten werden diese evtl. genderten oderergnzten Kongurationsdaten in diese Geodatenbank propagiert.80 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.2: Architektur der Autoren-Schnittstelle6.2 Autoren-Schnittstelle 81Abbildung 6.3: Kongurations-Assistent Datenbankauswahl6.2.2 Geoobjektklassen erstellen/bearbeitenIn Kapitel 4 und 5 wurde gezeigt, dass die Gruppierung von Geoobjekten, die gleichdargestellt werden sollen, an Hand gemeinsamer Attribute durch sogenannte Sichtenauf Datenbanken verwirklicht werden knnen. Diesen Geoobjektklassen knnen 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) mglich, fr jede Geoobjektklasseeine weitere DB-View zu denieren, die diese Eigenschaften reprsentiert. Diese knntenbeispielsweise Name und nungszeiten zu Museen sein.Vorhandene Geoobjektklassen werden unter Geoobjekt-Classes aufgelistet (Abb. 6.4).Werte einer ausgewhlten Geoobjektklasse aus dieser Liste werden unter Selected Geo-object-Class dargestellt. Zu diesen Werten gehren, wie bei der Modellierung in Kapitel4.4.1 dargestellt, Name, Basistyp, Sichtdenition fr Geoobjekte und Sichtdenition frderen Attribute (nichtgraphische Eigenschaften). Werden nderungen an diesen Wertenvorgenommen, so knnen diese ber die Save-Taste gesichert werden. Sollen neue Geo-objektklassen deniert werden, kann dies durch Klicken der New-Taste erfolgen, was zurFolge hat, dass die Eingabefelder unter Selected Geoobject-Class geleert werden und82 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.4: Kongurations-Assistent Geoobjektklassendarin neue Werte eingegeben werden knnen. Diese neue Denition kann durch Save ge-speichert werden und erscheint daraufhin in der Liste unter Geoobjekt-Classes. Bei derDenition der neuen Geoobjektklasse sind die bei der Modellierung erarbeiteten Integri-ttsbedingungen zu beachten. Beispielsweise sind Namen fr Geoobjektklassen eindeutigzu vergeben und Geoobjektklassen unterschiedlicher Basisklassen bedrfen verschiedenerSicht-Schemata. Beispielhaft folgt die Denition der Klassen fr Straenbahnhaltestellen,Straenbahnlinien und CO2-Belastung, wie sie auf den Karten in den Abbildungen 4.2,4.3 und 4.4 dargestellt sind. Diese Sicht-Denitionen basieren auf den Relationen, die imTouristik/Umweltbeispiel genutzt wurden (Kapitel 4.1.1).Die fr jede Basisklasse notwendigen Sicht-Schemata werden im folgenden durch diePrsentation von Beispielen fr diese drei Geoobjektklassen erlutert. Wie zuvor in Kapi-tel 4.4 erarbeitet, wird bei der Sicht-Denition auf den CREATE VIEW ...-Teil verzichtet.Dies ist mglich, da MapGENeric keine durch das DBMS verwaltete Sicht-Denition,wie im herkmmlichen Sinne bentigt. Vielmehr handelt es sich hierbei um systeminter-ne Sichten, die MapGENeric zur Gruppierung von Geoobjekten bentigt, denen durchVisualisierungs-Regeln einheitliche Darstellungsformen zugewiesen werden knnen.6.2 Autoren-Schnittstelle 83Fr die Gruppierung von Straenbahnhaltestellen zu einer solchen einheitlichen Dar-stellung werden durch die Add-Taste evtl. gefllte Eingabefelder geleert. Im Eingabefeldfr Name wird zunchst Straenbahnhaltestellen eingetragen und darauf folgend die Ba-sisklasse Punkt unter BaseType gewhlt. Fr punktfrmig darzustellende Geoobjektesind die Attribute Objekt_ID (id), Lngengrad (long) und Breitengrad (lat) notwendig.Um die graphische Darstellung dieser Geoobjekte auch beschriften zu knnen, ist einweiteres Attribut notwendig: Beschriftung (label). Um eventuelle Namenskonikte mitAttributen der GeoDaten zu vermeiden, wurde den Attributen mge_ frMapGENericvorgestellt. Im Eingabefeld Geoobjects-Class-View ist basierend auf Tabellen aus Kapi-tel 4.1.1 folgende Sicht-Denition einzugeben:SELECTid AS mge_id,laengengrad AS mge_long,breitengrad AS mge_lat,name AS mge_labelFROMStrassenbahnhaltestellenUm zuvor erwhnte nicht-graphische Eigenschaften der Geoobjekte auf Abruf darstel-len zu knnen, ist eine weitere Sicht-Denition notwendig. Dabei ist zu beachten, dass dieRelation zwischen dieser Sicht und der zuvor denierten Geoobjektklassen-Sicht durchdas gleiche Attribut id (mge_id) gewhrleistet ist, d.h., dass diese neue Attribut-Sichtmit einem Freumdschlssel auf die Geoobjektklassensicht zu denieren ist. Fr Attributedieser Geoobjektklasse sollte eine Sichtdenition im Eingabefeld Geoobject-Attributes-View, wie folgend eingetragen werden:SELECTid AS mge_id,'Name: ' , name,'Kapazitt: ', kapazitaet,'Linien #: ' , anzahl_linienFROMStrassenbahnhaltestellenUm diese Geoobjektklassen-Denition zu speichern, muss die Save-Taste bettigtwerden. Fr die Gruppierung der Straenbahnlinien ist erneut die Add-Taste anzuklickenund im Eingabefeld Name Straenbahnlinien einzutragen. Als Basistyp wird Liniegewhlt. Unter Geoobjects-Class-View wird folgende Sicht-Denition eingetragen:SELECTsbts.id AS mge_id,sbhs.laengengrad AS mge_long,sbhs.breitengrad AS mge_lat,sbts.max_speed AS mge_label,sbhs.id AS mge_seqposFROM84 Kapitel 6. Architektur und Funktionalitt von MapGENericStrassenbahnteilstrecke AS sbts,Strassenbahnhaltestellen AS sbhsWHEREsbhs.id = sbts.haltestelle_id1OR sbhs.id = sbts.haltestelle_id2An dieser Sicht-Denition ist zu sehen, dass ein weiteres Attribut fr die Darstel-lung von Linien eingeossen ist: mge_seqpos. Dieses Attribut dient bei linienfrmigenGeoobjekten zur korrekten Darstellung, da es die Richtung fr gerichtete linienfrmigeGeoobjekte deniert, und bei Linienzgen 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: Straenbahnlinien-Sicht-ErgebnisIn dieser Ergebnisrelation ist zu sehen, dass eine Linie durch zwei Zeilen deniertwird, die ihren Anfangs- und Endpunkt darstellen. Die zur korrekten Darstellung lini-enhafter Geoobjekte notwendige geordnete Folge von Punkten wird in diesem Beispielknstlich erzeugt, indem die Haltestellen-ID hierfr genutzt wird. Dies ist hier mglich,da die Haltestellen in der Relation in geordneter Reihenfolge stehen. Bei Geoobjekten,die in den darzustellenden Geodatenbanken als Linienzge modelliert sind, werden dieseGeoobjekte durch zwei oder mehr Zeilen deniert, je nachdem aus wievielen Punkten siebestehen. Dies wird bei der Denition der Geoobjektklasse fr CO2-Belastungen im nchs-ten Beispiel deutlich. Im folgenden wird ausschlielich die Sicht-Denition erlutert, dadas Prinzip der Geoobjektklassen-Denition durch die beiden vorangegangenen Beispieledeutlich geworden ist.SELECTumwb.id AS mge_id,vkoords.laengengrad AS mge_long,vkoords.breitengrad AS mge_lat,'' AS mge_label,koords.position AS mge_seqposFROMKoordinaten AS koords,Umweltbelastungen AS umwb,Verschmutzungskoordinaten AS vkoordsWHEREumwb.art = 'CO2-Konzentration'AND umwb.id = vkoords.umweltbelastung_idAND vkoords.koord_id = koords.id6.2 Autoren-Schnittstelle 85Wird diese Sicht-Denition auf die Relationen im Touristik/Umwelt-Beispiel angewandt,so entsteht eine Ergebnisrelation, in der CO2-Belastungen chenhaft durch mehrere Zei-len reprsentiert werden. Diese Zeilen wiederum denieren Punkte eines Linienzuges,der diese Flche begrenzt. Die Zusammengehrigkeit der Zeilen wird durch die gleichemge_id gewhrleistet. 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 Konguration rckwrts bewegen zu knnen. Dies kann er-forderlich sein, wenn der Kartenautor beispielsweise im vorangegangenen Schritt etwasvergessen hat. Wird diese Taste bettigt, hat das auch wie Next zur Folge, dass diebearbeiteten Felder durch den CongManager auf Integritt geprft und bei positivemErgebnis gespeichert werden.6.2.3 Darstellungsformen erstellen/bearbeitenUm Geoobjekte graphisch auf einer Bildschirmkarte zeichnen zu knnen, bentigt Map-GENeric Darstellungsformen, wie sie in Kapitel 4.4.1 modelliert wurden. Die Komponentedes Kongurations-Assistenten zum Erstellen und Bearbeiten solcher Darstellungsformenist in drei Bereiche unterteilt. Fr jede Basisklasse (Punkt, Linie, Flche) ist ein separaterBereich reserviert (Abb. 6.5). Sind Darstellungsformen bereits vorhanden, werden sie inder jeweiligen Liste angezeigt. Fr diese Listen werden die Funktionen Bearbeiten (Edit),Lschen (Delete) und Hinzufgen (Add) bereitgestellt. Fr jede Basisklasse werden dieseFunktionen in unterschiedlichen Fenstern angeboten, da sie unterschiedliche Darstellungs-variablen untersttzen mssen.Die fr das Touristik/Umwelt-Beispiel notwendigen Darstellungsformen sind in Abb.6.5 teilweise dargestellt. Beispielhaft folgt die Denition der Darstellungsformen fr dieim letzten Schritt (Step 2 of 5) erstellten Geoobjektklassen Straenbahnhaltestellen, 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 fr Punkt-Darstellungsformen net sich eine Eingabemaske,in der eine neue Darstellungsform fr punktfrmige Geoobjekte deniert werden kann.Die Funktionalitt dieser Eingabemaske soll im folgenden am Beispiel der Darstellungs-form eines hellblauen Kreises fr Straenbahnhaltestellen (siehe Beispielkarte in Abb.4.2) erlutert werden. Die Eingabemaske fr Punkt-Darstellungsformen bietet eine Tastefr die Farbauswahl, die durch einen Klick ein weiteres Fenster net, das einige vor-denierte Farben und Eingabefelder fr die Farbwerte rot, grn und blau bietet. Wirdin diesem Fenster beispielhaft eine hellblaue Farbe ausgewhlt, so kann dies durch dieOk-Taste besttigt werden, wodurch sich das Fenster fr die Farbauswahl schliet unddas Eingabefenster fr Punkt-Darstellungsformen in den Vordergrund tritt. Unter Vor-dernierte Formen bietet dieses Eingabefenster eine Auswahl an vordenierten Formen,Kreis, Dreieck, Rechteck, wie sie in Kapitel 4.2.1 gefordert wurde. Fr die Beispielde-nition der Straenbahnhaltestelle wrde aus dieser Auswahl der Kreis gewhlt werden.86 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.5: Kongurations-Assistent DarstellungsformenIn die Eingabefelder fr Breite und Hhe sollte der selbe Wert eingegeben werden, dadie Darstellungsform andernfalls eine elliptische Form annehmen wrde. Fr das Beispielwrde der Wert fnf gewhlt werden. Das Eingabefenster fr Punkt-Darstellungsformenbietet des weiteren einen Schieberegler fr die Transparenz der Darstellungsform an, derfr das Beispiel bei 255 beibehalten werden sollte. Das Eingabefeld fr ein Bitmap, durchdas punktfrmige Geoobjekte in MapGENeric auch dargestellt werden knnen, wrde indiesem Fall freigelassen werden. Sollten Haltestellen durch Bitmaps dargestellt werden,so msste in das Feld unter Bitmap ein Verzeichnispfad eingegeben werden der zu ei-nem Bitmap fhrt. Durch einen Klick auf Ok wird die Denition der Darstellungsformgespeichert, das Fenster geschlossen und die neue Darstellungsform in der Liste fr punkt-frmige Darstellungsformen dargestellt.Fr die Darstellungsform der Straenbahnlinien wird ber die Add-Taste unter lini-enfrmige Darstellungsformen eine andere Eingabemaske genet. Auf dieselbe Art wiezuvor wird die Farbe hellblau fr die Linie gewhlt und Transparenz bei 255 belassen. Frlinienfrmige Geoobjekte wurde zuvor bei der Modellierung gefordert, dass sie Pfeilspit-zen, Kreise oder Rechtecke fr Linienanfang und -ende erhalten sollten, um beispielsweiseEinbahnstraen, Sackgassen mit und ohne Wendemglichkeit darzustellen. Das Eingabe-fenster fr die Denition von Linien-Darstellungsformen bietet dies an in Form von je6.2 Autoren-Schnittstelle 87einer Auswahlbox fr den Anfang und das Ende der Linie. Fr das Beispiel werden sie aufden Standardeinstellungen belassen wie auch Linienmuster und -form. Fr die Darstellungder Eisenbahnstrecke im Touristik/Umwelt-Beispiel kann unter Linienmuster ein gestri-cheltes Muster gewhlt werden (siehe mittlere Spalte in Abbildung 6.5). Zuletzt muss eineLinienbreite festgelegt werden, die fr das Beispiel mit drei Pixeln ausreichend ist. Auchhier wird durch einen Klick auf Ok die neue Darstellungsform gespeichert und daraufhinin der zugehrigen Liste dargestellt.Die Darstellung der Umwelt-Belastungen ist eine chenfrmige Darstellungsform, dieber die Add-Taste fr chenhafte Darstellungsformen deniert werden kann. In dersich nenden Eingabemaske wird wie zuvor ber einen Farbbutton eine Farbe gewhlt(fr das Beispiel: schwarz). Die Transparenz wird auf 80 gestellt. Die Eingabeche frein Bitmap wird hierfr frei gehalten, ganz im Gegensatz zur Denition der Laub- undNadelwalddarstellung, fr die hier der Pfad zu einem Bitmap stehen muss. Um Grenzenvon chenhaften Geoobjekten deutlich machen zu knnen, ist unter Border eine Linieauszuwhlen, die um das chenhafte Geoobjekt gezeichnet werden soll. Hierzu werdenalle fr diese Geodatenbank denierten Linien-Darstellungsformen zur Auswahl in einerAuswahl-Box angeboten. Durch Ok wird die neue Denition bernommen und das Fens-ter geschlossen.Wenn fr jede Basisklasse mindestens eine Darstellungsform vorliegt, kann durch dieNext -Taste mit dem nchsten Schritt fortgefahren werden.6.2.4 Visualisierungs-Regeln erstellen/bearbeitenDer vierte von fnf Schritten des Arbeitens mit dem Kongurations-Assistenten ist dieRegel-Konguration. Komponenten der MapGENeric-Konguration, die in den vorange-gangenen Schritten deniert und bearbeitet werden konnten, knnen 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 ausgewhlt wird, erscheinen in der Eingabemaske VisRule-Denitionund knnen hier bearbeitet werden. Werden Werte einer Regel bearbeitet, so kann diesenderung 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-Denition geleert werdenund hier neue Werte ausgewhlt und eingetragen werden knnen. Die Denition einerneuen Visualisierungs-Regel beginnt mit ihrem Namen, die unter VisRules noch nichtvorhanden sein darf. Als nchstes muss die Geoobjektklasse, deren Geoobjekte dargestelltwerden sollen, ausgewhlt werden. Je nachdem welcher Basisklasse diese ausgewhlte Geo-objektklasse angehrt, werden unter Viewshape mgliche Darstellungsformen angezeigt,aus denen eine zu whlen ist. Mit Save wird die Denition einer neuen Visualisierungs-Regel abgeschlossen und gesichert.88 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.6: Kongurations-Assistent Visualisierungs-Regeln6.2.5 Kongurationen erstellen/bearbeitenIm Touristik/Umwelt-Beispiel ist der Wunsch entstanden, mehrere Kongurationen freine Geodatenbank erstellen zu knnen, so dass dieselben Geoobjekte nach Bedarf un-terschiedlich dargestellt werden knnen (Touristenkarte und Touristenkarte II). Um dieseFunktionalitt bieten zu knnen, ist die Denition und das Bearbeiten unterschiedlicherKongurationen im linken Teil der in Abb. 6.7 sichtbaren Eingabemaske unter Congu-ration mglich. Diese Eingabemaske bietet die Mglichkeit, Kongurationen 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 Kongura-tionen bentigt. Diese knnen im zweiten Schritt des Kongurations-Assistenten erstelltwerden. Dazu ist es ntig, 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. Fr das oben genannte Beispiel wre diese Aktion dreimal zu wiederholen, jeweilsfr Touristenkarte, Touristenkarte II und Umweltkarte. In Abb. 6.7 ist zu sehen, dassgerade die Konguration Umweltkarte erstellt wird. Falls die eine oder andere Kon-guration bereits fr die zuvor ausgewhlte Geodatenbank existiert, werden diese unter6.2 Autoren-Schnittstelle 89Abbildung 6.7: Kongurations-Assistent KongurationConguration aufgelistet. Bei Bedarf ist es mglich eine Konguration aus dieser Listeauszuwhlen und zu lschen (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 Kongurationen zugewiesen werden knnen, um zu vermeiden, dass fr verschiedenesich hnelnde Anwendungen auf derselben Geodatenbank dieselbe Regel mehrfach de-niert werden muss. Regeln die einer unter Conguration selektierten Kongurationzugewiesen sind, werden in der mittleren Liste unter Cong-VisRules aufgelistet. Frdie Zuweisung einer unter VisRules ausgewhlten Regel zu einer ausgewhlten Kongu-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 unerwnschte berlagerungen der Geoobjektevermeiden zu knnen. Diese Zeichenreihenfolge wurde fr Regeln abhngig davon, in wel-cher Konguration sie zum Einsatz kommen, deniert. Die Darstellung der Regeln erfolgtin der mittleren Liste (Cong-VisRules) in ihrer Zeichenreihenfolge. Die Position in derZeichenreihenfolge einer in der mittleren Liste ausgewhlten Regel kann durch die Upund Down-Tasten nach oben und unten verndert werden . Die oberste Regel in dieser90 Kapitel 6. Architektur und Funktionalitt von MapGENericListe mit einem Hkchen davor wird als erstes angewandt, dem weitere Regeln mit Hk-chen in der Liste folgen. Das vorangestellte Hkchen stellt die Sichtbarkeit dieser Regelin der jeweiligen Konguration dar, die bei neu zugewiesenen Layern automatisch gesetztwird.Um die Konguration von MapGENeric fr die unter Schritt 1 von 5 gewhlten Geo-datenbank abschlieen zu knnen, muss nur noch die Finish !-Taste bettigt werden.Daraufhin werden die auf diese Weise entstandenen Kongurationen in die jeweilige Geo-datenbank propagiert, sofern alle Schritte der Konguration erfolgreich waren.6.3 Nutzer-SchnittstelleDer Kartennutzer sollte die Karte so dargestellt bekommen, wie es vom Kartenautormit Hilfe des Kongurations-Assistenten bestimmt wurde. Wie bei der Konzeption derBildschirmkarte festgestellt, ist fr den Kartennutzer ebenfalls eine graphische Obercheerforderlich, um Layer ein- oder auszublenden, ihre Zeichenreihenfolge zu ndern, den dar-zustellenden Realwelt-Ausschnitt zu verndern und weitere Informationen zu bestimmtenGeoobjekten anzufordern (siehe Kapitel 4.2.2). Im folgenden sollen Struktur und Funk-tionalitt dieser Nutzer-Schnittstelle beschrieben werden. Der Begri Layer wird hierwieder eingefhrt und im weiteren genutzt fr die Gesamtheit der durch eine Regel de-nierten Reprsentations-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 DBzu erreichen. Ein Klick auf diesen Menpunkt 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 Kongurationenbeinhaltet, so werden diese Kongurationen zur Auswahl angeboten. Entscheidet sich derNutzer fr eine dieser Kongurationen, dann wird in Bereich B des Hauptfensters dieKarte mit dieser Konguration dargestellt. Die Darstellung der Karte kann der Nutzerauf unterschiedliche Weise beeinussen, wie bei der Modellierung von MapGENeric unterInteraktion gefordert wird. Zu diesen Interaktions-Mglichkeiten gehren Inforetrieval,Navigation, Zooming und Layermanipulation.6.3.1 LayoutBeim Layout der Nutzer-Schnittstelle wurden die Vorgaben aus Kapitel 4.2.2 berck-sichtigt. Bereich A lsst sich unterteilen in Zooming-, Info- und Layer-Abschnitte (Abb.6.9). Im Zooming-Abschnitt sind drei Schaltchen vorhanden, die aus zwei unterschied-lich groen Globen und einem gebogenen Pfeil zwischen diesen beiden bestehen. ImInfo-Abschnitt unter Coordinates ist Platz fr Lngen- und Breitengradwerte. DieseKoordinaten beziehen sich auf die Position des Mauszeigers ber der Karte in Bereich6.3 Nutzer-Schnittstelle 91Abbildung 6.8: Nutzer-SchnittstelleB. 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 Schaltchen bereit. In der Listesind Layer aufgefhrt, 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 mglich, diesen Layer auszuwhlen. Der ausgewhlte Layer wird angezeigt durch Hin-terlegen des Namens mit einem blauen Balken (siehe Layer Grnchen in Abbildung6.9). Vor den Layernamen sind jeweils Boxen mit und ohne Hkchen, die anzeigen, obder jeweilige Layer auf der Karte sichtbar ist oder nicht. Die drei Schaltchen unter derLayerliste dienen zur Layermanipulation und werden im zugehrigen Unterkapitel nhererlutert werden.Der wesentlich grere Bereich B dient zur Darstellung der Bildschirmkarte, derenVorgaben in dieser Arbeit durch Kartentitel, Mastab und Layerkonzept deniert wur-den (siehe Kapitel 4.2.2 - Layout). Der Kartentitel ist auf einer dunklen Flche ber dereigentlichen Karte dargestellt (im Beispiel Musterhausen-Touristenkarte). Der Karten-titel hat einen rein informativen Charakter. Der Mastab wird links unten auf der Kartedargestellt und verdeutlicht die Lnge, die der Mastab selber auf dem aktuell sichtba-ren Kartenausschnitt einnimmt. Das Layerkonzept reprsentiert die Bildschirmkarte, die92 Kapitel 6. Architektur und Funktionalitt von MapGENericAbbildung 6.9: Nutzer-GUI Bereich Adurch den Map Generator erstellt wird, indem Geoobjekte unter Bercksichtigung derVisualisierungs-Regeln auf verschiedenen Layern gezeichnet und diese wiederum aufein-andergelegt dargestellt werden. Um diese Bildschirmkarte herum ist ein Rahmen, der alsSchaltche fr die Navigation dient.6.3.2 InforetrievalInforetrieval bezeichnet die Mglichkeit, die dem Nutzer geboten wird, verschiedene nicht-graphisch dargestellte Informationen zu Geoobjekten auf der Karte anzufordern. DieseFunktionalitt steht durch einen Klick mit der rechten Maustaste auf die graphische Dar-stellung eines Geoobjekts im Bereich B auf der Karte zur Verfgung. Dabei ist zu be-6.3 Nutzer-Schnittstelle 93Abbildung 6.10: Nutzer-GUI Bereich Bachten, dass ausschlielich Geoobjekte angeklickt werden knnen, die gezeichnet sind aufdem Layer, der im Layer-Abschnitt von Bereich A ausgewhlt wurde. In Abbildung 6.9wren dies beispielsweise Geoobjekte auf dem Layer Grnchen. Wird mit der rechtenMaustaste auf die Karte geklickt, ohne vorher ein Layer gewhlt zu haben, erscheint einHinweisfenster mit der Auorderung dies nachzuholen.Der Begri Reprsentations-Objekt bezeichnet im folgenden die jeweilige graphischeDarstellung eines Geoobjekts aus der realen Welt innerhalb der Bildschirmkarte. WelcheReprsentations-Objekte anklickbar sind und welche nicht ist abhngig von der Kon-guration des Kartenautors. Generell sind alle Reprsentations-Objekte auf dem jeweilsausgewhlten Layer anklickbar.Punktfrmige GeoobjekteIm Touristik/Umwelt-Beispiel sind Straenbahnhaltestellen und Museen als punktfrmigeGeoobjekte der Realwelt mit einem Koordinatenpaar deniert. Wird die Beispielkongu-ration fr dieses Beispiel aus Kapitel 6.2 betrachtet, so ist beispielsweise festzustellen,dass die Visualisierungs-Regel fr die Darstellung von Straenbahnhaltestellen vorsieht,diese als blaue Kreise darzustellen. Mchte ein Nutzer z.B. weitere Informationen zu ei-ner bestimmten Haltestelle, so kann er in Bereich A den Layer Straenbahnhaltestellenwhlen und diese blauen Kreise mit der rechten Maustaste anklicken, vorausgesetzt der94 Kapitel 6. Architektur und Funktionalitt von MapGENericLayer ist sichtbar. Dies hat zur Folge, dass evtl. vorhandene Attribute (z.B.: Haltestellen-name) in einem separaten Fenster dargestellt werden. Die anklickbare Flche beschrnktsich dabei auf den dargestellten Kreis. Wird beispielsweise ein Pixel neben diesem Kreisangeklickt, ist keine Informationsdarstellung zu erwarten, weshalb bei der Kongurations-Denition darauf zu achten ist, nicht zu kleine Darstellungsformen zu erstellen. Die Greder Darstellungsformen sollte vom Kartenautor unter Bercksichtigung der Kartennutzerdeniert werden. Beispielsweise wren fr Kleinkinder und Menschen in hohem Alter be-sonders groe Darstellungsformen praktisch.Bei der Darstellung von punktfrmigen Geoobjekten durch Bitmaps, die ebenfalls mg-lich ist und im Touristik/Umwelt-Beispiel fr Museen angewandt wurde, ist der anklick-bare Bereich ein anderer. Die Darstellung von Museen ist im Unterschied zu Hotels die-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 knnte 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 vergrerte DarstellungDieses Phnomen lsst sich dadurch erklren, dass vordenierte Darstellungsformenwie Ellipse, Dreieck und Rechteck fr die Darstellung von punktfrmigen Geoobjektenals Vektoren dargestellt werden und tatschlich 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 Gebudes lediglichdurch den Einsatz von durchsichtigen Pixeln erreicht, die sozusagen den klickbaren Bereichmitdenieren.Linienfrmige GeoobjekteLinienfrmige Geoobjekte sind Realweltobjekte, die modelliert sind mit zwei oder mehrKoordinatenpaaren. Das Informationretrieval ber die Darstellung dieser Geoobjekte hngtauch von der Modellierung und Konguration des Kartenautors ab. Bei Geoobjekten, diedurch zwei Koordinatenpaare deniert werden (im Beispiel Straenbahnteilstrecken) undauf der Karte durch eine Linie dargestellt werden, ist es gleichgltig, wo auf dieser Liniegeklickt wird, die Information zu dieser Teilstrecke zu erwarten. Es knnte evtl. erwartetwerden, dass wenn auf eine der beiden Enden einer Linie geklickt wird, Informationenzu dem jeweiligen Punkt, der dieses Ende deniert, angezeigt werden. Auf eine solcheFunktionalitt wurde bewusst verzichtet, da die Konguration einer solchen Funktiona-litt fr den Kartenautor zu kompliziert werden wrde. Ferner muss eine solche Linie6.3 Nutzer-Schnittstelle 95nicht durch zwei Geoobjekte mit je einem Koordinatenpaar (z.B.: Straenbahnhaltestel-len) deniert sein, sondern knnte lediglich durch Koordinatenpaare deniert worden sein.Die gleiche Erwartung ist auch bei Zwischenpunkten von linienfrmigen Geoobjekten, diedurch mehr als zwei Koordinatenpaare deniert werden (Linienzge), denkbar, genausowie bei sich schneidenden Linien der Schnittpunkt. Falls diese Endpunkte, Zwischenpunk-te und Schnittpunkte eine besondere Bedeutung fr die Anwendung haben, mssen sie inder Geodatenbank als punktfrmige Geoobjekte modelliert vorliegen. Wenn dies der Fallist, knnen sie durch den Karten-Autor auch durch eine Visualisierungs-Regel besondershervorgehoben und somit anklickbar gemacht werden.Flchenfrmige GeoobjekteGrnchen im Touristik/Umwelt-Beispiel beispielsweise stellen chenfrmige Geoobjek-te dar. Die Flchen solcher Geoobjekte werden durch Linienzge begrenzt, die auch frihre Reprsentations-Objekte Form und Gre denieren. Um Informationen zu solchenGeoobjekten zu erhalten, ist es mglich, auf jede Stelle ihres Reprsentations-Objekts zuklicken und somit die Funktionalitt des Inforetrieval zu erhalten.6.3.3 NavigationDie Interaktions-Mglichkeiten der Nutzer-Schnittstelle lassen sich unterteilen in Infore-trieval und Kartenmanipulation (Navigation, Zooming und Layermanipulation). Die Kar-tenmanipulation kann als eine zweite Art der Konguration von MapGENeric betrachtetwerden. Der Unterschied zur Kongurationsmglichkeit des Kartenautors, die dauerhaftin der Datenbank gespeichert wird, ist der, dass die Konguration durch den Kartennutzeraktuelle Wnsche des Kartennutzers wiedergibt und Parameter fr die Kartengenerierungdurch den Map Generator in Echtzeit anpasst.Navigation ist die erste dieser Echtzeitkongurations-Arten. Aus Grnden der Ezienzwurde in Kapitel 4.2.2 die Entscheidung, welche Navigationsart umgesetzt werden soll,zugunsten der Rahmen-Navigation getroen. Diese Form der Navigation ist dem Nutzerber den Rahmen um die Karte in Bereich B mglich. 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 untersttzt acht Richtungen. Diese sind im Uhrzeigersinn: Nord, Nord/Ost, Ost,Sd/Ost, Sd, Sd/West, West, Nord/West. Wrde der Mauszeiger beispielsweise auf dierechte obere Ecke des Navigations-Rahmens bewegt werden, so wrde sich die Darstellungder Maus in einen Pfeil ndern, der von links unten nach rechts oben zeigt. Wrde nundie linke Maustaste bettigt, so wrde der Kartenausschnitt in diese Richtung bewegt,und die Karte neu gezeichnet.6.3.4 ZoomingDas Zooming ist aufzufassen als Vernderung des dargestellten Realweltausschnitts. Frdiese Funktionalitt stehen verschiedene Mglichkeiten zur Verfgung. Bei der ersten Dar-stellung der Bildschirmkarte nach Auswahl der Datenbank und der Konguration ist der96 Kapitel 6. Architektur und Funktionalitt von MapGENericRealweltausschnitt so gewhlt, dass alle darzustellenden Geoobjekte sichtbar sind. DerKartennutzer hat daraufhin die Mglichkeit, diesen Ausschnitt ber die beiden verschiedengroen Globen im Zooming-Abschnitt des Bereichs A (siehe Abbildung 6.9) zu verndern.Der kleine Globus dient zum herauszoomen, wobei der Realweltausschnitt vergrert wirdund dadurch die Darstellung verkleinert. Der groe Globus hat den gegenteiligen Eekt.Um komfortabel wieder zum ursprnglichen Realweltausschnitt zurckkehren zu knnen,dient der Pfeil unter diesen Globen.Eine weitere Mglichkeit ist gegeben durch das Markieren eines Ausschnitts auf derKarte selber. Dabei wird mit gedrckter 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) mglich.Beim Zooming ndern sich die durch die Visualisierungs-Regeln bestimmten Grenfr die Darstellungsformen nicht. Die Karte wird lediglich fr den neuen Realweltaus-schnitt mit den gleichen Darstellungsformen in den Visualisierungs-Regeln gezeichnet.Wird beispielsweise in die Karte hineingezoomt, so wird eine hhere Detaillierung derdargestellten Karte erreicht. Dies sei am folgenden Beispiel einer Deutschlandkarte ver-deutlicht, die lediglich Bahnhfe einiger Stdte als Punkte darstellt, und das Teilstck derAutobahn A3 innerhalb von NRW (siehe Abbildungen 6.12, 6.13, 6.14). Die Darstellungs-form fr Deutschland ist beige, die fr Bahnhfe ist schwarz mit 25 Pixel Durchmesser,und fr Autobahn ist die Darstellungsform eine schwarze Linie mit 10 Pixel Breite.Abbildung 6.12: GesamtansichtIn einem kleinen Mastab berdecken einige Darstellungsformen der Bahnhfe 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 Mastab ver-6.3 Nutzer-Schnittstelle 97Abbildung 6.13: Zoom 1 NRWAbbildung 6.14: Zoom 2 Kln und Umgebung98 Kapitel 6. Architektur und Funktionalitt von MapGENericgrert, so ist in der nchsten Abbildung 6.13 zu erkennen, dass die Bahnhfe nicht mehrauf der Autobahn liegen. Der Trugschluss, dass die Autobahn bis auf eine Biegung gradli-nig ist, ist in diesem Mastab 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 gendert haben, denndie Autobahn ist auf allen dreien noch immer 10 Pixel breit und die Kreise fr Bahnhfe25 Pixel.Wre diese Anwendung in der Datenbank noch detaillierter modelliert worden, bei-spielsweise Autobahnen und Bahnhfe als chenhafte Geoobjekte, so wrden diese Geo-objekte beim Hineinzoomen mitwachsen wie auch das chenhafte Geoobjekt Deutschlandin den Abbildungen.6.3.5 LayermanipulationEs ist dem Kartennutzer mglich, die Zeichenreihenfolge oder die Sichtbarkeit der einzel-nen Layer zu ndern. Diese Funktionalitt wird zur Verfgung gestellt, weil Kartenautorennicht wirklich fr jeden Nutzer eine eigene Konguration erstellen knnen. Jede Nutzer-gruppe, fr die ein Kartenautor Kongurationen erstellt, knnte weiter unterteilt werden.Diese Funktionalitten hingegen ermglichen es jedem Nutzer die Darstellung der Karteseinen persnlichen Wnschen anzupassen. Beispielsweise ist es im Touristik/Umwelt-Beispiel denkbar, dass auf einer Vergngungsmeile viele Restaurants und Cafs eng bei-einander liegen (siehe Abbildung 6.15). Ein Tourist knnte sich nun in der Layerlisteeine Rangfolge erstellen, in der er seine Fast-Food-Restaurantauswahl trit. Diese Rang-folge knnte so aussehen, dass er die Fast-Food-Kette Subway, dann Burger King undzuletzt McDonald`s bevorzugt. Nun wre es ihm neben dem optischen Vorteil auch mg-lich, einfacher auf das Symbol fr 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 Funktionalitt Sichtbarkeit einzelner Layer ndern zuknnen, wrde diesem Tourist mehr berblick auf der Karte verschaen, indem er dieLayer mit den unerwnschten Restaurants ausblenden knnte.Um die Zeichenreihenfolge der Layer ndern zu knnen, 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 frher gezeichnet werden als Layer weiterunten. Die auf diese Weise vernderte Karte wird bei jedem Klick neu aufgebaut, so dassder Eekt der Reihenfolgenderung in Echtzeit verfolgt werden kann.Vor den Layern in dieser Liste stehen CheckBoxes, die die Sichtbarkeit der jeweiligenLayer bestimmen. Ist ein Hkchen in einer solchen Box, so ist der Layer sichtbar, andern-falls ist er unsichtbar. Sind die Sichtbarkeiten bestimmt, kann der Kartennutzer ber dieRedraw-Taste veranlassen, dass die Karte nach seinen persnlichen Einstellungen neugezeichnet wird. Die Redraw-Taste liegt auf der rechten Seite unter der Layerliste.6.3 Nutzer-Schnittstelle 99Abbildung 6.15: Karten- und Layerausschnitt (vergrerte Darstellung)Bei der nderung von Sichtbarkeiten wurde auf eine direkte Darstellung des Ergebnis-ses (wie zuvor bei nderung der Zeichenreihenfolge) aus Ezenzgrnden verzichtet. Diedirekte Darstellung bei nderung der Zeichenreihenfolge ist mglich, 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 gelscht, so dass sie aufwendig neu gezeichnet werden mssen,wenn sie wieder eingeblendet werden. Da es aber oft vorkommen kann, dass mehrere aus-geblendete Layer eingeblendet werden sollen, wurde auf die Technik zurckgegrien, dassNeuzeichnung erst auf Anforderung erfolgt.Kapitel 7ImplementierungIn diesem Kapitel werden Teilprobleme der Implementierung von MapGENeric nhererlutert werden. Dazu wird die hierarchische Struktur von MapGENeric genutzt, umdie Detaillierung der Erluterungen zu erhhen bis in Codeebene. Dabei werden Kompo-nenten dargestellt, die bei der Modellierung und Implementierung eine besondere Stellungeingenommen haben, sei es die Funktionalitt oder die Architektur betreend. 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 Zeichenche, Abbildung der Realweltkoordinaten aufBildschirmkoordinaten und das Zeichnen der Reprsentations-Objekte interessant sind.7.1 Map GeneratorDer Map Generator ist die Hauptkomponente von MapGENeric, denn sie ist fr dasErstellen der Karte zustndig. Sie agiert zwischen der Datenbank-Schnittstelle und demNutzer der Anwendung. Diese Komponente ist fr die Regelverarbeitung und die Erstel-lung der daraus resultierenden Karte zustndig. Der Abbildung 7.1 ist zu entnehmen,dass Map Generator eine sequenziell arbeitende Komponente ist. Sie fhrt verschie-dene Schritte aus, die von einer Geodatenbank zu einer fertigen 2D-Bildschirmkarte inForm eines Bitmaps fhren. Die dazu ntigen Schritte knnen unterteilt werden in LadeKonguration (Conguration 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-dularitt ist beispielsweise die Projektions-Komponente beliebig austauschbar.Der Map Generator erwartet ber das Nutzer-GUI die Auswahl einer Geodatenbankmit Kongurationsdaten fr MapGENeric, wie in Kapitel 6.2 beispielhaft fr das Tou-ristik/Umwelt-Beispiel erstellt. Genauer erwartet nicht clsMapGenerator diese Geodaten-bank, sondern der DataManager ber den der Map Generator Kongurationsdaten aus derGeodatenbank anfordert. Zu diesen Daten gehren Kongurationen, Darstellungsformen,Geoobjektklassen-Denitionen und Visualisierungs-Regeln, die durch den DataManagerin systeminterne Strukturen umgewandelt und an Map Generator bergeben werden.1007.1 Map Generator 101Abbildung 7.1: Map GeneratorAnhand der ausgewhlten Konguration werden im nchsten 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 fr jede Visualisierungs-Regel erzeugt, die fr die aktu-elle Konguration als sichtbar deniert wurde. Dabei wird der Kartenausschnitt initialan Hand der eingelesenen Geoobjektkoordinaten bestimmt und deniert 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 fr Weltkar-tendarstellung eine chentreue Darstellung bietet. In der letzten Komponente (LayerGenerator) werden diese systeminternen Strukturen fr Geoobjekte auf Layern darge-stellt. Jeder Layer wird fr sich auf einem eigenen Bitmap gezeichnet. Zusammengelegtzu einem einzelnen Bitmap (in der durch die Konguration vorgegebenen Reihenfolge)stellen sie die Ausgabe des Map Generators dar.7.1.1 Conguration und Geoobject LoaderDie Konguration 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 Konguration zugewiesen102 Kapitel 7. ImplementierungAbbildung 7.2: Flussdiagramm fr Map Generator (1)sind. Um die durch den Kartennutzer gewhlte Konguration zu laden, greift Map Ge-nerator als erstes lesend ber die DB-Schnittstelle auf die Regeln zu, die der gewhltenKonguration zugewiesen sind.In Kapitel 6.3 wurde die Gesamtheit der Reprsentations-Objekte, der durch eineRegel denierten Geoobjekte als Layer bezeichnet. Dies wird im folgenden genauer spe-ziziert: Eine Regel bestimmt eine Menge von Geoobjekten, die durch eine bestimmteDarstellungsform dargestellt werden sollen. Die Beziehung, die Regeln mit einer Kongu-ration bilden, enthlt ihre Position in der Abarbeitungsreihenfolge und die Sichtbarkeitfr die jeweilige Konguration. Das in Kapitel 4.4.1 vorgestellte Anschauungsbild frLayer (Layer knnen angesehen werden als durchsichtige Folien, auf denen Geoobjekteder selben Klasse durch die gleiche Darstellungsform dargestellt sind. Diese Folien msseneine Position haben in der Reihenfolge in der sie bereinander gelegt werden.) fhrt beigenauer Betrachtung zu einer hnlichkeit mit Regeln, genauer noch zu der Erkenntnis,dass Regeln Layer denieren.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 gewnsch-ter Sichtbarkeit. Das liegt daran, dass die Sichtbarkeit von Regeln durch den Karten-autor initial vorgegeben, jedoch whrend der Programmlaufzeit durch den Nutzer vern-dert werden knnen. Dabei wird beim Laden der Konguration die gewnschte Sichtbar-keit mit dem Wert aus der Datenbank gesetzt. Zusammengefasst in einem clsLayerList-Containerobjekt werden diese clsLayer-Objekte dem zuvor instanziierten clsMap-Objektbergeben. An dieser Stelle kommt ein geordnetes Containerobjekt zum Einsatz, das dieLayer in der Reihenfolge speichert, in der sie gezeichnet werden sollen.7.1 Map Generator 103Als nchstes werden alle Darstellungsformen fr die drei Basisklassen Punkt, Linieund Flche 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. Fr einen schnellen Zugri werden diese Darstellungsformen in separaten Hashta-bellen (fr jeden Typ PunktDF, LinieDF und FlcheDF eine Hashtabelle) gespeichert,aus denen sie bei Bedarf an Hand ihrer IDs ausgelesen werden knnen. Diese Hashtabellenwerden auch dem clsMap-Objekt bergeben.Abhngig 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, wobeifr jede als sichtbar denierte Regel (clsLayer-Objekt) die Geoobjekt-Sichten ber dieDB-Schnittstelle ausgefhrt 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 zustzlichen Eigenschaften reprsentiert. 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 whlen, dass alle eingelesenen Geoobjekte dar-gestellt werden knnen, mssen die Eckkoordinaten bestimmt werden. Dazu werden beijeder Regel ber eine Methode die minimalen und maximalen Koordinaten der durchdiese Regel denierten Geoobjekte ermittelt. Dabei gilt die am weitesten links unten ste-hende Koordinate als minimale und die am weitesten rechts oben stehende als maximaleKoordinate. Die Lngen- und Breitengrade dieser zwei Koordinaten werden mit den zu-vor ermittelten verglichen. Wenn sich bei diesem Vergleich herausstellt, dass der Lngen-oder Breitengrad auerhalb 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 mglich, jederzeit wieder zu dem ursprnglichenRealweltausschnitt zurckzukehren, der alle eingelesenen Geoobjekte beinhaltet.7.1.2 Projection TransformerDas 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 spter weitere Projektionen implementiert und in MapGENericgenutzt werden knnen. 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 durchluft die convert-Methode alle in104 Kapitel 7. ImplementierungclsMap 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 fr Weltkarten eine -chentreue Darstellung liefert.7.1.3 Layer GeneratorDas clsMap-Objekt wird im nchsten 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 denierten 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 verndert 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 Grenangabe in Pixeln als Parametererwartet. Diese Grenangabe (Hhe x Breite) bezieht sich auf die Gre der zu generie-renden Bildschirmkarte. Die Layerliste in clsMap wird abgearbeitet, und fr jeden Layer,der als sichtbar deniert ist, wird ein leeres Bitmap erstellt. Weiter werden alle Geoobjek-te aus dem aktuellen Layer ausgelesen und abhngig vom Basistyp (Punkt, Linie, Flche)durch die jeweilige Methode drawPoints, drawLines oder drawAreas auf diesem leerenBitmap gezeichnet. Dazu mssen 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 mssen aus diesem Ko-ordinatensystem auf das Bitmap abgebildet werden. Hierzu wird fr jedes Geoobjekt dieFunktion world2screen aufgerufen, die diese einfache Umrechnung ausfhrt. Es gibt aucheine Funktion screen2world, die in die umgekehrte Richtung wandelt. Diese Funktion istntig, um von der Karte auf Realweltkoordinaten zurckschlieen zu knnen, beispiels-weise fr das Zooming durch Ausschnittwahl.Die Methoden zum Zeichnen der Geoobjekte werden abhngig 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 bentigt, 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 Gre, wie sie in der Darstellungsform deniert ist, auf dasaktuelle Layer gezeichnet. Ist dies jedoch nicht der Fall wird kontrolliert, ob eine vorde-nierte Form (Punkt, Dreieck, Quadrat) gewnscht ist. In diesem Fall wird das Objekt inder vordenierten Form gezeichnet. Wenn auch dieser Fall nicht zutrit, wird die vorde-nierte Form Punkt genutzt, um das Geoobjekt darzustellen. In den Fllen, in denen7.1 Map Generator 105Abbildung 7.3: Flussdiagramm fr Map Generator (2)vordenierte Formen genutzt werden, wird aus der Farbe, die in der Darstellungsformgespeichert ist, ein SolidBrush erstellt, mit dem die Geoobjekte gezeichnet werden. Auchbeim Zeichnen der vordenierten Formen wird die Gre in der Darstellungsform beachtet.Bei Linienobjekten ist die Denition 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 Flchenobjekten (hierzusiehe 3.2.3) genutzt werden. In VisualBasic ist es nur mit Pens mglich, Linien ein Muster(vgl. durchgehende, gestrichelte, gepunktete Linien in Kapitel 4.2.1) zu verleihen. Pensbieten auch die Mglichkeit, die geforderten Enden fr Linien zu gestalten, beispielsweisedurch eine Pfeilspitze fr Einbahnstraen.Flchenobjekte werden durch ihre Begrenzungspunkte deniert und knnen mit ei-ner Farbe oder einem Muster gefllt werden. Um ein Flchenobjekt mit einer Farbezu befllen, werden auch SolidBrushes angewendet. Ist jedoch in der ihr zugewiesenenDarstellungsform ein Musterbitmap deniert, so wird ein TextureBrush eingesetzt. Tex-tureBrushes nutzen Bitmaps zum Zeichnen oder Befllen der graphischen Objekte an106 Kapitel 7. Implementierungderen Zeichenmethode sie bergeben werden. Wenn zustzlich in der Darstellungsformgewnscht ist, dass die Flche durch eine Linie umrandet ist, wird die Methode fr Li-nienobjekte mit den gleichen Koordinaten fr die Flche aufgerufen. Die auf diese Weiseerstellten Layerbitmaps werden gespeichert und knnen ber eine weitere Methode (draw-Map) in der richtigen Reihenfolge bereinander auf einem endgltigen Bitmap gezeichnetwerden, der das Resultat der Anwendung des Map Generators darstellt.7.2 Module des Layer Generator7.2.1 Generierung der Zeichenche - LayerDer 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() fr jeden sichtbaren Layerin der Liste ein neues Layerbitmap erzeugt wird, auf dem wiederum die graphische Dar-stellung der Geoobjekte gezeichnet werden. Fr die Darstellung von Layern eignet sichdas GDI+ Objekt Bitmap. Wie auch das Layer-Modell sind Bitmap-Objekte durchsichtigdeniert und bieten eine Zeichenche. Fr jeden darzustellenden Layer wird folgenderCode wiederholt ausgefhrt:'neues Layerbitmap instanziierenDim layerBitmap As BitmaplayerBitmap = New Bitmap(width, height)'Zeichenflche des Bitmap-Objekts holenDim g As Graphicsg = Graphics.FromImage(layerBitmap)'get layer to drawDim layer As clsLayerlayer = map.layerList.item(i)Dim mapObjectList As ArrayListmapObjectList = layer.mapObjectsDim mapObject As clsMapObjectFor Each mapObject In mapObjectListDim coordinates(mapObject.coordList.Length - 1) As PointFmapObject.copyCoordList(coordinates)For ir As Integer = 0 To coordinates.Length - 1' map realWorldCoordinates to screencoordinates(ir) = world2screen(coordinates(ir))Next7.2 Module des Layer Generator 107Select Case mapObject.geoObjectBaseClassCase clsMap.enumGeoObjBaseClass.AREAdrawAreas(coordinates, mapObject.viewshapeID, g)Exit SelectCase clsMap.enumGeoObjBaseClass.LINEdrawLines(coordinates, mapObject.viewshapeID, g)Exit SelectCase clsMap.enumGeoObjBaseClass.POINTdrawPoints(coordinates, mapObject.viewshapeID, g)End SelectNextAuf der Zeichenche des jeweiligen LayerBitmap sollen die Geoobjekte der realenWelt abgebildet werden. Die Zeichenche 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 Zeichenche. Dabei ist diese Trans-formation nicht mit der Projektion zu verwechseln, die geographische Koordinaten derdreidimensionalen Erdoberche 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 verflscht werden, werden sie fr dieseTransformation kopiert (mapObject.copyCoordList(coordinates), siehe Code zuvor). Ei-ne Verflschung in den den internen Strukturen wrde nach sich ziehen, dass fr jedeDarstellungsnderung durch Zooming, Navigation oder hnlichem die Daten erneut ausder Geodatenbank ausgelesen werden mssten. Da diese Transformation ausschlielichim Layer Generator genutzt wird, ist sie als eine Methode der Klasse clsLayerGeneratorumgesetzt worden, dessen Notwendigkeit und Architektur im folgenden an einem Beispielerlutert werden soll.7.2.2 World To Screen - KoordinatentransformationIm 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. Wrden nun die Koordinaten derPunkte aus dem linken Bereich 1:1 auf den rechten Bereich bertragen, so wre dies indiesem Fall zwar mglich, jedoch wre die Darstellung sehr klein. Wre der Wertebereichder darzustellenden Welt grer als die der Flche, auf der abgebildet werden soll, sowrden viele Punkte nicht dargestellt werden knnen. Aus diesen Gegebenheiten folgtdie Notwendigkeit einer Funktion, die Koordinatenwerte aus der darzustellenden Ebene(Realweltausschnitt) in die Ebene transformiert, auf die abgebildet werden soll (Bitmap-108 Kapitel 7. Implementierungzeichenche). Von einer Ebene kann in beiden Fllen 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: ZeichencheUm eine chenfllende Abbildung des Realweltausschnitts (Abb. 7.4 grn umrandeteFlche) auf der Zeichenche (Abb. 7.5 grn umrandete Flche) zu erhalten, muss ein Fak-tor ermittelt werden, mit dem Koordinaten von Geoobjekten aus dem Realweltausschnittmultipliziert die entsprechenden Koordinaten im Koordinatensystem der Zeichencheergeben. Diese Funktionalitt nennt sich Skalierung. Ein solcher Faktor kann aus der Di-vision der Breite der Zeichenche durch die Breite des abzubildenden Ausschnitts frdie X-Achse und aus der Division der Zeichenchen-Hhe durch die Ausschnitts-Hhefr die Y-Achse gewonnen werden. Aus den beiden Abbildungen 7.4 und 7.5 ist leichtersichtlich, dass das Seitenverhltnis der beiden Bereiche ungleich ist. Der Realweltaus-schnitt hat ein Seitenverhltnis von 7:4 und die Zeichenche 4:3. Soll nun der gesamteRealweltausschnitt die gesamte Zeichenche ausfllen, sind fr die beiden Achsen X undY unterschiedliche Faktoren notwendig:Breite ZeichenflacheBreite Realweltausschnitt=8007= 114, 29...Hohe ZeichenflacheHohe Realweltausschnitt=6004= 150Oensichtlich fhren unterschiedliche Faktoren zu Verzerrungen der Realitt in der Dar-stellung. Aus diesem Grund ist es erforderlich, sich fr einen dieser Faktoren zu entschei-den. Fllt die Entscheidung zugunsten des greren Faktors, d.h. im Beispiel fr denFaktor der Y-Achse, so wird die abzubildende Flche grer als die Zeichenche. Da-durch wrden Punkte wie P(7,8|5) auerhalb des sichtbaren Bereichs der Zeichenche7.2 Module des Layer Generator 109gezeichnet. Sinnvoller ist daher die Wahl des jeweils kleineren Faktors.Ein weiteres Problem ergibt sich aus der Mglichkeit, Realweltausschnitte frei whlenzu knnen. Wrde der Faktor mit den Koordinatenwerten der realen Wert multipliziert, sowrde beispielsweise der Punkt P(7,8|5) noch immer auerhalb des sichtbaren Bereichs ge-zeichnet (in Abb. 7.5 rot dargestellt). Das hngt damit zusammen, dass der Ursprung (0|0)des Ausschnitts nicht mit dem der Zeichenche 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 (RR) stammen und die Zeichen-che aus der Menge des Kartesischen Produkts der positiven natrlichen Zahlen (N N),d.h. es muss aus der Menge der reellen Zahlen in die Menge der positiven natrlichen Zah-len transformiert werden. Die Funktion hierfr soll im folgenden an Hand der X-Achseerlutert werden. Es gibt drei Mglichkeiten, wie der darzustellende Bereich (D-Bereich)deniert sein kann, wobei uG R die untere Grenze des D-Bereichs darstellt und oG Rdie obere Grenze:1. uG < 0 und oG < 02. uG < 0 und oG 03. uG 0 und oG 0Im 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 Eekt kannerreicht werden, wenn diese Distanz und die Punkt-Koordinate addiert werden.Abbildung 7.6: Achsenkorrektur - Fall 1Im zweiten Fall kann ebenfalls durch eine Addition der Distanz zur Punkt-Koordinatedie ntige 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 fr die Y-Achse und zusammen fr die Ebene immathematischen Sinne. In Ebenen erfolgt die Bestimmung eines rechteckigen Ausschnittsdurch zwei gegenberliegende Eckpunkte dieses Ausschnitts. In RR ist es sinnvoll dieseEckpunkte so zu whlen, dass sie die linke untere Ecke und die rechte obere Ecke de-nieren. Auf diese Weise deniert der linke untere Eckpunkt (LeftBottomCorner - lbc)110 Kapitel 7. ImplementierungAbbildung 7.7: Achsenkorrektur - Fall 3fr alle darzustellenden Punkte die untere Grenze ihrer X- und Y-Koordinaten, wohin-gegen der obere rechte Eckpunkt (RightUpperCorner - ruc) ihre obere Grenze deniert.WorldVisRange bezeichne im folgenden den darzustellenden Realweltausschnitt, wPointeinen Punkt aus diesem Ausschnitt und sPoint die Entsprechung des wPoints auf der Zei-chenche. Dann lsst sich der achsenverschobene sPoint in der Ebene folgendermaenberechnen:sPoint.X = wPoint.X WorldV isRange.lbc.XsPoint.Y = wPoint.Y WorldV isRange.lbc.YDurch diese einfache Funktion werden alle drei Flle abgedeckt. In den ersten beidenFllen, 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 oensichtlich gegeben ist. Der Faktor fr die Skalierung(scaleFactor) erfordert folgende Berechnungen, um in obiger Funktion eingesetzt werdenzu knnen (D-Bereich als dRange, Funktion Min(x,y) zur Bestimmung der kleineren Zahlvon x und y, zWidth und zHeight fr die Breite und Hhe der Zeichenche):dRange.Width = WorldV isRange.ruc.X WorldV isRange.lbc.XdRange.Height = mWorldV isRange.ruc.Y mWorldV isRange.lbc.YscaleFactor = Min(zWidthdRange.Width,zHeightdRange.Height)Werden die X- und Y-Koordinatenwerte von sPoint mit scaleFactor multipliziert, soentsteht die gewnschte Abbildung der Koordinatenpaare aus dem darzustellenden Real-weltausschnitt in die Zeichenche. Eine Eigenart, die GDI+ mitbringt und in Abbildung7.5 zu sehen ist, wurde jedoch in den bisherigen Lsungen nicht bercksichtigt. GDI+deniert den Ursprung auf Zeichenchen links oben. Bei der bisher erarbeiteten Funkti-on wrde somit eine horizontal gespiegelte Darstellung auf der Zeichenche folgen. Umauch diese Fehldarstellung zu korrigieren, reicht es, den Y-Wert jeweils von der Hhe derZeichenche abzuziehen, so dass endgltig folgende Funktion in Codeform resultiert:7.2 Module des Layer Generator 111Private Function world2screen(ByVal wPoint As PointF) As PointF'ermittle Ausschnitt-GreDim dRange.Width As Single = mWorldVisRange.ruc.X - mWorldVisRange.lbc.XDim dRange.Height As Single = mWorldVisRange.ruc.Y - mWorldVisRange.lbc.Y'berechne beide Faktoren und whle den KleinerenDim scaleFactor As Single = Math.Min((zWidth / dRange.Width, zHeight / dRange.Height)Dim sPoint As New PointFsPoint.X = ((wPoint.X - mWorldVisRange.lbc.X) * (scaleFactor))sPoint.Y = (((wPoint.Y - mWorldVisRange.lbc.Y) * (scaleFactor)) * -1) + zHeightReturn sPointEnd Function7.2.3 Zeichnen der Reprsentations-ObjekteDas Zeichnen der Geoobjekte erfolgt abhngig 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 bentigen, 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 Lngengrad. Wie zuvor erlutert,wird dieses Koordinatenpaar durch die Methode world2screen(...) umgewandelt in einKoordinatenpaar, das einen Punkt auf der Zeichenche des LayerBitmaps reprsentiert.Damit gezeichnet werden kann, bentigt die Methode jedoch neben dem Koordinatenpaardie Zeichenche, auf der gezeichnet werden soll, und die Darstellungsform, durch die dasObjekt dargestellt werden soll. In Kapitel 4.2.1 wurde fr die Darstellung eines punkthaftmodellierten Geoobjekts ein Bitmap oder ein vordeniertes graphisches Objekt vorgese-hen. Ist die der Methode bergebene Darstellungsform deniert durch ein Bitmap, wirdauf der Zeichenche dieses Bitmap durch die GDI+interne Methode der ZeichenchenDrawImage gezeichnet.Private Sub drawPoints(ByRef coords As PointF(), _ByRef viewshapeID As Integer, _ByRef g As Graphics)If coords.Length > 0 ThenDim myViewshape As clsViewshapePoint = _CType(mMap.viewshapePointList.Item(viewshapeID), clsViewshapePoint)'center pointIcon to pointCoordinates and draw imageIf Not myViewshape.getBitmap Is Nothing Theng.DrawImage(myPen.getBitmap, _New PointF(coords(0).X _- CType((myViewshape.getBitmap.Width / 2), Single), _coords(0).Y _- CType((myViewshape.getBitmap.Width / 2), Single)))Else...112 Kapitel 7. ImplementierungDie 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. Frdiese Korrektur wird ermittelt, wie die Ausmae des Bitmaps sind, und das Bitmap wirdum die Hlfte dieser Ausmae versetzt gezeichnet (siehe Codeabschnitt zuvor).Ist die Darstellungsform jedoch nicht deniert durch ein Bitmap, so wird geprft,ob der Alpha-Kanal der in der Darstellungsform gespeicherten Farbe grer ist als 0.Denn wre der Alpha-Kanal 0, dann wre das zu zeichnende graphische Objekt absoluttransparent und somit nicht sichtbar. Auf das Zeichnen eines unsichtbaren Objekts kannverzichtet werden, weshalb eine solche berprfung direkt zu Beginn durchgefhrt wird.Abhngig vom Typ der Darstellungsform (siehe 4.2.1 - vordenierte 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 fr ein dreieckiges Objekt keine spezielle GDI+-Methode existiert,wird die Methode fr Polygone genutzt. Dazu werden drei Eckpunkte fr ein Dreieck miteiner Gre, wie sie in der Darstellungsform deniert 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 ThenDim myBrush As SolidBrush = New SolidBrush(myViewshape.colorARGB)Select Case myViewshape.getPointTypeCase myViewshape.PointType.Rectangle'center pointIcon to pointCoordinatesDim 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 triangleDim tmpPointsTriangle(2) As PointF' topcornertmpPointsTriangle(0) = _New PointF(coords(0).X, _coords(0).Y - CType((myViewshape.getHeight / 2), Single))' leftcornertmpPointsTriangle(1) = _New PointF(coords(0).X - CType((myViewshape.getWidth / 2), Single), _coords(0).Y + CType((myViewshape.getHeight / 2), Single))7.2 Module des Layer Generator 113' rightcornertmpPointsTriangle(2) = _New PointF(coords(0).X + CType((myViewshape.getWidth / 2), Single), _coords(0).Y + CType((myViewshape.getHeight / 2), Single))'draw triangleg.FillPolygon(myBrush, tmpPointsTriangle)Case Else'center pointIcon to pointCoordinatesDim 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 SelectEnd 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 SubdrawLines(...)Linienhaft modellierte Geoobjekte bentigen mindestens zwei Koordinatenpaare, die ih-re Lnge denieren. 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 Zeichenche gezeichnet wird:Private Sub drawLines(ByRef coords As PointF(), _ByRef viewshapeID As Integer, _ByRef g As Graphics)Dim myViewshape As clsViewshapeLine = _CType(mMap.viewshapeLineList.Item(viewshapeID), clsViewshapeLine)If coords.Length > 1 And myViewshape.colorARGB.A > 0 ThenDim drawingPen As Pen = New Pen(myViewshape.colorARGB)drawingPen.DashStyle = myViewshape.dashStyledrawingPen.StartCap = myViewshape.startLineCapdrawingPen.EndCap = myViewshape.endLineCapdrawingPen.DashCap = myViewshape.dashCapdrawingPen.Width = myViewshape.getWidthg.DrawLines(drawingPen, coords)End IfEnd SubDie DrawLines-Methode wurde hier eingesetzt, da bei der Modellierung kein Unter-schied gemacht wurde zwischen Linien und Linienzgen (siehe Kapitel 4). Um das lini-enhafte Objekt zeichnen zu knnen, bentigt die DrawLines-Methode ein sogenanntesPen-Objekt, womit die Linie gezeichnet werden soll. Linien lassen sich ausschlielich mitdiesem Objekt zeichnen, das mehr Eigenschaften bietet und den ermittelten Bedrfnissenfr die Darstellung linienhaft modellierter Geoobjekte gengt. Diese Eigenschaften zurGestaltung der Farbe (.colorARGB), Gre (.Width), Form (.DashCap), Muster (.Das-hStyle) und Richtung (.StartCap / .EndCap) werden gesetzt durch die entsprechenden114 Kapitel 7. ImplementierungEigenschaften der in dieser Arbeit modellierten Darstellungsformen fr 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 ausgefhrt:If coords.Length > 1 And myViewshape.colorARGB.A > 0 Then...End IfUm eine falsche Darstellung von linienhaften Geoobjekten zu vermeiden, die durchmehr als zwei Koordinatenpaare deniert sind, mssen 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 fr sinnvoll erachtet, Flchendarzustellen durch eine Farbfllung, Texturfllung oder Umrandung. Dabei sollen dieseFllungen sich nicht gegenseitig ausschlieen, sondern miteinander kombinieren lassen. Beider Kombination ist auch eine feste Reihenfolge sinnvoll, die einzuhalten ist: 1. Farbfl-lung, 2. Texturfllung und 3. Umrandung. Diese Reihenfolge ergibt sich aus den folgendenberlegungen: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 Koordinatenpaaredeniert ist, mit diesem Stift dargestellt werden, so erfolgt dies durch eine zentrierteVerbindung dieser beiden Koordinatenpaare, d.h. ist dieser Stift beispielsweise zehn Pixelbreit deniert, so liegen fnf dieser Pixel auf der einen Seite der Linie und fnf auf deranderen Seite.Private Sub drawAreas(ByRef coords As PointF(), _ByRef viewshapeID As Integer, _ByRef g As Graphics)If coordinates.Length > 2 ThenDim myViewshape As clsViewshapeArea =CType(mMap.viewshapeAreaList.Item(viewshapeID), clsViewshapeArea)If myViewshape.colorARGB.A > 0 ThenDim myBrush As SolidBrush = New SolidBrush(myViewshape.colorARGB)g.FillPolygon(myBrush, coords, Drawing2D.FillMode.Alternate)End IfIf Not myViewshape.getBitmap Is Nothing ThenDim myTextureBrush As TextureBrush = New TextureBrush(myViewshape.getBitmap)g.FillPolygon(myTextureBrush, coords, Drawing2D.FillMode.Alternate)End IfIf Not myViewshape.border Is Nothing Then ' myViewshape.border includesdrawLines(coords, myViewshape.border, g) ' a viewshapeLineIDEnd IfEnd IfEnd Sub7.2 Module des Layer Generator 115Eine Flche wird in GDI+ deniert durch eine Grenzlinie, die durch eine geordneteFolge von Koordinatenpaaren deniert wird. Die Darstellung einer solchen Flche durcheine Farbfllung kann beschrieben werden durch die Vorstellung, dass ein Eimer Farbe indiese Flche gegossen wird, und diese Farbe an der Grenzlinie nicht nach Auen ieenkann. Genauso ist auch die Texturfllung nur bis zu dieser Grenzlinie mglich. Angenom-men diese Grenzlinie wrde durch ein Pen-Objekt gezeichnet und daraufhin erst die Flchedurch eine Farb- oder Texturfllung dargestellt werden, so wrde die zuvor gezeichneteGrenzlinie bis zur Hlfte ihrer Breite berdeckt werden. Dies war der Anlass dafr, dieUmrandung erst als letztes zeichnen zu lassen. Die Kombination einer Umrandung vonFlchen mit ihrer Fllung ergibt sich aus der berlegung, dass gleichartige Flchen (bei-spielsweise Bundeslnder der BRD) nicht unterscheidbar wren, wenn eine Anwendungverlangen wrde diese in einer einheitlichen Farbe oder einem einheitlichen Muster dar-zustellen. Durch eine Umrandung der Flchen wrden Grenzen sichtbar gemacht werdenknnen, so dass die Flchen wieder unterscheidbar wrden.Der Grund fr die Darstellung einer Texturfllung erst nach einer Farbfllung ist, dasssich dadurch weitere Mglichkeiten ergeben. Da fr die Textur Bitmaps zugelassen sind,die auch transparente Bereiche aufweisen drfen, ist es sinnvoll die Flche erst mit einerFarbe zu befllen und spter das teilweise transparente Muster darber zu legen. Dadurchknnen Anwendungen genge getan werden, die dasselbe Muster ber verschieden gefrbteFlchen darstellen mchten, um beispielsweise bundeslandbergreifende Gegebenheitendarzustellen.Kapitel 8Zusammenfassung und Ausblick8.1 ZusammenfassungZiel dieser Arbeit war es, einen generischen 2D-Kartengenerator auf Basis relationalerGeodatenbanken zu entwerfen und zu implementieren, der unabhngig von Datenbank-schema und DBMS arbeitet. Dazu notwendige Grundlagen aus der Geographie und derInformatik wurden ausgewhlt und erlutert im Hinblick auf eine zeit- und technologiege-me 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 untersttzt. 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 ausschlielich die Anbin-dung von Microsoft R Access exemplarisch implementiert wurde. Jedoch wurde das Ge-samtsystem so entworfen, dass es einfach mglich ist, Schnittstellen fr weitere DBMS zuimplementieren. Dies wurde durch einen komponentenbasierten Entwurf ermglicht.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 reprsentierte. Notwendige Darstellungsvariablenzur Darstellung von Geoobjekten wurden intensiv diskutiert. In dieser Diskussion konntenKombinationen von Darstellungsvariablen fr jede Geoobjekt-Basisklasse (Punkt, Linieund Flche) identiziert werden, anhand derer eine mglichst hohe Darstellungsvielfalterreicht wurde, die wiederum die Darstellungsmglichkeiten 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 herkmmlichenProgrammen genutzt wird (gelbe Linie mit je einer dnneren roten Linie auf beiden Sei-ten), nicht mglich ist. Auf solche Darstellungsmglichkeiten 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.1168.1 Zusammenfassung 117Grundlage einer weiteren Diskussion war die Darstellung von Bildschirmkarten mitihren Randangaben und ihren Funktionalitten bzw. Interaktionsmglichkeiten, die beider Entwicklung eines Kartengenerators fr ein solches System beachtet werden mssen.Dabei wurden zu entwickelnde Randangaben und Funktionalitten bestimmt, wie Karten-titel, Mastab, Zooming, Navigation und mehr, die in die Implementierung eingeossensind.In diesen Diskussionen wurde festgestellt, dass drei Komponenten bei der Kartenge-nerierung existieren: Gruppierung hnlicher Geoobjekte (Klassikation), 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 bezglich Dyna-misierungsmglichkeiten diskutiert. Dabei wurden Strken und Schwchen verschiedenerMglichkeiten ermittelt und dargestellt. Die Zusammenfhrung der einzeln ermitteltenDynamisierungsmglichkeiten wurde durch ein regelbasiertes Modell erreicht. Dies warmglich, weil eine ausschlielich automatische Klassikation von Geoobjekten grundstz-lich auszuschlieen ist, so dass ein Akteur (Kapitel 4.4) notwendig wird, der Geoobjektebestimmt und ihre Darstellungsformen deniert. Bei der Erstellung von analogen Kartensind hierfr Kartographen bzw. Kartenautoren zustndig, deren redaktionelle Arbeit undKreativitt die Gte 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 fr 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 mglichGeoobjektklassen aus Geodatenbanken zu denieren, deren Schema dem MapGENeric-System nicht bekannt ist, die Darstellungsform dieser Geoobjektklassen zu denieren undsie einander zuzuordnen. Des weiteren wurde es ermglicht mehrere VM-Regeln zu ei-ner Konguration des Systems zu bndeln, so dass mit unterschiedlichen Kongurationenverschiedene Anwendungen auf derselben Geodatenbank mglich sind. Dazu war es not-wendig eine Regelsprache zu denieren, die diese Eigenschaften ermglicht und somit diedrei identizierten Komponenten elegant zusammenfhrt.Ein Schwerpunkt bildete bei der Regelsprache die Klassikationskomponente, die frdie Gruppierung von Geoobjekten notwendig ist. Da diese unabhngig von Datenbank-schema und Datenbanksystem zu sein hatte, wurde nach einer Mglichkeit gesucht, diedurch den Groteil existierender Datenbanksysteme untersttz wird. In SQL wurde eineeinfache jedoch sehr eektive Lsung gefunden, die von den meisten DBMS untersttztwird. Basierend auf Sichtdenitionen in SQL, wurde die Regelsprache so deniert, dasses mit ihr mglich ist, eine Klassikation durch Denition einer Sicht auf Geoobjekte zuverwirklichen. Diese Sichtdenitionen mssen ein bestimmtes Schema haben, damit Map-GENeric die fr die Darstellung der Geoobjekte notwendigen Geometriedaten erhlt.118 Kapitel 8. Zusammenfassung und AusblickFr 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 knnen. Dies ist ebenfalls mglich mit einer weiteren Sichtdenition, diedieselbe Menge der Geoobjekte deniert, wie die Sichtdenition zur Klassikation, jedochin ihren Spalten nicht-graphische Eigenschaften zu diesen Geoobjekten enthlt. Map-GENeric kann auf diese Sicht eine SQL-Anfrage mit der ID des ausgewhlten Geoobjektsstellen und erhlt die durch diese Sicht denierten nicht-graphischen Eigenschaften.Eine der Komponenten, die durch die Regelsprache mitbedacht werden musste, ist dieDenition der Darstellungsformen fr die jeweiligen Geoobjekte. In den vorangegangenenDiskussionen ausgearbeitete Kombinationen von Darstellungsvariablen, die fr die Dar-stellung der Geoobjekte einer Basisklasse dienen, mussten in diese Regelsprache mitinte-griert werden. Die Regelsprache mit den zuvor genannten Eigenschaften wurde abkrzendVRL genannt und ihre Grundkonzepte anhand eines ER-Diagramms nher erlutert. Diestrug zum besseren Verstndnis der Beziehungen zwischen den Sprachelementen bei, diedaraufhin formal durch die BNF-Notation deniert wurden.Nachdem fr MapGENeric notwendige Komponenten modelliert worden sind, wur-de eine Gesamtarchitektur fr MapGENeric vorgestellt, die zu implementieren war. Indieser Gesamtarchitektur wurde der Kartengenerator als zentrale Komponente model-liert. Um die Leistungsfhigkeit des Kartengenerators darstellen zu knnen, wurde einegraphische Nutzer-Schnittstelle implementiert. Diese bietet die Funktionalitten, die voneinem modernen System zur Darstellung von Bildschirmkarten erwartet werden kann. Siestellt neben der Bildschirmkarte ihren Kartentitel und ihren Mastab dar. Des weiterenermglicht sie verschiedene Manipulationen an der Kartendarstellung, durch Zooming,Navigation, Ein-/Ausblendemglichkeiten der Layer. Weiterreichende Informationen ne-ben der Karte stellt sie ebenfalls dar, wie Realweltkoordinaten der Mausposition auf derKarte und zuvor erwhnte nicht-graphische Eigenschaften zu einem Geoobjekt auf Anfor-derung des Nutzers per Mausklick.Um eine komfortable Eingabe der VM-Regeln bieten zu knnen wurde auch eineSchnittstelle fr Kartenautoren implementiert. Diese bietet durch untersttzende Hil-festellungen textueller Form zu allen Elementen des VRL (Visualisierungs-Regelsprache)eine intuitiv zu bedienende Eingabemaske. Schritt fr Schritt ist es dem Kartenautordadurch mglich, Kongurationen fr verschiedene Anwendungen auf derselben Geoda-tenbank zu erstellen. Dabei wurden alle syntaktischen und semantischen Restriktionen desVRL bercksichtigt, so dass bei Fehleingaben erluternde Fehlerhinweise darauf hinweisen.Bei der Modellierung der Hauptkomponente des MapGENeric, dem Kartengenerator,wurde, wie auch bei der Gesamtarchitektur, groen Wert darauf gelegt, diese Modular zugestalten, so dass diese im Nachhinein durch evtl. leistungsfhigere Module ausgetauschtwerden knnen. Zu diesen Modulen gehren, Conguration 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 119In 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 erlutert. Da jedoch fr 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 fr die Generierung der Layer und der darauf gezeichnetenReprsentations-Objekte zustndig, 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 ausgeschpften technologischenSpektrums von ADO.NET bei der Schnittstellen- und Kartenautor-GUI-Implementierungverzichtet werden.8.2 AusblickDiese 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 fr 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 wre es wnschenswertin einem Bahnnetz einen Bahnhof anklicken zu knnen, 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 aufgezhlt: Krzeste Wege in einem Netzwerk Liegt ein Punkt auf einer Geraden? Liegt ein Punkt in einer Flche oder auerhalb? Wie gro ist die Flche? Wie weit sind zwei Punkte voneinander?120 Kapitel 8. Zusammenfassung und AusblickWenn die Darstellung einer Bildschirmkarte auf Papier ausgegeben werden soll, istbei herkmmlichen Programmen eine exakte Abbildung der Bildschirmkarte auf Papiervorgesehen. Wie in dieser Arbeit jedoch gezeigt wurde, ist das Medium Papier fr 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 deniert wurde, weiter auszubauen fr die Zustzliche Denition der Darstellungeiner Karte auf Papier.Mit dem in dieser Arbeit entstandenen System wurde es einem potentiellen Kartenau-tor ermglicht, die Darstellung von Geoobjekten mit ihrer Zeichenreihenfolge auch nochim Nachhinein zu gestalten, ohne auf einen Programmierer angewiesen zu sein. Beispiels-weise knnte die Mglichkeit weiter ausgearbeitet werden, die gesamte Kartendarstellungmit ihren Randangaben (Mastab, Kartentitel, . . . ) und Funktionalitten (Navigation,Zooming) zu manipulieren, damit ein Kartenautor Karten noch besser an Nutzerkreiseund Anwendungen anpassen kann. Denkbar wre hier eine Templatearchitektur, in der diefreie Positionierung und Gestaltung dieser Elemente und Schaltchen ermglicht werdenwrde.Denkbar fr die Weiterentwicklung eines generischen Kartengenerators wre auch dieKombinationsmglichkeit 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 aufgezhlten Erweiterungsmglichkeiten in der Lage einem Bildschirmkarten-Autor viele Mglichkeiten der Gestalltung zu bieten. In einer Zeit, in der die Entwick-lungskosten fr Software immer hher steigen, ist ein Werkzeug wie MapGENeric nichtmehr wegzudenken.Anhang AVRLA.1 Grammatik ::= | ::= KONFIGURATION ( " " ) { } ::= | ::= VMREGEL ( " " , , ){ } ::= on | off ::= | | ::= PUNKTDF ( , ){ } ::= FARBE ( ) |FARBE ( , , , ) ::= [0..255] ::= [0..255] ::= [0..255] ::= [0..255] ::= PFORM( ) |PFORM(Ellipse) |PFORM(Dreieck) |PFORM(Rechteck)121122 Kapitel A. VRL ::= BITMAP ( ) |BITMAP ( " " ) ::= LINIEDF ( , , , ){ } ::= solid | dash | dot | dashdot | dashdotdot ::= ::= ::= ArrowAnchor | RoundAnchor | SquareAnchor | NoAnchor ::= LFORM( ) |LFORM(flat) |LFORM(round) |LFORM(triangle) ::= FLAECHEDF { } ::= ::= GEOOBJEKTKLASSE( " " , ){ } ::= Punkt | Linie | Flaeche ::= GEOOBJEKTE ( ) |GEOOBJEKTE ( ) ::= SELECT AS mge_id, AS mge_long, AS mge_lat, AS mge_labelFROMWHERE ::= SELECT AS mge_id, AS mge_long, AS mge_lat,A.2 Beispiel 123 AS mge_label AS mge_seqposFROMWHEREA.2 BeispielDas folgende Beispiel ist nur ein Auszug aus der Konguration fr 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_labelFROMhotelsWHEREanzahl_zimmer > 200)ATTRIBUTE (SELECTid AS mge_id,'ID: ',id,'Name: ',name,'Zimmeranzahl: ',anzahl_zimmer,'Gnstigstes Zimmer (Euro): ',preisFROMhotels)PUNKTDF (15, 15){FARBE()FORM ()BITMAP("C:\Bilder\HotelIconKlein.gif")124 Kapitel A. VRL}}}VMREGEL ("Straenbahnhaltestellen", 4, on){GEOOBJEKTKLASSE("Straenbahnhaltestellen", Punkt){GEOOBJEKTE (SELECTid AS mge_id,Laengengrad AS mge_long,Breitengrad AS mge_lat,'' AS mge_labelFROMstrassenbahnhaltestellen)ATTRIBUTE (SELECTid AS mge_id,'ID: ',id,'Name: ',name,'Kapazitt: ',kapazitaet,'Linienanzahl: ',anzahl_linienFROMstrassenbahnhaltestellen)PUNKTDF (5, 5){FARBE(255, 34, 32, 209)FORM (Ellipse)BITMAP()}}}VMREGEL ("Einbahnstraen", 2, on){GEOOBJEKTKLASSE("Straen", Linie){GEOOBJEKTE (SELECTid AS mge_id,Laengengrad AS mge_long,Breitengrad AS mge_lat,Name AS mge_labelFROMstrassenbahnhaltestellen)A.2 Beispiel 125ATTRIBUTE (SELECTid AS mge_id,'ID: ',id,'Name: ',name,'Kapazitt: ',kapazitaet,'Linienanzahl: ',anzahl_linienFROMstrassenbahnhaltestellen)LINIEDF (3, solid, NoAnchor, ArrowAnchor){FARBE (255, 255, 255, 255)FORM (RECTANGLE)}}}VMREGEL (Land, 1, on){GEOOBJEKTKLASSE("Laubwald", Flche){...}Anhang BDB-SchnittstelleDie 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 clsConnectionDie Klasse clsConnection baut die Verbindung zu einer ber das GUI ausgewhlten,Access-Geodatenbank auf. Da keine weiteren Verbindungen bentigt werden, wurde dieseKlasse nach dem Singleton-Pattern entworfen. Design Patterns, zu denen das Singleton-Pattern zhlt, sind Muster bzw. Schablonen fr 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 whrend der gesamten Laufzeit allen anderen Komponentender Datenbank-Schnittstelle als zentraler Zugrispunkt. Sie holen sich ber die MethodegetConnection das eine Exemplar, um die Verbindung zur Datenbank aufzubauen.B.2 clsLayerDBReaderDie clsLayerDBReader -Klasse wird einmal beim Auslesen der Layerliste bentigt, direktnachdem entweder ber das Nutzer-GUI oder ber den Kongurations-Assistenten eineDatenbank ausgewhlt wurde. Sie berfhrt in der Datenbank vorliegende Layer in eineinterne Objektstruktur. Als Ergebnis liefert sie daraufhin eine Liste dieser systeminternenLayer-Objekte.B.3 clsMapObjectsDBReaderDie 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 mssen. Dazu werden alle Visualisierungs-Regeln126B.4 clsViewshapeDBReader 127aus der Datenbank ausgelesen, die mit Layern verknpft sind, die wiederum in der syste-minternen Layer-Objekte-Liste als sichtbar deniert sind. Daraufhin werden Geoobjektefr sichtbare Layer in dieser Liste ausgelesen, und in den jeweiligen Layern gespeichert.Jedes Geoobjekt erhlt neben ihren Geometriedaten ihre Darstellungsform, die durch dieVisualisierungs-Regel deniert wird. Ferner erhlt jedes Geoobjekt die Sichtdenition 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 auerhalb des aktuellenOriginWorldViewRange liegen. Wenn sie auerhalb liegen, wird der aktuelle Origin-WorldViewRange angepasst.B.4 clsViewshapeDBReaderDie Komponente clsViewshapeDBReader der DB-Schnittstelle dient zum auslesen derDarstellungsformen, und wird wie auch andere Komponenten die zur Konguration desSystems bentigt werden direkt nach der Auswahl der Datenbank ausgefhrt. Fr jedeTabelle mit Darstellungsformen (es gibt drei, fr jede Basisklasse eine) wird eine syste-minterne Liste erstellt, in die die jeweiligen Darstellungsformen eingelesen werden.B.5 clsAttributesDBReaderUm weitere Eigenschaften eines Geoobjektes anzeigen zu knnen, mssen diese ersteinmalausgelesen werden. Dies bernimmt die DB-Schnittstellen-Komponente clsAttributesD-BReader. Bei Anforderung durch den Nutzer ber den Karten-Bereich des Nutzer-GUIwird das ausgewhlte Geoobjekt bergeben, woraus sich die Komponente die Sichtde-nition fr Attribute ausliest und diese mit der ID des Geoobjekts ergnzt. 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.: Einfhrung 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. Auage, Wes-termann Verlag, 1999[FS00] Fowler, M. und Scott, K.: UML konzentriert, 2. Auage, Deutsche bersetzung,Addison-Wesley Verlag, 2000[Gr95] Grnreich, D.: Development of Computer-Assisted Generalization on the Basisof Cartographic Model Theory, in Mller, Lagrange u. Weibel, Seiten 4755, 1995[HG94] Hake, G.; Grnreich, D. : Kartographie; 7. Auage, de Gruyter, Berlin, 1994[Hey01] Heyn, Jrgen : 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. Auage, Oldenbourg Wissen-schaftsverlag, 2001128Literaturverzeichnis 129[Kri99] KRIZ, K.: Perspektiven in der Kartographie. In: KRETSCHMER, I., KRIZ,K.(Hrsg.): 25 Jahre Studienzweig Kartographie. Wien, Institut fr Geographie derUniversitt 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. Auage, 256 Seiten[Man99] Prof. Dr. Rainer Manthey: Skript zu Informationssysteme; Rheinische FriedrichWilhelm Universitt Bonn; WS99/00[Mat97] MATTHIAS, E.: Nutzungsmglichkeiten der neuen Ausgabeformen. In: DEUT-SCHE GESELLSCHAFT FR KARTOGRAPHIE E.V. (Hrsg.): Digitale Karten-technologie. 21. Arbeitskurs Niederdollendorf 29.9. bis 2.10.1997. Knigslutter 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] Rtsel 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.16.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 Einfhrung in die Geoinformatik an derUniversitt Mnster im WS 2005[Tp92] Tpfer, F.: Zur Bedeutung der kartographischen Generalisierung fr Geo-Informationssysteme, Kartographische Nachrichten Heft 42(1), 1220, 1992[Wag62] Karlheinz Wagner, Kartographische Netzentwrfe, Bibliographisches InstitutMannheim, 2. Auage 1962130 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)ErklrungBonn, 13. September 2005Hiermit erklre ich, dass ich vorliegende Diplomarbeit selbstndig durchgefhrt undkeine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlichgemacht habe.Ahmet Devrim

Recommended

View more >