Die vorliegende praxisorientierte Arbeit gibt einen Einblick in die Möglichkeiten der Programmier-
und Entwicklungsumgebung ‚WIGeoAPI Developer Net’ der Fa. WiGeoGis
GmbH sowie deren Werkzeuge (z.B. Modul XML Next Door) und dokumentiert
die Erstellung eines GIS-Tools namens „Apotheken u. Arztfinder im Wiener
Raum“. Dabei wurden ca. 300 Apotheken bzw. ca. 4800 Arztpraxen in einer Datenbank
im Raum Wien erfasst und zur weiteren Bearbeitung geokodiert und als sogennante Shape-Files für die weitere Bearbeitung in der oben erwähnten Entwicklungsumgebung abgespeichert.
Ziel des Praxisteils dieses Projekts ist es, mit Hilfe des hier vorgestellten GIS-Web-Tools „Apotheken- bzw. Arztfinder“ aus ca. 300 Apotheken bzw. ca. 4800 geokodierten (verorteten)Arztpraxen im Wiener Raum genau jene zu filtern die topographisch am nächsten beim Kunden verortet sind.
Diese Arbeit gliedert sich in einen theoretischen Teil wo in Grundzügen Daten Geographischer Informationssysteme, Datenbankmanagementsysteme und Datenorganisation von GIS-Daten genauer beschrieben werden. In weiterer Folge wird die Funktionalität des University of Minnesota Mapserver (UoM Mapserver) vorgestellt sowie die Script-Sprache PHP/Mapscript, die auch in der 'WIGeoAPI Developer
Net' Umgebung zum Einsatz kommt. Die zum Praxisteil überleitenden Kapitel beschreiben die Systemarchitektur, das Dateimanagement sowie das Datenmodell des Prototyps näher. Der Prototyp „Apothekenfinder“, verwendet die Funktionalität der Module XML Map Engine und XML GeoCoder. Diese Entwicklungs-Tools werden in der Arbeit genauer beschrieben. Ein weiteres zentrales Kapitel befasst sich eingehend mit der Erstellung des Prototyps.
Ein weiterer Kernteil dieser Arbeit ist die Erstellung eines Location Based Services
(LBS) - Prototypen mit Hilfe der Application Programming Interface (API)
Umgebung von Google Maps® [vgl. GOOG05]. Die API der Google Maps® wird hierzu
ausführlich beschrieben.
Im nachfolgenden Kapitel 6.11 „Beschreibung des Prototyps der API
Google Maps®“ wird der Quellcode, der in Form von JavaScript Code im
DHTML-Format geschrieben ist, in seine Programmteile zerlegt und die darin enthaltenen Klassen,
Methoden und Funktionen erklärt.
Das Schlusskapitel Zusammenfassung und Ausblick fasst die Kernteile dieser
Arbeit zusammen und gibt die gewonnen Erkenntnisse sowie weitere Modellierungs-
und Designmöglichkeiten der vorgestellten Prototypen wider.
Inhaltsverzeichnis
4 Einführung
5 Projektbeschreibung
5.1 Allgemeines
5.2 Rahmenbedingungen
5.3 Projektinhalte
5.4 Projektablauf
5.5 Projektphasen - Phasenmodell
5.6 Projektphasenplan und Projektmeilensteinplan
6 Inhalt
6.1 Strukturierung von Geographische Daten
6.2 Datenbankmanagementsysteme (DBM) zur Verwaltung von GIS-Daten
6.3 Datenorganisation von GIS Daten
6.4 UMN-Mapserver der WIGeoAPI Developer Umgebung– Beschreibung und Funktionsweise
6.5 Die Einbindung der Script-Sprache PHP/Mapscript
6.6 Die zur Verwendung kommenden Module der WIGeoAPI Programmierumgebung
6.6.1 Modul XML MapEngine
6.6.2 Modul XML GeoCoder
6.6.3 Modul XML NextDoor
6.7 Systemarchitektur und Systemmodell
6.8 Beschreibung des Dateimanagements
6.8.1 Logisches Datenmodell
6.8.2 Physisches Datenmodell
6.9 Beschreibung des Prototyps der WiGeoAPI Programmierumgebung
6.9.1 Analyse
6.9.2 Design
6.9.3 Implementierung
6.9.4 Test
6.10 Beschreibung der API von Google Maps
6.11 Beschreibung des Prototyps der API Google Maps
6.11.1 Analyse
6.11.2 Design
6.11.3 Implementierung
6.11.4 Test
7 Zusammenfassung und Ausblick
8 Source Code
8.1 Quellcodebeispiele
Zielsetzung & Themen der Arbeit
Ziel dieser Arbeit ist die Erstellung eines interaktiven GIS-Prototypen, der dem Nutzer in Form eines Location Based Services (LBS) Dienste zur Adresssuche bereitstellt. Dabei werden die Möglichkeiten der WIGeoAPI-Entwicklungsumgebung sowie die API von Google Maps zur Implementierung georeferenzierter Abfragen untersucht.
- Entwicklung eines GIS-Tools zur Standortsuche für Ärzte und Apotheken im Raum Wien.
- Nutzung der WIGeoAPI-Programmierumgebung und ihrer Module (XML MapEngine, XML GeoCoder).
- Integration der Google Maps API zur Bereitstellung eines interaktiven LBS-Prototypen.
- Anwendung des Wasserfallmodells als methodisches Rahmenkonzept.
- Praktische Implementierung mittels PHP/Mapscript und JavaScript-basiertem DHTML.
Auszug aus dem Buch
6.2 Datenbankmanagementsysteme (DBM) zur Verwaltung von GIS-Daten
Insbesondere bei GIS-Daten lässt sich ein hohes Datenvolumen feststellen. Effiziente und kostengünstige Verwaltung dieser großen Datenmengen (z.B. Kundendaten, Attributedaten oder raumbezogene Daten) wird dadurch erforderlich um kostenintensive Ressourcen (z.B. Server) zu sparen. Durch Datenbankmanagement (DBM) kann eine größere Zielgenauigkeit bei der Segmentierung der Märkte erreicht werden, die Geschäfts- und Kundenbeziehungen lassen sich genauer analysieren, steuern und nutzen [vgl. Holl92b, 779]. Dadurch wird es möglich, individuell und interaktiv mit den Kunden, Interessenten oder Zielpersonen zu kommunizieren.
Das DBM lässt sich durch vier wesentliche Merkmale bestimmen:
1) Der Einsatz von Database-Technologien dient zur Erfassung, Bearbeitung und zur Bereitstellung von Adressen und weiteren Informationen über Zielpersonen.
2) DBM ermöglicht die Nutzung der Daten und Informationen für den Einsatz der Direktmarketing-Instrumente.
3) Mit DBM soll die Ausgestaltung eines Dialogs zwischen dem Unternehmen und der Zielperson ermöglicht werden. Die Zielperson kann hier im Consumer Bereich oder auch im Business to Business Bereich liegen. Wichtig ist, dass dieser Dialog vom ersten Kontakt bis hin zur Bildung eines Stammkundenverhältnisses bzw. dem Ende der konkreten Beziehung aufrechterhalten wird.
4) Das DBM hat einen Systemcharakter, der durch die permanente Sammlung kommunikationsnotwendiger Daten und eine langfristige Perspektive beschrieben wird [vgl. Wonn97, 592].
Zusammenfassung der Kapitel
Einführung: Die Studie gibt einen Überblick über die WIGeoAPI Developer Net Umgebung und dokumentiert die Erstellung des Prototyps "Apotheken u. Ärztefinder im Wiener Raum".
Projektbeschreibung: Dieses Kapitel erläutert die Rahmenbedingungen, Projektinhalte sowie das verwendete Phasenmodell nach dem Wasserfall-Prinzip.
Inhalt: Hier werden theoretische Grundlagen zu GIS, Datenbankmanagement und Datenorganisation sowie die technischen Details der verwendeten Module (XML MapEngine, Geocoder, NextDoor) und der Google Maps API beschrieben.
Zusammenfassung und Ausblick: Das Abschlusskapitel fasst die Ergebnisse der Prototypenentwicklung zusammen und diskutiert weitere Erweiterungsmöglichkeiten.
Source Code: In diesem Teil sind alle für die Implementierung relevanten Quellcodebeispiele zusammengefasst.
Schlüsselwörter
Geoinformationssysteme, GIS, WIGeoAPI, Google Maps API, Location Based Services, LBS, Geokodierung, Web-Programmierung, PHP, Mapscript, Standortsuche, Datenbankmanagement, XML, Prototyping, Wasserfallmodell.
Häufig gestellte Fragen
Worum geht es in dieser Arbeit grundsätzlich?
Die Arbeit behandelt die Erstellung interaktiver GIS-Prototypen, um standortbezogene Dienste (LBS) für die Adresssuche von Apotheken und Ärzten im Wiener Raum zu realisieren.
Was sind die zentralen Themenfelder?
Die zentralen Themen umfassen Geoinformationssysteme, die WIGeoAPI-Programmierumgebung, die Google Maps API sowie datenbankgestützte Standortanalysen.
Was ist das primäre Ziel der Arbeit?
Ziel ist der Aufbau eines lauffähigen GIS-Tools, das Geodaten verarbeitet und dem Nutzer eine intuitive, grafische Benutzeroberfläche zur Standortsuche bietet.
Welche wissenschaftliche Methode wird verwendet?
Die Projektdurchführung orientiert sich am Wasserfallmodell, unterteilt in Anforderungsanalyse, Systementwurf, Implementierung und Testphase.
Was wird im Hauptteil der Arbeit behandelt?
Der Hauptteil gliedert sich in theoretische Grundlagen zu GIS und DBM, eine detaillierte technische Beschreibung der WIGeoAPI-Module sowie den praxisorientierten Teil zur Implementierung der zwei Prototypen.
Welche Schlüsselwörter charakterisieren die Arbeit?
Die Arbeit wird primär durch Begriffe wie GIS, WIGeoAPI, Google Maps, LBS, Geokodierung, PHP und Standortsuche charakterisiert.
Warum wurde das XML-Modul NextDoor beschrieben, aber nicht im Prototyp genutzt?
Es wurde für optionale Routenplanungsfunktionen beschrieben, war jedoch für den primären Fokus der Standortsuche des hier vorgestellten Prototyps nicht zwingend erforderlich.
Wie unterscheidet sich die Geokodierung mit dem WIGeoAPI-Modul von der Google Maps-Lösung?
Während das WIGeoAPI-Modul gezielt für Datenbankabfragen und Geokodierungsschnittstellen in der WIGeoGIS-Umgebung konzipiert ist, stellt die Google Maps API eine stärker interaktive, clientseitige Lösung mittels JavaScript dar.
- Quote paper
- MMag. Ondrej Horsky (Author), 2005, Erstellung eines GIS-Tools für die Standortsuche von praktischen Ärzten bzw. Apotheken im Wiener Raum, Munich, GRIN Verlag, https://www.grin.com/document/52186
