1. Einleitung / Motivation - Institut für Geodäsie und Geoinformation

Transcrição

1. Einleitung / Motivation
1.1. Motivation seitens der Studenten
2. Ablauf /Phasen des Projektes
2
2
2
2.1. Seminarphase
2
2.2. Planungsphase
6
2.3. Durchführungsphase
7
2.3.1. Gruppe Daten
7
7
7
8
9
16
17
17
2.3.1.1. Allgemeines
2.3.1.2. Historisches
2.3.1.3. Übersicht über die Daten
2.3.1.4. Vorgehen bei der Bearbeitung
2.3.1.5. Ergebnisse
2.3.1.6. Resümee
2.3.1.7. Die Gruppenmitglieder und ihre Aufgabenfelder
2.3.2. Gruppe Navigation
2.3.2.1. Allgemeine Ziele, Gruppenzusammensetzung, Arbeitsaufteilung
2.3.2.2. Programmierung
2.3.2.3. Kantengewinnungsfunktion, Travelling-Salesman-Problem
2.3.2.4. Höhenprofil
2.3.2.5. GPS-Anbindung
2.3.3. Gruppe Technik
2.3.3.1. Aufgaben Gruppe Technik
2.3.3.2. Übersicht ArcIMS
2.3.3.3. Schnittstelle für Routenplanung
2.3.3.4. Anbindung der Webseite an den ArcIMS
2.3.3.5. Schlußbetrachtung
2.3.3.6. Zusammensetzung der Gruppe Technik
2.3.4. Gruppe Gestaltung
2.3.4.2. Gruppenaufteilung
2.3.4.3. Durchführung
2.3.4.4. Resümee der Gruppe Gestaltung
3. Resümee
3.1. Resümee der Studenten
3.2. Persönliche Stellungnahme der Projektleiter
19
19
19
20
22
25
28
28
28
30
34
35
36
37
37
37
38
45
46
46
47
1
1. Einleitung / Motivation
Im Wintersemester 2000/01 wurde im Studiengang Geodäsie im Rahmen der
Vertiefungsveranstaltung des Faches Kartographie erstmalig ein Projekt angeboten, welches in
Zusammenarbeit mit dem Lehrstuhl für Geoinformation durchgeführt werden sollte.
Ziel des Projektes mit dem Titel „Multimediales Internetangebot ‚Freizeit und Kultur in Bonn‘ mit GPSAnbindung“ war es, einen Fahrradroutenplaner zu entwickeln, welcher über das Internet für die
Allgemeinheit verfügbar gemacht werden sollte. Das Interesse, an diesem Projekt teilzunehmen, war
sowohl seitens der Studenten als auch seitens der Professoren und wissenschaftlichen Mitarbeiter
des IKG (Institut für Kartographie und Geoinformation) sehr groß.
1.2. Motivation seitens der Studenten
In dieser Vertiefung wurde uns erstmalig in unserem Studienfach die Möglichkeit geboten, über einen
längeren Zeitraum an einem Projekt teilzunehmen. Das besondere daran war, dass wir von der ersten
Idee, über die Durchführung bis hin zur Dokumentation und Präsentation selbständig und zum großen
Teil eigenverantwortlich unser Produkt „Fahrradroutenplaner“ gestalten konnten. Reizvoll war dabei,
dass wir mit unserer eigenen Initiative großen Einfluß auf das Ergebnis nehmen konnten. Wir
erhofften uns durch dieses Projekt Schlüsselqualifikationen, wie Teamfähigkeit oder Eigeninitiative,
welche heutzutage auf dem Arbeitsmarkt besonders gefordert werden, erlangen zu können.
Ein weiterer wichtiger Grund für unser Interesse war die Neugier auf das erst seit kurzem eingerichtete
Fach der Geoinformation, welches einen neuen, zukunftsorientierten Zweig des Geodäsie-Studiums
darstellt. In diesem Zusammenhang spielte auch die Aussicht auf die Arbeit mit modernen Medien wie
dem Internet oder verschiedenen GIS-Systemen eine wichtige Rolle.
Ein weiterer Anreiz bestand darin, dass es sich bei der Entwicklung des Fahrradroutenplaners um ein
praxisorientiertes Projekt handelt, dessen Ergebnis auch im täglichen Leben für jedermann nützlich
sein könnte. Ferner ist die behandelte Thematik der Freitzeitgestaltung in der unmittelbaren
Umgebung für jeden interessant, und kann im Gegensatz zu vielen anderen Studieninhalten auch
fachfremde Freunde und Bekannte ansprechen.
Und Last but not Least überzeugte uns auch die große Motivation und Begeisterung, mit der die
Initiatoren das Projekt angingen.
2. Ablauf / Phasen des Projektes
2.1 Seminarphase
Am Anfang des Projektes stand eine ‚Seminarphase, welche dazu diente eine für das Projekt
notwendige einheitliche Wissensgrundlage zu schaffen.
Jede/r Student/in bereitete dabei ein bestimmtes Thema vor, dessen Kenntnis für die Durchführung
des Projektes notwendig war, und referierte über die Ergebnisse in einem ca. 30-minütigen Vortrag,
an den sich jeweils eine ca. 15-minütige Diskussion anschloss.
Es folgt eine Aufstellung der jeweiligen Vortragsthemen mit einer kurzen Inhaltsübersicht und den
Namen der Referenten und Betreuer:
1. Basisinformationen der Landesvermessung
Landschaftsmodellierung in ATKIS
Erfassungsstand in ATKIS
Nutzung der ATKIS-Daten und Ausgabeproduktfamilie
DTK 10 und ihr Inhalt
Eignung dieser Daten für Routenplanung; Vergleich mit
GDF-Datenformat
Referent: Andreas Neuenhausen; Ansprechpartner: PD Dr.Schoppmeyer
2
2. Thematische Informationen
Hintergrund für thematische Karten
Bezugssysteme
Homogenität von Basisinformationssystemen und Thema
Datenbeschaffung (z.B. von der Stadt: Sehenswürdigkeiten,
Fahrradwege)
Referent: Thomas Krompholz; Ansprechpartner: PD Dr. Averdung
3. Digitale Geländemodelle
Aufbau digitaler Geländemodelle
TIN- und Gitterstrukturen
Integration von Strukturinformationen (Rücken- und Muldenlinien,
Aussparungen, singuläre Punkte)
Nutzung für Präsentation und digitale Auswertung (z.B. Ableitung
von Streckenhöhenprofilen)
Referent: Georges Audry; Ansprechpartner: PD Dr. Schoppmeyer
4. Urheberrecht und Nutzungsrechte an Geodaten
Was ist geschützt? (UrhG und EU-Datenbankrichtlinie)
Wie erfolgt die Nutzungsgenehmigung? (Bundesland und
länderübergreifend)
Welche Kosten entstehen für die Nutzer?
ATKIS-Vertriebskonzept
Probleme bei der Benutzung der Daten im Internet
Referent: Jens Stenger; Ansprechpartner: PD Dr. Schoppmeyer
5. Datenintegration mit Support-GIS
Konzepte und Modelle von Support-GIS
Schemagenerator
Datenimport und -export
Integration von DGM- und DTK-Daten
Referentin: Annette Eicker; Ansprechpartner: PD Dr. Averdung
6. Verkehrsnetze in GIS
Geometrisch-topologische Datenstrukturen
Spezifische Attribute für die Routenplanung (Einbahnstraßen,
Abbiegeverbote, Straßenbelag etc.)
Amtliche Daten
GDF (Verkehrsdaten zur Routenplanung)
Geometrische Netze in Arc/Info
Referent: Mathias Thelker; Ansprechpartner: Dr. Kolbe
7. Routen- und Tourenplanung
Dijkstra-Algorithmus
Travelling-Salesman-Problem
Spezifische Anforderungen (Straßen- und Höhenprofil,
3
Fahrradwege)
Systemfunktionen mit Arc/Info
Referent: Thorsten Berka; Ansprechpartner: Dr. Kolbe
8. Kartographische Gestaltung: Einsatz multimedialer Variablen
Semiotik
Dynamik
Farb- und Formwahrnehmung
Schallereignisse
Referent: Frank Weydert; Ansprechpartner: PD Dr. Averdung
9. Multimediale Kartographie
Kognitive Aspekte: Wahrnehmung und mentale Modellbildung
Erweiterung des kartographischen Variablen- und Zeichensystems
Kommunikation und Interaktion
Referentin: Alexandra Höfer; Ansprechpartner: PD Dr. Averdung
10. Bildschirmkarte
Anforderungen
Eigenschaften und Struktur einer Bildschirmkarte
Kartographische Gestaltungsmittel
Interaktionsmöglichkeiten
Referent: Markus Kosbab; Ansprechpartner: PD Dr. Averdung
11. Arc/Map - Kartographische Möglichkeiten von Arc/Info
Layer und Legenden
Erzeugung von Symbolen und Signaturen
Darstellung von Netzen
Positionierung und Gestaltung von Schrift
Erzeugung von Kartenobjekten aus Objekten der Geodatenbank
Inwieweit ist Arc/Info - Arc/Map "objektorientiert"?
Referentin: Ariane Middel; Ansprechpartner: Prof. Plümer
12. 3D-Darstellung räumlicher Daten
3D-Modellwelt
DGM-Auflösung versus Texturqualität
VRML für kartographische Darstellung
Referent: Olaf Bromorzki; Ansprechpartner: PD Dr. Averdung
13. Internet-GIS
Klassifizierung von Internet-GIS
Technische Hintergründe von Internet-GIS
Graphische Fähigkeiten von Java
Internet Map Server (IMS) von Arc/Info
4
Referent: Ralf Müller; Ansprechpartner: Dr. Kolbe
14. Anfragesprachen für raumbezogene Daten
SQL
Raumbezogene Erweiterungen von SQL
Graphische Unterstützung zur Formulierung von Anfragen
Möglichkeiten und Grenzen von Arc/Info & Internet Map Server
Referent: Sascha Rudolph; Ansprechpartner: Dr. Kolbe
15. Arc/Info: Geodatabase
Geodatabase, Coverages, Shape-Files
Das Datenbankkonzept von Arc/Info 8
Objektorientierung: Objekte, Domänen und Subtypen, Integrität,
Methoden
Spatial Database Engine (SDE)
Grid: Zugriffspfad für räumliche Objekte
Referent: Enrico Kurtenbach; Ansprechpartner: Prof. Plümer
16. Interaktive Karten im Internet - Technische Infrastruktur (2
Vorträge)
Client-Server-Prinzip
Grundlagen Web-Server
Kopplung Web-Server - Map-Server - Datenbank
IIS - IMS - MapObject - SDE - RDBMS
Referenten: Christoph Schaefer, Markus Tondorf; Ansprechpartner: Dr. Kolbe
17. Web-Design und Multimedia im WWW
HTML, XML
Java, Flash und Plug-Ins
Autorensysteme, Gestaltungswerkzeuge
Anwendung kartographischer Gestaltungsregeln ("Vom Musterblatt
zum Styleguide")
Probleme bzgl. Interoperabilität
Referentin: Kathrin Haverkamp; Ansprechpartner: Dipl.-Ing. Kneuper
18. Kultur und Sport mit GPS
Westentaschenformat (Low-Cost Pocket Version)
Automatische Erzeugung von Wegmarken
Austauschformate
Probleme und Perspektiven
Referent: Helmut Jansen; Ansprechpartner: Prof. Plümer
5
19. Mobile Geoprocessing / Bildschirmkarten für unterwegs
Bildschirmkarte im WAP-Handy?
GPS und Handy, GPS und PDA
Aktuelle Systeme und Anwendungen
Referent: Heiko Stumm; Ansprechpartner: Dr. Kolbe
20. Die Präsentation der Stadt Bonn im Internet
Bonn als Lebensraum aus stadtgeographischer Sicht
Klassifikation und Bewertung des Kultur- und Freizeitangebots
Präsentation einer Kommune im Internet (Recherche, Vergleich)
Defizite der vorhandenen Präsentation
Bedarfsanalyse
Wie bewertet man Erfolg, Nutzungsmuster und Zugriffspfade eines
Internet-Angebots?
Referent: Carsten Szidzik; Ansprechpartner: PD Dr. Averdung
21. Freizeitradler und Fahrradkarten
Untersuchung verschiedener Radwanderführer; Systematisierung;
Klassifizierung
Unterschiede zu Autostraßenkarten
Welche Rolle spielt die Karte in bezug auf den beschreibenden
Text?
Feststellung des praktischen Nutzens der angebotenen Karten und
Informationen
Was läßt sich wie auf das Internet-Angebot übertragen?
(gemeinsam mit Vortrag 22)
Referent: Boris Giesen; Ansprechpartner: Prof. Plümer, Dr. Kolbe
22. Bildschirmkarten im Internet - Eine kritische
Bestandsaufnahme aus der Sicht des Radfahrers
Recherche; Systematisierung und Klassifizierung
Identifikation von Defiziten; Verbesserungsmöglichkeiten
Qualität der Bildschirm- und Druckausgabe
Was läßt sich wie auf das Internet-Angebot übertragen?
(gemeinsam mit Vortrag 21)
Referent: Dirk Schröder; Ansprechpartner: Prof. Plümer, Dr. Kolbe
2.2. Planungsphase
Im Anschluß an die Seminarphase fand die Planungsphase statt. In dieser Phase wurde darüber
diskutiert, inwieweit man das „Gehörte“ umsetzten konnte. Mehrere Lösungsvorschläge, die während
der Seminarphase vorgestellt oder erarbeitet wurden, mußten verworfen werden, da sich bei einer
näheren Betrachtungsweise viele Nachteile einstellten. Zu Beginn des Seminars gingen wir z.B. davon
aus, daß zur Datentransformation das Programm „SupportGIS“, welches an der Universität Bonn
entwickelt wurde, verwendet werden kann. Aber es stellte sich dann heraus, daß dieses noch in der
Entwicklung befindliche Programm nicht in der Lage war die relativ großen Datenmengen einzulesen.
6
In erster Linie fiel auf, daß die einzelnen Themenkomplexe so umfangreich waren, daß man die
Teilnehmer des Vertieferseminars in einzelne Gruppen aufteilen mußte, so daß man sich intensiver
mit den jeweiligen Problemen auseinandersetzen konnte:
2.3.1. Gruppe: Daten
2.3.2. Gruppe: Navigation
2.3.3. Gruppe: Technik
2.3.4. Gruppe: Gestaltung
Jede dieser Gruppen wählte einen Gruppensprecher, dessen Aufgabe darin bestand, im weiteren
Verlauf des Projektes die Ergebnisse und Fortschritte der jeweiligen Gruppe vorzustellen.
Desweiteren wurde je ein Schnittstellenbeauftragter bestimmt, der für die Kommunikation mit den
anderen Gruppen zuständig sein sollte.
2.3. Durchführungsphase
Mit der Durchführungsphase begann die eigentliche Arbeit der Gruppen an ihrem Aufgabenbereich.
Da die Gruppen jedoch nicht isoliert zu betrachten waren, wurden in wöchentlichem Abstand Treffen
der gesamten Projektgruppe und der Betreuer durchgeführt. Dies ermöglichte es jedem Teilnehmer
einen Überblick über die Arbeit der anderen Gruppen und den Fortschritt des Gesamtprojektes zu
erhalten. Außerdem wurden die weiteren Vorgehensweisen der verschiedenen Gruppen geklärt um
insbesondere Überlappungen der Zuständigkeiten der einzelnen Gruppen zu verhindern.
Im folgenden wird die Arbeit der einzelnen Gruppen vorgestellt:
2.3.1 Gruppe Daten
2.3.1.1. Allgemeines:
Die Gruppe Daten war im Gesamtprojekt „Fahrradkarte der Stadt Bonn“ für die Sammlung und
Aufbereitung aller nötigen Daten verantwortlich. Dabei wurde versucht, die Anfragen und
Ansprüche der anderen Gruppen zu erfüllen.
Die Daten wurden dabei in unterschiedlichsten Formen und Formaten angenommen und in das
Gesamtprojekt eingebracht. Dabei wurden einerseits Kartenbilder an die Gruppe „Gestaltung“
abgegeben (Vektor und Raster) und andererseits eine Datenbank aufgebaut, die die nötigen
Hintergrundinformationen für die Topographie liefert. Diese wurde von den Gruppen „Gestaltung“
und „Navigation“ benötigt. Die Aufbereitung der Daten sollte unter anderem mit dem Programm
ArcInfo erfolgen.
2.3.1.2.Historisches:
Die Gruppe Daten erlebte während der Planung und Durchführung des Projekts eine ständige
Wandlung aufgrund von Veränderungen der Datenquellen und –formate. Aus diesem Grund ist es
auch schwierig, einen optimalen vollständigen Ablauf unserer Tätigkeit darzustellen. Oftmals
wurden Umwege beschritten, die im Nachhinein einfacher zu bewerkstelligen waren.
Ursprünglich gab es Diskussionen über die Quelle der Hauptdaten. Dabei fiel die Wahl auf ATKISDaten des Landesvermessungsamtes, die im Gegensatz zu den gdf-Daten der Firma TeleAtlas
nicht nur die reinen Verkehrswege erfaßten, sondern auch zusätzliche Topographie.
Beide Formate konnten jedoch nicht ohne weiteres in unser GIS importiert werden.
Eine weitere Diskussion gab es im Bereich des GIS, das wir benutzen wollten. Die Entscheidung
fiel auf ArcInfo, zu dem wir entsprechende Konvertierungstools der Firma CITRA erhielten.
Die zusätzlichen Daten über die Wege und Straßen sollten von der Stadt Bonn kommen.
Nach einem Besuch im Stadthaus stellte sich jedoch heraus, daß die Stadt bereits ein eigenes GIS
besitzt und wir dieses nutzen könnten. Als Konsequenz wurden die ATKIS-Daten verworfen und
die Daten der Stadt Bonn unsere neue Grundlage. Diese mußten jedoch noch aus dem SICADFormat nach ArcInfo importiert werden, was relativ reibungslos funktionierte.
Bei der Wahl der Rasterkarte kamen wir auf die topographische Karte des
Landesvermessungsamtes in Form von digitalen Daten auf der TOP10-CD.
Die Gruppe Daten war damit in der Lage, auf sicherer Basis mit der Planung einer Datenbank und
7
sonstiger Bearbeitung, wie unten beschrieben, zu beginnen.
2.3.1.3. Übersicht über die Daten:
Für unser Projekt wurden verschiedene Arten von Daten benötigt. Im Einzelnen brauchten wir
dafür:
Kartenmaterial, digital im Vektorformat:
Für die Darstellung der Fahrradkarte auf einer Internetseite wurde eine Karte von Bonn benötigt,
die durch Anbindung an eine Datenbank die nötigen Informationen bot.
Dafür war eine Vektorkarte erforderlich.
Ursprünglich gab es zwei verschiedene Datenquellen bzw. –formate, die zur Diskussion standen:
Geographic Data Files (gdf), die in Autonavigationssystemen zum Einsatz kommen. Dieses Format
hat den Vorteil, daß das Verkehrssystem für eine Routenplanung optimal aufbereitet ist. Es gibt
Abbiegespuren, Einbahnstraßen usw.
Nachteilig wirkt sich aber die fehlende Topographie aus. Schließlich mußten unsere Daten
Grundlage für eine Karte sein.
ATKIS, das geographische Informationssystem des Landesvermessungsamtes, hingegen bietet
alle topographischen Strukturen, die wir benötigten. Als kleiner Nachteil ergab sich die fehlende
Struktur der Verkehrswege (wie bei gdf) und ein etwas komplizierter Aufbau der Daten.
Beide Formate ließen sich jedoch nicht ohne weiteres mit ArcInfo bearbeiten, das seine eigenen
Datenformate benutzt. Von der Firma CITRA wurde uns daher ein Konvertierungsprogramm zur
Verfügung gestellt, mit dem sich ATKIS-Daten (für diese hatten wir uns entschieden) in ArcInfo
shape-Files konvertieren ließen.
Letztendlich kam dann aber doch ein ganz anderes Format zum Einsatz, auf das wir mehr
überraschend bei Gesprächen mit der Stadt Bonn trafen. Dieses hatte den Vorteil, daß die
räumlichen Daten schon mit diversen Attributen verbunden waren, wir also einen Bezug zu unserer
Datenbank herstellen konnten.
Die Daten der Stadt Bonn wurden aus einer Informix bzw. SICAD-Datenbank in shape-Files
konvertiert und uns zur Verfügung gestellt.
Kartenmaterial, digital als Rasterkarte:
Da die Karte auch in vergrößerter Form dargestellt werden sollte, mußte sie auch bei großen
Maßstäben immer noch erkennbar sein. Um dies zu gewährleisten, wurde das Gebiet ebenfalls
durch eine Rasterkarte dargestellt, die auch zur Verfügung gestellt wurde.
Als Quelle für Rasterdaten wurde die TOP10 (TK 1:10.000) CD des Landesvermessungsamtes
gewählt.
Informationen über Straßen und Wege:
Um eine Route zu planen, sollten gewisse Faktoren der Straßenbeschaffenheit, Steigung, Umwelt
usw. berücksichtigt werden. Die meisten Daten wurden uns durch die Stadt Bonn zur Verfügung
gestellt.
Informationen über sonstige, für den Radfahrer interessante topographische
Gegebenheiten:
Als weiteren Zusatz zu unserer Fahrradkarte sollte der Nutzer auch Informationen erhalten, die
nicht direkt mit der Routenplanung zusammenhingen. Dazu gehörten Positionen und Daten zu
Fahrradgeschäften, Sehenswürdigkeiten, öffentlichen Gebäuden usw.
Auch diese Informationen wurden gesammelt und an die Topographie angebunden.
Höhenraster des Gebietes:
Um Steigungen der Route zu beachten, wurden Höhen des Gebietes benötigt. Diese erhielten wir
über das digitale Geländemodell (DGM) des Landesvermessungsamtes, das uns ein Raster (10 m
Abstand) von Höhen in einem ASCII-Format lieferte.
8
2.3.1.4. Vorgehen bei der Bearbeitung:
Vektordaten:
Wir erhielten die Vektordaten im "shape"-File-Format der Firma ESRI, so daß sich die Einbindung
in das Programm ArcInfo problemlos gestaltete. Die Daten waren aufgeteilt in mehrere einzelne
Files: 4 Files deckten das Bonner Stadtgebiet ab (Bonn, Beuel, Godesberg und Rhein-SiegUmgebung), 1 File stellte noch zusätzliche Kartensymbole für das ganze Gebiet zur Verfügung.
Außerdem erhielten wir noch Flächendaten, Polygone, die eine bestimmte Nutzung angaben.
Diese nutzten wir nur zur grafischen Darstellung der Karte.
Alle shape-Files wurden zunächst mit der ArcInfo-Toolbox in das Linien-coverage-Format
überführt, da nur dieses den Aufbau einer Topologie erlaubt. Hier traten bereits die ersten
Probleme auf:
Die "beuel"-Coverage enthielt ein Kante mit den Koordinaten (0/0), die das Erscheinungsbild
natürlich massiv verzerrte. Nach längeren Irrwegen konnten wir diese Kante schließlich mit Hilfe
von ArcView aus dem Datenbestand löschen.
Auf der "bonn"-Coverage war nichts zu sehen, ArcInfo zeigte keine Geometrie an. Dieses Problem
löste sich beim Aufbau der Topologie. Außerdem fehlten einige Kanten (Autobahnstück).
Die "godesberg"-Coverage zeigt im Zentrum von Bad-Godesberg einen weißen Fleck. Hier ist die
Aufnahme der Daten bei der Stadt Bonn noch nicht vollständig.
Anzumerken ist noch, daß in diesen coverages nicht nur Straßen, sondern auch Gemeindegrenzen, Bahnlinien etc. gespeichert waren.
Alle Daten besaßen bereits Gauß-Krüger-Koordinaten, waren jedoch nicht georeferenziert. ArcInfo
konnte die Koordinaten nicht automatisch einem System zuordnen. Die "25" im Rechtswert wurde
also als volle Koordinate angenommen und nicht als Angabe eines Meridianstreifens. Dies wurde
manuell von uns über ein Tool eingegeben.
Wir führten jetzt erst einmal die Topologie bei allen 4 Gebietsfiles getrennt ein, nicht zuletzt um die
"verschwundene" Bonn-coverage sichtbar zu machen, was auch gelang. Unter normalen
Umständen ließe sich dieser Schritt sparen.
Anschließend führten wir alle coverages zu einer einzigen zusammen und erzeugten erneut eine
Topologie über das gesamte Stadtgebiet. ArcInfo stellt zwei Befehle zur Verfügung, "build" und
"clean", wobei "clean" eine Toleranzentfernung von Kanten anbietet. Wir wählten "clean" mit einer
Fehlertoleranz von 0,1 m.
Zwischenstand:
In diesem Stadium der Bearbeitung lagen die Vektordaten mit "erster" Topologie (ohne
Überführungsproblematik) georeferenziert vor. Die einzigen Attribute der Daten waren bisher nur
ihre räumliche Struktur (Kanten mit Knoten). Inhaltliche Angaben, wie Straßenname, Steigung etc.
waren noch nicht mit den Coverages verknüpft.
Attributdaten:
Von der Stadt Bonn erhielten wir allgemeine Daten wie Straßenname, Tempolimit (teilweise) usw.
Die Daten waren in einer MS Access Datenbank gespeichert und über eine ObjektNr (Stadt Bonn
intern), z.B. L10005_6 mit den räumlichen Daten, die in ihren Attributen diese Nummer ebenfalls
enthielten, verbunden.
Um unsere Karte mit weiteren Information zu füllen (Radwege) war die Beschaffung von weiteren
externen Daten nötig.
Während im Dezember 2000 noch unsicher war, ob Support-GIS, ArcInfo, SICAD oder doch
Intergraphs Geomedia für unsere ATKIS-Daten der Stadt Bonn geeignet ist und welche
Abgrenzung unser Arbeitsgebiet besitzt, wurde Kontakt mit dem Bund Deutscher Radfahrer (BDR),
dem Allgemeiner Deutschen Fahrrad Club (ADFC) Sektion Bonn und der Bundesstadt Bonn
aufgenommen.
9
Die zur Verfügung oder zum Kauf angebotenen Unterlagen unterschieden sich erheblich in
Aktualität, Qualität und Quantität:
BDR: Deutsche Rad-Tourenkarte Nr.26, 1: 100 000, Stand 2000
ADFC: Regionalkarte, 1: 75 000, Stand 2000
ADFC: Fahrradstadtplan, 1: 20 000, Stand 1998
Bundesstadt Bonn: Routenvorschläge, Stand 2000.
Gleichzeitig wurde nach ähnlichen, schon verwirklichten und verfügbaren Projekten oder
Informationssystemen recherchiert, Vergleichbares in Umfang und Ausführung aber nicht
gefunden!
Es entstand eine 20-seitige (100 KB) Klassifikation des Bonner Radwegenetzes nach der
Befahrbarkeit: Verkehrsaufkommen, Beschaffenheit und Zustand.
Um diese Daten zusammenzubringen, verwendeten wir zunächst die Funktionen von MS-Access.
Durch diverse Abfragen ließen sich erst einmal die Objektnummern mit Straßennamen (Stadt
Bonn) mit den Straßennamen und Radwegen (ADFC) verbinden. Dabei war zu beachten, daß die
Straßennamen erst an die jeweilige Schreibweise angepaßt werden mußten. Dies geschah auch
mehr oder weniger in Handarbeit und stellte uns vor Probleme: Hinsichtlich der Straßennamen
lieferte die Datenbank der Stadt fehlerhafte und lückenhafte Daten, d.h., die gesuchte Straße war
zwar geographisch in den Stadtdaten an der richtigen Stelle vorhanden, aber nicht jede Kante der
Straße enthielt den gesuchten Straßennamen, sondern die Bezeichnung „nicht mehr vorhanden“.
Zudem befanden sich vereinzelte Kanten willkürlich in dem Stadtgebiet verteilt, deren Straßennamen falsch waren.
Wir erhielten also jetzt eine MS Access Datenbank in der folgenden Form:
Stadt Bonn – Attributdaten:
ObjektNr
Straßenname
...
L1002_23
Nußallee
...
L2434_1
Endenicher Allee ...
...
ADFC-Radweg – Attributdaten:
Straßenname
Radweg:
Nussallee
12
Endenicher Allee
23
...
Attributdaten:
ObjektNr
Straßenname
L1002_23
Nußallee
L2434_1
Endenicher Allee
...
Radweg:
12
23
...
...
...
Wir konnten jetzt jedem Objekt = jeder Kante ein Radweg-Attribut zuordnen (soweit vorhanden).
Über die ObjektNr hatten die Daten einen Bezug zur Coverage der räumlichen Daten.
Um die Steigung der Kanten zu gewinnen, mußte viel experimentiert und ausprobiert werden, und
der letztendlich eingeschlagene Weg zeugt von der Benutzerfeindlichkeit ArcInfos in manchen
Teilbereichen der Arbeiten. Um die Abfolge unserer Arbeit einzuhalten, wenden wir uns jetzt erst
den Daten des DGM zu:
Höhenraster:
Datengrundlage bei der Erstellung des Digitalen Höhenmodells, das später zum Beispiel für die
Berechnung der Steigungen der Straßen benötigt wurde, war das DGM 5, das uns vom
Landesvermessungsamt zur Verfügung gestellt wurde. Hierbei handelt es sich um ein Höhenraster
mit der Rasterbreite 10m, das in einer einfachen ASCII-Datei abgelegt ist. Die einzelnen
Höhenpunkte sind in der Datei in der Form „Rechtswert ... Hochwert ... Höhe“ abgelegt. Die
Sortierung erfolgte hierbei spaltenweise (aufsteigende Rechtswerte) und mit aufsteigenden
Hochwerten. Man hat in ArcInfo die Möglichkeit, ein DGM aus einer ASCII-Datei einzulesen, das
Datenformat unterscheidet sich allerdings von den zur Verfügung gestellten DGM-Daten.
10
Abbildung 1 DGM-Daten des LvermA
Abbildung 2 Von ArcInfo benötigtes DGM-Format
Die vom LVermA erhaltenen Daten mußten daher in ein ArcInfo-konformes Datenformat konvertiert
werden. Eine weitere Schwierigkeit war, daß die DGM 5-Daten aus Kacheln mit einer Größe von 2
x 2 Km² bestehen. Neben einer Umsortierung der Höhendaten aus den *.ras-Dateien mußten diese
auch in einer großen Eingabedatei zusammengefaßt werden. Dies geschah durch
Implementierung eines kleinen C-Programms. Zu diesem Zeitpunkt erschien uns dieser Weg als
der einfachste, da wir noch wenig Erfahrung mit ArcInfo hatten. Heute sind wir schlauer: ein
Zusammenfassen mehrerer Einzelkacheln ist auch direkt mit ArcInfo möglich. Ein kleines Problem
tauchte dennoch auf: Die letzte Kachel im Südosten unseres „Einsatzgebietes“ lag leider in
Rheinland-Pfalz, so daß sie bei den Daten des LVermA NRW nicht mitgeliefert wurde. Wir halfen
uns damit, in der fehlenden Kachel alle Höhen auf einen mittleren Wert von 50,00 m zu setzen,
ohne dabei außer acht zu lassen, daß es bei der späteren Berechnung der Steigungen zu
problematischen (weil unrealistischen) Werten kommen könnte. Dies nahmen wir aber in Kauf, da
die Anzahl dieser Problemfälle verschwindend gering war.
Nach der Konvertierung und Zusammenfassung der Einzelkacheln konnte das DGM in ArcInfo
eingelesen werden, und stand somit als Datengrundlage für eine Weiterverarbeitung zur
Verfügung.
Nach Abschluß der Arbeiten am DGM konnte mit der Bearbeitung des Netzwerkes begonnen
werden. Hierbei waren im einzelnen folgende Probleme zu lösen: Zum einen die Bestimmung der
Steigung der einzelnen Kanten im Netzwerk und zum anderen die Berücksichtigung der Brücken,
die bei der Erstellung der Topologie noch unberücksichtigt geblieben waren.
Das Netzwerk der Straßen lag in einer Linien-Coverage vor. Hierbei sind die Kreuzungspunkte die
Knoten und die Straßen sind Kanten des Netzwerks. Um die Steigung der Kanten bestimmen zu
können, mußte man die Höhen der einzelnen Knoten kennen. Diese ließen sich aus dem DGM
ableiten. Hierzu wurde in einem ersten Schritt aus der Linien-Coverage eine Punkt-Coverage
erzeugt, die nur noch die Knotenpunkte des Netzwerks enthielt. Der hierzu verwendete Befehl
lautet:
NODEPOINT <in_cover> <out_cover>1
Aus der Punkt-Coverage ließen sich jetzt einfach unter Zuhilfenahme des DGM die Höhen der
Punkte ermitteln und in einem neuen Attribut "Höhe" ablegen. Hierzu verwendeten wir die Funktion
LATTICESPOT <in_lattice> <in_cover> {spot_item} {z_factor}
Die Punkt-Coverage konnte jetzt mit ArcCatalog in eine vorher mit MS Access angelegte leere
Datenbank exportiert (Export to Geodatabase) werden. Das gleiche geschah mit der Linien1
Ich führe hier die einzelnen Befehle auf, da die Suche nach den richtigen Funktionen recht mühsam war. Dies will ich dem
interessierten Leser, der vor ähnliche Probleme gestellt ist, ersparen. Alle Befehle müssen im Kommando-Fenster manuell
eingeben werden. Eine Menü-Steuerung ist nicht vorgesehen.
11
Coverage, die als Ausgangspunkt für die Ableitung der Höhen verwendet wurde. Mit MS Access
konnten wir dann auf einfache Weise für die einzelnen Kanten, deren "Knoten-Höhe" wir bestimmt
hatten, die Steigung berechnen. Ohne MS-Access, also ein externes Programm, wäre dies kaum
möglich gewesen.
Zwischenstand:
Wir hatten jetzt räumliche Daten, Attributdaten mit ObjektID-Stadt Bonn und Attributdaten mit
ObjektID-Arc Info:
Coverage-Table
FID:
Object:
1
line
2
line
...
Attributdaten:
ObjektNr
Straßenname
L1002_23
Nußallee
L2434_1
Endenicher Allee
...
Radweg:
12
23
Length:
12,56
25,76
ObjektNr
L1002_23
L2434_1
...
...
...
...
...
...
Steigungs-Attributdaten:
FID:
Steigung:
1
1,672
2
-0,567
...
...
...
...
Um die Daten nun endgültig zu verknüpfen, wurden die Datenbanken in ein dbase-Format
konvertiert. Mit dem Programm ArcView ließen sich dann Tabellen und räumliche Daten verbinden.
Dabei kam ein neuer shape-File mit den räumlichen Daten und deren Attributen heraus:
Neuer shapeFile:
FID:
Object:
1
line
2
line
...
Length:
12,56
25,76
ObjektNr
L1002_23
L2434_1
Straßenname:
Radweg:
Nußallee
12
Endenicher Allee 23
Steigung:
1,672
-0,567
...
...
...
Ein shape-File hatte nun jedoch den Nachteil, daß keine Topologie vorlag, d.h., die ersten Schritte
der Topologie-Erzeugung mußten wiederholt werden. Da wir in unserer Bearbeitung nicht alles so
klar durchführen konnten, wie hier beschrieben, mußten wir die Vorgänge jedesmal wiederholen,
wenn neue Attributdaten anzuhängen waren!
Zwischenstand:
Nach erneuter Topologieerzeugung hatten wir nun die Daten fast so, wie sie sein sollten. An allen
Kanten hingen die nötigen Attribute und der räumliche Bezug war vorhanden. Die Topologie war
vorhanden.
Topologie-Verfeinerung:
Ein Problem bei der Erzeugung der Topologie ergab sich naturgemäß bei Kreuzungen von Kanten,
die in der Natur keine Kreuzungen, sondern Überführungen sind. An diesen Punkten kann man
nicht, wie die einfache Topologie es vorgibt, "abbiegen".
Um dieses Problems Herr zu werden, wurden alle Brücken gesucht und die entsprechenden
Kanten bearbeitet. Uns war und ist jedoch nicht bekannt, ob bzw. wie man Kanten einer coverage
verändern kann. Wichtig war auch, daß sich nicht nur das "Bild" ändert, sondern auch die
Topologischen Daten und Attribute (Knoten Anfang, Ende, Länge) geändert werden.
Aus diesem Grund wurde die coverage erst einmal in eine Geodatabase von ArcInfo importiert.
Diese ließ sich dann bearbeiten. Ein weiterer Nebeneffekt zeigte sich darin, daß hier in der
Datenbank die überflüssigen Gemeindegrenzen herausgefiltert werden konnten. Es befanden sich
jetzt tatsächlich nur noch Straßen und Wege in unserem Netz.
Glücklicherweise waren in dem fünften shape-File Brückensymbole verzeichnet. Die Aufgabe
bestand nun darin, dieses shape-File über unsere "Datenbank"-coverage zu legen und die
entsprechenden Kanten zu verändern. Das shape-File mit den Brückensymbolen diente nur zur
Orientierungshilfe. Autobahnen und deren Zu- und Abfahrten sind im Vergleich mit dem
interaktiven Stadtplan der Stadt Bonn lokalisiert worden.
Die Änderung der Knoten-Kanten-Beziehungen in der Geodatabase erfolgte grafisch mit ArcMap.
Der Editor wird gestartet aus der Symbolleiste Editor unter „Edit à Start Editing“. Nach Auswahl
einer Kante werden im Attribut-Fenster der Name der Kante, die Attribute und deren Werte
angegeben. Die Werte, z.B. #FNODE und #TNODE (Anfangs- und Endknoten) können nun per
12
Hand verändert werden. Das Verschmelzen mehrerer Kanten zu einer erfolgt mit der Funktion
„merge“. Dabei ist aber zu beachten, daß die Attribute und Daten der im Attribut-Fenster oben
stehenden Kante übernommen werden und die restlichen ausgewählten Kanten darunter samt
Inhalte gelöscht werden, d.h., die Änderung von Anfangs- und Endknoten erfolgt nur an der in der
Liste oben stehenden Kante (siehe Bilder: links: vor Verschmelzung, rechts: danach). Dagegen
wird aber das Attribut „shape-length“ neu berechnet, (hier nicht mit aufgelistet).
Abbildung 3: Situation vor der Bereinigung:
Die Brücke besteht aus zwei Kanten.
Abbildung 4: Situation nach der Bereinigung:
Die Brücke besteht nun nur noch aus einer
Kante. Ein Abbiegen ist auf der Brücke nicht
mehr möglich.
Die Speicherung der Editierung hatte zur Folge, daß in der Geodatabase einzelne Attribute
ausgewählter Kanten verändert bzw. ganz gelöscht wurden. Dies alles geschah in mühsamer
Handarbeit.
Hier zeigte sich hier eines der größeren Probleme:
Da sich durch die Brücken die Länge von Kanten verändert hat, müßte auch die Steigung neu
gerechnet werden. Dies würde aber nur in Access funktionieren. Dann hätten wir aber wieder eine
Tabelle/Datenbank, die wir an räumliche Daten heften müßten. Dies würde nur mit ArcView
möglich sein, das unsere Topologie wieder zerstört, womit die Brücken wieder falsch dargestellt
würden ...
Es gab also gewissermaßen kein Zurück mehr. Die Änderung von Attributen war mit normalem
Aufwand nicht möglich. Es ist aber durchaus möglich, daß ArcInfo in seinen tiefen Regionen noch
irgendwo diverse Funktionen bereithält. Diese sind aber dann, wie vieles, gut versteckt.
Da wir mittlerweile ein gewaltiges Arbeitspensum zu bewältigen hatten, ließen wir die
Steigungsungenauigkeiten im Brückenbereich zu, ohne uns weitere Tage in das Problem zu
vertiefen.
Auch der Problematik von Einbahnstraßen haben wir uns aufgrund des Zweckes des Projekts
(Fahrradkarte) nicht gewidmet.
Nachdem wir die Topologie nun richtiggestellt hatten, wurden die coverages in die endgültige
Geodatenbank importiert. Die weiteren Schritte werden später erläutert.
Rasterdaten:
Da die Gestaltungsgruppe im Bereich der großmaßstäbigen Karten mit Rasterdaten arbeiten
wollte, war es nötig, entsprechende Daten zur Verfügung zu stellen:
Neben den Vektordaten wurden uns vom Landesvermessungsamt NRW auch Rasterdaten zur
Verfügung gestellt. Die Rasterdaten lagen in Form der CD-ROM „TOP 10 NRW/Südwest“ vor. Für
Aufbereitung und Bildschirmdarstellung der Karten ist das patentrechtlich geschützte Verfahren
GEOGRID® for Windows der Firma DORNIER GmbH eingesetzt worden. (Die Daten liegen nicht
in einem gängigen Bildformat vor.)
Um die Rasterdaten als Hintergrundinformationen in unserem Projekt verwenden zu können,
mußten diese als gängiges Bildformat, wie GIF, TIFF, JPEG oder BMP vorliegen.
13
Dazu wurde aus der TOP 10 für den Bereich Bonn und Umgebung das Kartenbild „kachelweise“
mit mehreren Hundert Screenshots nach CorelDRAW exportiert.
Abbildung 5: Rasterkartenausschnitt
Hier konnten die einzelnen Screenshots pixelgenau aneinandergefügt werden, so daß schließlich
ein komplettes Bild des uns interessierenden Bereiches entstand, welches im BMP Format
abgespeichert werden konnte.
Die Rasterkarte wurde als Hintergrundinformation benötigt, sie sollte im GIS hinterlegt werden.
Dazu mußte das Bild einen räumlichen Bezug zu anderen (Vektor-) Daten haben, es mußte
georeferenziert werden.
Das Bild lag zunächst in Form von Rasterdaten vor, d.h., jede Rasterzelle hatte eine Bildkoordinate
aus Zeilen- und Spaltennummern. Um das Bild zusammen mit shape-Files, die in Weltkoordinaten
abgespeichert sind, anzuzeigen, benötigte man eine Transformationsvorschrift zur Umrechnung
der Bildkoordinaten in Weltkoordinaten. Die Transformationsvorschrift wird dann üblicherweise mit
dem Bild vorgehalten. Einige Bildformate, wie z.B. ERDAS, IMAGINE und GeoTIFF speichern die
Georeferenzinformation im headerfile der Rasterbilddatei. Bei anderen Bildformaten, wie GIF,
TIFF, JPEG oder BMP wird die Transformationsvorschrift in einer separaten ASCII-Datei abgelegt,
welche als “world“-Datei bezeichnet wird, da sie die Umrechnung in Weltkoordinaten enthält. Die
Bilddatei und der worldfile haben den gleichen Namen, der worldfile erhält ein “w“ am Ende der
Kennung. Durch diese Konvention kann die Transformationsvorschrift dem Bild zugeordnet
werden. Der worldfile wird jedesmal benutzt, wenn das Bild angezeigt wird, so daß eine
georeferenzierte Darstellung möglich ist.
Konkret enthält der worldfile Informationen über eine affine Transformation (6 Parameter
Transformation).
Der worldfile kann mit dem Arc/Info-Kommando REGISTER erzeugt werden.
Beim Georeferenzieren sind wir folgendermaßen vorgegangen:
Zunächst wurde das zu georeferenzierende Bild geladen (die BMP von Bonn und Umgebung),
anschließend wurde ein bereits georeferenzierter shape-File geladen. Im nächsten Schritt mußten
die Paßpunkte gesetzt werden, und zwar zuerst im Bild, dann im shape-File. Bei der Auswahl der
Paßpunkte haben wir eine gleichmäßige Verteilung über das Bild angestrebt und nur solche
Objekte gewählt, die relativ eindeutig zu identifizieren waren (Autobahnauffahrten und
Straßenkreuzungen). Insgesamt haben wir etwa 15 Paßpunkte gesetzt. In einer Paßpunkttabelle
werden die sich bei der Transformation ergebenden Standardabweichungen der Punkte angezeigt.
Hier fiel uns auf, daß einige Punkte eine recht große Standardabweichung aufwi esen. Es bestand
jedoch die Möglichkeit, die schlechten Paßpunkte auf „OFF“ zu setzen und die Transformation
erneut zu bestimmen. Nach Akzeptanz der Standardabweichungen wurde der worldfile in das
Verzeichnis des Bildes geschrieben.
Die Rasterkarte konnte nun als Ganzes an die Gruppe Gestaltung abgegeben werden.
14
Interessante Punkte ("points of interest"):
Da wir in unserer Karte nicht nur Wege und Straßen, sondern auch Sehenswürdigkeiten und
Informationsmöglichkeiten darstellen wollten, war es auch nötig, Daten über diese Punkte zu
sammeln. Einen großen Teil der Daten bekamen wir hier wiederum von der Stadt Bonn. Diese
Daten hatten den großen Vorteil, daß die Punkte, obwohl sie in einer Access-Datenbank
gespeichert, bereits koordiniert waren.
Mit ArcView läßt sich eine dbase-Tabelle über Angabe der Koordinatenspalten in ein Punkt-shapeFile umwandeln. Nach der Transformation MS Access -> dbase erhielten wir nun also ein shapeFile, daß wir in eine coverage umwandelten und georeferenzierten.
Da uns der Umfang der Daten nicht ausreichend erschien und wir die Daten um einige Attribute
ergänzen wollten, gingen wir dazu über, eigene Informationen zu sammeln.
Diese wurden dann mit den Daten der Stadt Bonn mit dem ATKIS-Katalog, TK 50 & TOP 50,
allgemeinen und privaten (Generalanzeiger) Branchenverzeichnissen, VRS-Fahr- und
Schiffahrtsplänen verglichen und gegebenenfalls ergänzt.
Es entstand nun eine 30-seitige (120 KB starke) Datensammlung mit Adressen, Telefon-Nummern,
Öffnungszeiten, Eintrittspreise über:
- Info & Hilfe: Fahrradgeschäfte, Krankenhäuser, Notdienste, Bibliotheken, Zeitungen
- Kulturelles: Kinos, Museen, Theater
- Sehenswertes: Sehenswürdigkeiten, Aussichtspunkte, Grün- und Parkanlagen
- Sport & Kinder: Bademöglichkeiten, KinderSpecials
- Parkplätze und Verkehrsverbindungen von Deutscher Bahn AG, U- und S-Bahnen,
Fährverbindungen und Schiffahrtslinien (Köln-Düsseldorfer, BonnerPersonenSchifffahrt, Siebengebirgslinie).
Mit Access wurden die Stadtdaten erst ergänzt und dann noch einmal transformiert. Leider war es
uns nicht so ohne weiteres möglich, zu den sonstigen Informationen Koordinaten zu erhalten. Es
besteht zwar Hoffnung, daß die Stadt uns Koordinaten zu abgegeben Punkten zukommen läßt,
doch scheint dies noch eine Weile in Anspruch zu nehmen.
Letztendlich können wir jedoch mit einer großen Menge von Punkten, von Schulen, Behörden,
Sehenswürdigkeiten bis hin zu Notfallzentren aufwarten.
Alle Daten wurden schließlich in die Geodatenbank integriert.
Aufbau der Geodatenbank:
Zur letztendlichen Speicherung und Verwaltung aller Daten wurde eine Geodatenbank aufgebaut.
Dieser letzte Schritt war mühsamer, als es zunächst schien. Das Arbeiten mit einer großen Zahl
von Daten (Kanten) erfordert viel Zeit und Vertrauen. Während ArcInfo mit bis zu 60.000 Kanten
arbeitet, kann es vorkommen, daß der Rechner bis zu ¼ Stunde keine Reaktionen zeigt. Lange
Versuche zeigten erst, daß keine Fehlfunktion vorliegt. Ein weiterer fataler Nachteil von ArcInfo
zeigte sich im Verhalten nach einem programmtechnischen Abbruch (Prozeß-Beendung) während
des Arbeitens in der Datenbank. Diese war danach oft zerstört und ließ sich nicht mehr öffnen. Es
ist daher zu empfehlen, mit einer ausreichenden Zahl von Sicherheitskopien zu arbeiten.
Die Geodatenbank gliedert sich grob in die verschiedenen topologischen Elemente ("feature
datasets").
Im ersten dataset wurden die Flächen abgelegt, sortiert nach Art der Fläche, je nach Anforderung
der Gestaltungsgruppe (="feature classes")
Im zweiten Bereich wurden einmal alle Linien zusammen abgelegt und alle Linien, sortiert nach
Straßenart, ebenfalls je nach Anforderung der Gestaltungsgruppe. Der Teil mit allen Straßen wurde
für die Navigationsgruppe angelegt.
Im dritten Bereich befinden sich alle Punktobjekte, auch hier getrennt nach Art.
15
Jeder dieser einzelnen "feature-classes" läßt sich problemlos als shape-File exportieren.
Die exportierten shape-Files erhielt die Gestaltungsgruppe. Sie sind grafische Grundlage der Karte
und beinhalten zwar keine Topologie, aber alle Attribute.
Abbildung 7: Die einzelnen feature-classes mit ihren Attributen.
Abbildung 6: Die einzelnen feature
classes in der Übersicht
2.3.1.5. Ergebnisse
Die Gruppe Gestaltung erhielt von uns:
Flächen = Nutzungsarten als shape-Files
Linien = Straßen als shape-Files
Punkte = points of interest als shape-Files
Die Attribute sind direkt an das Objekt gebunden und können so aufgerufen werden.
Außerdem erhält die Gruppe Gestaltung eine Rasterkarte des Stadtgebietes in Form eines
Bitmaps.
Die Gruppe Navigation erhält von uns:
Eine Datenbank in MS-Access Format, in der alle Kanten mit vollständigen Attributen
gespeichert sind.
Eine Liste aller Knoten mit ihren Koordinaten für das GPS-System.
Für die weitere Bearbeitung und Fortführung sind alle Vektordaten in einer Geodatenbank abgelegt
und können von dort aus leicht bearbeitet oder in andere Formate transformiert werden.
16
2.3.1.6. Resümee:
Das Arbeiten im Bereich der Datenaufbereitung stellte uns vor eine Vielzahl von
Herausforderungen und forderte viel Flexibilität.
Dies hängt einmal mit der Vielzahl der verschiedenen Daten und Formaten zusammen, die im
Laufe des Projekts auch einem ständigen Wechsel unterlagen. So kamen wir mit Datenformaten
von ATKIS bis EXCEL in Berührung. Der Umgang und der sinnvolle Einsatz von diesen erfordert
viel Experimentieren. Der Wandel der Daten (ATKIS, gdf, Informix) führte auch zu einem ständigen
Neubeginn des Arbeitens bei jedem Wechsel. Dies war sehr zeitaufwendig und forderte nicht
zuletzt viel Geduld.
Ein ähnliches Bild ergibt sich im Bereich der eingesetzten Software. Auch hier waren mußten wir
sehr flexibel reagieren. Während wir uns mit einem Programm befaßten (SupportGIS + Visual
Basic), wurde schon der Einsatz eines neuen sichtbar (ArcInfo).
Für jeden Teilbereich unseres Arbeitens mußte erst ein Weg gefunden werden um mit den
spezifischen Daten umzugehen:
Zum Beispiel mußte für die Rasterkarte die TOP10-CD gefunden werden. Mit CorelDraw wurden
die Bilder aneinandergefügt, mit ArcInfo georeferenziert.
Die Daten für unsere Sehenswürdigkeiten wurden mit Excel gesammelt, als dbase-File
gespeichert, mit ArcView transformiert, um sie in ArcInfo abzulegen.
Dies fordert viel Arbeitsaufwand (Ausprobieren) und Geduld.
Das Arbeiten mit ArcInfo, so gut das Programm auch ist, hat einige Tücken. Die Dokumentationen
zu den Funktionen des Programms sind äußerst dürftig. Der Umgang erfordert einige Erfahrung
und Abstürze (s. Datenbank) können verheerende Auswirkungen haben. Der Umgang mit
Topologien (s. ArcView) macht es dem Benutzer auch nicht leicht.
Unsere Arbeit im Bereich der Datenaufbereitung hat gezeigt wie vielschichtig und schwierig der
Umgang mit verschiedenen Datenformaten sein kann.
In einem perfekt geplanten Projekt hätte auch die Struktur der Datenbank und die Vorgehensweise
bekannt sein müssen, denn das Arbeiten mit Topologien in ArcInfo erfordert eine bestimmte
Reihenfolge. Da die Art und der Umfang der Daten jedoch nicht bekannt war, war dies nicht
möglich.
Trotzdem hat das Projekt gerade durch die diversen Schwierigkeiten und die Vielzahl von
Programmen und Daten, mit denen wir gearbeitet haben, die Gruppe motiviert und einen Einblick
in die Problematik geöffnet.
2.3.1.7. Die Gruppenmitglieder und ihre Aufgabenfelder:
Olaf Bromorzki:
Suche von externen Informationen (Sehenswürdigkeiten)
DGM-Konvertierung und Import
Aufbereitung der Radweg-Daten
Straßennamen-Angleichung
Erweiterte Topologie der Vektordaten ("Brückenproblematik")
Enrico Kurtenbach:
grundsätzliche Planung und Vorgehen
ArcInfo-Bearbeitung der Daten
DGM-Konvertierung, Impor t, Steigungsberechnungen
(GPS-Koordinaten)
Andreas Neuenhausen:
DGM-Konvertierung und Import
Bestimmung von Steigungen
Jens Stenger:
Rasterdaten (Screenshots & Bearbeitung)
Rasterdaten Georeferenzierung
Rasterdaten-Import
17
Carsten Szidzik:
Suche von externen Informationen (Sehenswürdigkeiten)
Aufbereitung der Punkt-Daten
Suche von externen Informationen (Radwege)
Aufbereitung der Radweg-Daten
Mathias Thelker:
grundsätzliche Planung und Vorgehen
Vektordaten
Geodatenbank
ArcInfo-Bearbeitung der Daten
Kontakt zu Stadt Bonn
18
2.3.2. Gruppe Navigation
2.3.2.1. Allgemeine Ziele, Gruppenzusammensetzung, Arbeitsaufteilung
Die Arbeitsgruppe Navigation hatte zur Aufgabe, die eigentliche Routenplanung, die GPS-Anbindung
und die Generierung der Höhenprofile zu analysieren, zu entwickeln und zu programmieren.
Die notwendigen Daten wurden uns im gewünschten Format von der Gruppe Daten zur Verfügung
gestellt, die Gruppe Technik hat unsere Entwicklungen in das Gesamtkonzept integriert und alle
technischen Probleme gelöst.
Zur Realisierung dieser Ziele haben wir uns die Arbeit folgendermaßen aufgeteilt:
Georges Audry:interne Koordination, Höhenprofil
Thorsten Berka:
Kantengewichtungsfunktion, Travelling-Salesman-Problem
Sascha Rudolph:
Programmierung der Routenplanung und aller Nebenprodukte
Heiko Stumm:
GPS-Anbindung
Frank Weydert: GPS-Anbindung
Es folgen die Berichte der einzelnen Arbeitsbereiche.
2.3.2.2. Programmierung
Von den ersten Ideen zur konkreten Umsetzung
Zunächst haben wir uns Gedanken über den Ablauf der Wegsuche inkl. der Interaktionsmöglichkeiten
des Nutzers gemacht, um daraus Anforderungen an den zu entwickelnden Algorithmus, sowie an die
benötigte Datengrundlage, formulieren zu können. Wir waren uns sehr schnell einig darüber, dass wir
die Wegsuche nicht auf eine einfache Bestimmung des kürzesten Weges zwischen 2 Punkten
beschränken wollten, sondern dem Nutzer die Gelegenheit dazu geben möchten, eine Route mit
mehreren Stützpunkten berechnen zu lassen, wobei dieser die Gewichtung der einzelnen Strassen je
nach ihren Attributen bei der Routensuche beeinflussen können sollte.
Dies führte dazu, dass es die ersten intensiven Gespräche mit der Datengruppe gab, um die
Möglichkeiten zu eruieren, über die Weglänge hinausgehende Informationen zu den einzelnen
Strassen bekommen zu können. Dabei haben wir uns bereits auf das RDBMS MS Access als
Datenbank für das Wegenetz und die Attribute der Strassen festgelegt, da es universell via ODBC von
sämtlichen zur Diskussion stehenden GIS – Systeme angefragt werden kann.
Weiterhin haben wir uns bereits auf ein schlichtes Kanten-Knoten Modell zur Speicherung des
gerichteten Weggraphen festgelegt.
Bei der Auswahl eines zweckmäßigen Algorithmus haben wir uns letztlich für den allgemein
bekannten Algorithmus von Danzig & Dijkstra entschieden, da ein näherungsweise optimal
arbeitender TSP – Algorithmus zu zu langen Rechenzeiten geführt hätte und uns für eine erste
Version zu aufwändig zu programmieren erschien.
Der Danzig & Dijkstra Algorithmus stellt an den Nutzer allerdings die Anforderung, die einzelnen
Wegpunkte seiner Route in der gewünschten Reihenfolge auszuwählen, zwischen denen im
Anschluss jeweils der kürzeste Weg berechnet wird.
In der Folge wurden eine Reihe von programmtechnischen Lösungen realisiert, wobei allen gemein
ist, dass zunächst bei Start des Programms der gesamte Graph aus einer Access – Datenbank in den
Arbeitsspeicher geladen wird.
Zur Demonstration der zu erwartenden Rechenzeiten und zu ersten Prüfungen, ob unser Vorhaben
zügig zu realisieren ist, haben wir zunächst eine Applikation in AutoCAD implementiert.
Erster Lösungsansatz: VBA – Programm als Applikation in AutoCAD
Die implementierte Oberfläche lässt sich direkt aus einem von uns erzeugten, zusätzlichen Pull-DownMenü aufrufen. Anschließend wird das gesamte Wegenetz aus der zuvor auszuwählenden Datenbank
ausgelesen und in AutoCAD dargestellt. Der Datenbankzugriff erfolgt bei dieser Lösung via ADO 2.5
und zeichnet sich durch eine hohe Performance aus. Anschließend befindet sich der gesamte Graph
im Arbeitsspeicher. Nach Auswahl von Anfangs- und Endknoten lässt sich der kürzeste Weg
berechnen und in der Graphik highlighten.
19
Bei dieser Erstlösung bestand noch keine Möglichkeit, eine Route mehrerer Punkte zu errechnen. Um
die Wegsuche universell einsetzbar zu machen, haben wir uns zu einer ersten Weiterentwicklung
entschieden und haben eine ActiveX - DLL programmiert, die in sämtliche VB - Programme aber auch
in ASP- Seiten eingebunden werden kann.
Zweiter Lösungsansatz: VB – ActiveX - DLL (Dynamic Link Library)
Die Umstellung der zunächst in VBA in der VBA- Umgebung in AutoCAD programmierten Lösung auf
eine VB – DLL ist technisch zwar ein großer Schritt, jedoch sind die beiden Sprachen weitestgehend
identisch, so dass der Quellcode nicht stark verändert werden musste. In diese Lösung wurde
erstmals auch die Gewichtsfunktion zur benutzerspezifischen Errechnung der Kantengewichte
implementiert. Das bedeutet, dass es dem Nutzer möglich ist z.B. bevorzugt Strecken großer oder
geringer Steigung wählen, oder besonderen Wert auf die Existenz von Radwegen entlang der Route
legen kann. Folge ist, dass die Minimierungsaufgabe, die mit dem Algorithmus gelöst werden soll, sich
nicht ausschließlich auf die Distanz, sondern auf ein Kantengewicht beschränkt. Dieses wird mit Hilfe
einer individuell vom Nutzer in gewissen Schranken vorzugebenden Funktion, die auf die Attribute der
einzelnen Kanten angewendet wird, errechnet.
Nachdem die Entscheidung für das zu verwendende GIS-System endgültig zu Gunsten von ArcInfo
gefallen war, hat uns die Gruppe Technik zunehmend gedrängt, eine Java – Lösung zu
programmieren, da sie nur so eine Möglichkeit zur Erstellung eines lauffähigen Gesamtsystems in
Verbindung mit dem ArcIMS sah.
Unterstützt wurde Sie dabei von Prof. Plümer, dem es schon aus didaktischen Gründen wichtig war,
eine rein Java – basierte Lösung zu entwickeln.
Da niemand in unserer Gruppe jemals objektorientiert, geschweige denn in Java programmiert hatte,
bedurfte es zunächst einer Einarbeitung, um ein halbwegs performantes Programm erstellen zu
können.
Lösung: Java – Klassen zur Wegsuche
Konzeptionell hat sich durch die Umstellung auf Java nicht viel geändert. Es wurde eine Klasse
„Wegsuche“ erstellt, in der sowohl die Daten der Access – Datenbank via JDBC geladen werden, als
auch die Wegberechnungen durchgeführt werden. Dabei greift diese Klasse auf die ebenfalls von uns
programmierten Kanten- und Knoten - Klasse zu, in denen, möglichst optimal, der Graph vorgehalten
wird und in die einige Methoden zur Unterstützung der Wegsuche implementiert wurden.
Die Wegsuche - Klasse liefert, nachdem eine Punktliste und die Parameter für die Gewichtsfunktion
an sie übergeben worden sind, den optimalen Weg in Form einer geordneten Liste von KantenID´s an
das aufrufende Servlet zurück.
Weiterhin ist es möglich eine Punktliste mit Koordinaten aller Knoten, die auf dem Weg liegen, im
NMEA und im PCX5 – Format in Form eines String – Arrays zurückzugeben, der mit Hilfe des von der
Gruppe Technik entwickelten Servlets in einer Datei abgelegt wird, die der Nutzer herunterladen und
in einen GPS – Empfänger einlesen kann (vgl. 5).
Des Weiteren wird ein Java Script - String mit den Knotenkoordinaten erzeugt, der direkt in die
ebenfalls von der Gruppe Technik erzeugte HTML – Seite geschrieben werden kann. Dieser String
enthält den Aufruf des Java - Applets, das zur Darstellung eines Steigungsdiagramms verwendet wird
(vgl. 4). Dabei wird die Größe des Applets in Abhängigkeit der Routenlänge und des
Höhenunterschieds dynamisch festgelegt.
2.3.2.3. Kantengewichtungsfunktion, Travelling-Salesman-Problem
Vorgehensweise:
1.) Sammlung der benötigten Attribute
2.) Aufstellung der Bedingungen, welche die Funktion erfüllen soll.
3.) Ermittlung einer Einstiegsfunktion (Nicht wichtig, nur der
Vollständigkeit halber)
4.) Vorläufig endgültige Funktion
5.) Probleme
6.) Überlegung zum TSP
20
Sammlung der benötigten Attribute
Hierbei werden die Eigenschaften gesammelt, nach denen Radfahrer gewöhnlich ihre Fahrtroute
aussuchen:
Bereich Anstrengung: Streckenlänge, Steigungen
Bereich Sicherheit:
Beleuchtung, Verkehrsdichte, Straßenbelag
Bereich Umgebung:
Gewässer, Natur
Aufstellung der Bedingungen, welche die Funktion erfüllen soll
Diese Bedingungen sind notwendig, um die Effizienz einer Funktion beschreiben zu können. Wichtig
ist das in erster Linie bei dem Vergleich zweier Alternativen:
Bereich Komplexität:
Anzahl der notwendigen Berechnungen, Übersichtlichkeit,
Segmentbildung (Jedes einzelnes Attribute kann dadurch entfernt werden
bzw. neue können später hinzugefügt werden.)
Bereich Ergebnisgüte: Möglichkeit der Gewichteverteilung, gleicher Einflußbereich aller
Attribute, anschaulich gute Ergebnisse (erst bei Laufen des Planers
möglich)
Ermittlung einer Einstiegsfunktion
Kosten = A * B * C * D * E * F * G
Segmente:
A = Entfernung => Entfernung * Bewertungskoeffizient
B = Verkehrsaufkommen (siehe C)
C = Natur =>vTypzahl^Bewertungszahl (<= Bewertungskoeffizient)
D = Fluß (siehe C)
E = Beleuchtung (siehe C)
F = Straßenzustand (siehe C)
G = Steigung => (0,00005 * Steigung(%)^3 + 0,005 * Steigung(%)^2
+ 0,05 * Steigung(%)^1 + 1) * Bewertungskoeffizient
wobei die Bewertungszahl vom Benutzer als Maß seines persönlichen Interesses an bestimmten
Eigenschaften, welche die Route haben sollte, ist.
4
3
2
1
0,5
und
Tabellen
werden, z. B. für
Straßenbelag:
: darauf legt man sehr viel Wert
: darauf legt man viel Wert
: darauf legt man Wert
: das ist einem egal
: lege Wert auf Gegenteil
Typzahlen:
Belagtyp:
Skala 1:
Asphalt (gut)
1
wassergebunden (gut) 1,5
Asphalt (mittel)
2
Asphalt (schlecht)
2,5
wassergeb. (schlecht) 3
Skala 2 (Alternative):
1
2
2
3
3
Typzahlenaus
zugeordnet
den
21
Vorläufig endgültige Funktion
Kostenfunktion:
Typzahlen
Alternativ-Typz.
Verkehrsdichte
Natur
Gewässer
Beleuchtung
Straßenbelag
Steigung
1
1
Keine(Fahrradweg abgetrennt)
Wald
See/Fluß(naturbelassen)
gute
Asphalt(gut)
Betrag<5%
1,5
1
gering
Wiese
See/Fluß(künstlich)
-
wassergebunden(gut)
Betrag<10%
Betrag<15%
2
2
mittel
Acker
Bach(naturbelassen)
schlechte
Asphalt(mittel)
2,5
3
hoch
Urban
Bach(künstlich)
-
wassergebunden(schlecht)
Betrag<20%
3
3
gewaltig
Industrie
kein Gewässer
keine
Asphalt(schlecht)
Betrag>=20%
Bew.-zahlen
Alternativ-Bewer.-z.
Bewertungsangabe
Formel:
-0,5
-
eher andersrum wäre mir lieb
Summe[Typzahl(i) * Bewertungszahl(i)] * Strecke * Steigungskoeffizient
0
0
ist mir egal
1
1
wäre schon ganz nett
Steigungskoeffizient:
2
-
fänd ich schon gut
0,0000005*-Stei.^4 + 0,00003*-Stei.^3 + 0,001*-Stei.^2 + 0,04*-Stei. + 1
4
3
auf jeden Fall
Spezielles: 1.) Fahrradweg auf Straße => Eine Verkehrsdichtestufe weniger.
2.) Asphalt(mittel) = wassergebunden(mittel) = Kopfsteinpflaster
3.) schlechte Beleuchtung ist auch Beleutung, die nur temporär eingeschaltet ist.
4.) Fähre zählt wegen durchschnittlicher Warte- und Fahrzeit als fünffache Strecke der Flußbreite, und ist in allen Eigenschaften als optimal zu bezeichnen.
Probleme
Das große Problem liegt darin, den Steigungen passende Gewichtungen in der Formel zuzuordnen.
Die Bewertung, wie sehr man Wert auf flache Strecken legt, bleibt dabei genauso wie bei den anderen
Eigenschaften. Dazu kommt aber noch der physikalische Teil. Die Schwi erigkeit resultiert nun aus der
Komplexität der anzuwendenden physikalischen Formel. Dazu benötigt man nämlich die Kraftarbeit,
die der Fahrer leistet, sein Gewicht, das Gewicht des Rades, u.s.w.. Da aber kaum ein Fahrer alle
diese Eigenschaften kennt, und die Funktion dadurch auch noch übertriebener Maßen komplexer
würde, bleibt nun nichts anderes übrig, als eine gute Approximation zu finden. (=> Steigungkoeffizient)
Diese hat selbst auch noch einige logische Bedingungen zu erfüllen, wie z.B.:
Eine Strecke über einen „flachen“ Berg ist der gleichen über einen höheren Berg bei selben
Anfangs- und Endpunkt vorzuziehen, u.s.w..
Traveling Salesman Problem
Wurde nach dem Brainstorming nicht mehr weiter vertieft, da die Einführung eines Algorithmus zum
TSP in den Routen-Planer auf Grund der schon bestehenden Probleme unrealistisch geworden ist.
2.3.2.4. Höhenprofil
verfolgtes Ziel, Aufbau, zu beachtende Punkte
Ziel war es, von der jeweils berechneten Route ein Höhenprofil zu generieren, anhand dessen der
Nutzer eine Vorstellung über die Steigungsverhältnisse in der vorgeschlagenen Route gewinnen kann.
Das Aussehen solcher Höhenprofile ist den Radsportbegeisterten wohlbekannt, wie z.B. bei der Tourde-France:
22
Der eigentliche Aufbau so eines Profils ist sehr einfach und läßt sich mit einigen Schritten
implementieren:
- Während der Routenberechnung eine Liste der besuchten Punkte anlegen:
- 1. Spalte: Distanz vom Anfangspunkt aus: di = di-1 + Kantenlänge
- 2. Spalte: Höhe des Punktes
Diese Liste muß dann an ein geeignetes Programm zur Grafik-Erzeugung übergeben werden. Dabei
muß sichergestellt werden, daß das Profil immer mit der gleichen Überhöhung dargestellt wird.
Kartographisch hat sich die Skalierung 1:10 für das x:y-Verhältnis bewährt. Wird dies nicht konsequent
eingehalten, kann es vorkommen, daß eine flache Route durch ungünstige Darstellung profilreicher
wirkt als eine Route mit viel Steigung und Gefälle.
Es wurden zwei Lösungsansätze entwickelt.
Erster Lösungsansatz: mit Hilfe von MS EXCEL
Der erste Ansatz beruht darauf, daß dem Nutzer eine Datei übergeben wird, mit der er sich das Profil
selbst erstellen kann: Durch Anklicken des entsprechenden Links wird MS Excel automatisch gestartet
und öffnet die ASCII-Datei, welche die weiteren Anleitungen sowie die zur Route passenden
Zahlenwerte enthält.
Vorteile:
- viele Möglichkeiten der graphischen Detailverarbeitung
- Nutzer kann das Aussehen selbst beeinflussen
- schneller und geringer Datentransfer, auch bei langsamer Modem-Verbindung
Nachteile:
- Nutzer muß MS WINDOWS und MS EXCEL installiert haben
- Nutzer muß mehrere Anleitungen befolgen, bevor er ein Resultat erhält
- Probleme bei unterschiedlichen Browsern: automatisches Datei-Öffnen bei NETSCAPE durch
teilweise anderen Befehl als bei MS EXPLORER
Das Resultat könnte folgendes Aussehen haben:
23
Aufgrund der gravierenden Nachteile wurde diese Lösung nicht realisiert.
Zweiter Lösungsansatz: Gebrauch einer existierenden Klasse
Beim Stöbern im Internet wurde eine bereits existierende Klasse gefunden, die das verfolgte Ziel
realisiert: die Darstellung eines Profils aufgrund einer Liste von Abszissen- und Ordinatenwerte.
Vorteile:
- automatische Generierung des Profils
- unabhängig vom Betriebssystem und von den Programmen des Nutzers
- Profil wird gleich neben der Karte angezeigt
Nachteile:
- geringe graphische Möglichkeiten, daher immer spärliches Aussehen
- keine Punkt- oder Kantenbeschriftungen möglich
- aufwendiger Einfluß auf Skalierung der Achsen
- überdimensionales Pop-Up-Fenster
Ein Nachteil dieser Klasse ist, daß die Größe des Profils in Pixelwerten absolut festgesetzt werden
muß. Ein Einfluß auf die Skalierung hat man somit nur über die Länge und Breite des Pop-UpFensters. Demnach müssen während der Routenberechnung die Werte Gesamtstrecke und maximale
Höhe ermittelt werden, je nach Skalierung in Pixelwerte umgerechnet werden und der Klasse
zusätzlich übergeben werden.
Da im Gebiet dieses Routenplaners vorwiegend flache Strecken vorkommen, werden sich die Profile
über mehrere Bildschirmbreiten ausdehnen. Es wäre aber ungünstig, durch die Skalierung der Strecke
das Profil auf einen Bildschirm zu begrenzen, da sonst bei langen Strecken nur noch ein mehrmals
leicht geknickter fast horizontaler Strich zu erkennen ist.
Die Generierung eines Höhenprofils für eine recht kurze Strecke liefert folgendes Resultat:
Diese Lösung wurde nach den beschriebenen Vorschriften ohne größere Probleme implementiert.
24
2.3.2.5. GPS-Anbindung
GPS-Handempfänger erfreuen sich heute immer größerer Beliebtheit. Deshalb ist in diesem Projekt
ebenfalls eine Anbindung an solche Systeme angestrebt worden. Dies hat den großen Vorteil, dass
der Nutzer Punkt für Punkt durch die berechnete Route navigiert werden kann.
Zu Beginn unserer Arbeit musste ein geeignetes, einheitliches Format (Protokoll) gewählt werden. Es
soll möglichst alle auf dem Markt befindlichen GPS-Handempfänger unterstützen. Dabei legten wir
uns zunächst auf das NMEA-Protokoll 0183 (National Marine Electronics Association) fest.
NMEA-Format
NMEA wurde zum Datenaustausch zwischen elektronischen Marine-Mess- und Auswertungsgeräten
entworfen und ist inzwischen ein Standardprotokoll für das Interface vielseitiger Meß- und
Datengeräte, das auf der seriellen Schnittstelle (RS232) aufsetzt. NMEA Informationen sind unterteilt
in Sätze aus jeweils maximal 80 Zeichen. Jeder Satz beginnt mit dem Zeichen '$'.
Beispiel-Datei:
$GPWPL,5043.32,N,0705.28,E,KARTOINSTITUT*2F
$GPWPL,5043.43,N,0705.07,E,NUSSALLEE*21
$GPWPL,5043.39,N,0704.57,E,MENSA*26
$GPWPL,5043.31,N,0705.03,E,SCHUPPEN*7C
$GPWPL,5043.27,N,0705.13,E,CARL-TROLL-STR*7C
$GPWPL,5043.32,N,0705.21,E,KATZENBURGWEG*21
$GPWPL,5043.30,N,0705.27,E,BOTGARTEN*2F
$GPWPL,5043.32,N,0705.28,E,KARTOINSTITUT*2F
Die ersten 5 Zeichen nach dem $ bezeichnet man als Adressfeld. Danach folgen (jeweils durch
Komma abgegrenzt) die Datenfelder.
Die ersten 2 Zeichen des Adressfeldes sind die so genannte Talker-ID, die den Typ des Senders
kennzeichnen (hier GP = GPS-Device). Die folgenden 3 Buchstaben kennzeichnen den Typ (das
Format) des Satzes, d.h. welche Informationen in diesem Satz übermittelt werden (hier WPL =
Waypoint List). Darauf folgen die Datenfelder, welche geographische Koordinaten in die Nord- und
Ostrichtung (N, bzw. E) enthalten und durch Komma getrennt werden. Danach folgt noch eine
Identifizierung des Koordinatensatzes.
Optional kann eine Check-Summe angehängt sein. Diese ist durch '*' vom Satz getrennt und
entspricht der hexadezimalen Darstellung der XOR-Verknüpfung aller Zeichen zwischen '$' und '*'.
Diese kann mit Freeware-Programmen (z.B.: NMEATool, www.nmeatool.de) für unser Beispiel
berechnet und eingesetzt werden. Hierdurch ist gewährleistet, dass die Daten fehlerfrei an den GPSEmpfänger gesendet wurden, da der Empfänger ein weiteres Mal die Check-Summe berechnet und
bei eventueller Nichtübereinstimmung eine Wiederholung der Datenübertragung fordert. Mit Hilfe des
oben genannten Programms kann schließlich die Datei an den GPS-Empfänger überspielt werden.
Nach den theoretischen Überlegungen und dem Erstellen eines Probeprotokolls traten jedoch die
ersten Probleme auf! Das Übertragen der Datei mit verschiedenen Programmen (u.a. Waypoint+,
NMEATool, ...) auf die institutseigenen Garmin-Empfänger (eMap, etrex Summit) war nicht möglich.
Diese Garmin-Empfänger unterstützen nur die NMEA-Ausgabe, nicht aber den NMEA-Import. Daher
war es uns nicht möglich, unsere Probedatei zu testen.
Da wir uns aber bereits stark mit diesem Format beschäftigt hatten und es allgemein als
Standardprotokoll angesehen ist, geben wir zusätzlich die Möglichkeit die Route in diesem Format
auszugeben.
Bei der weiteren Recherche fiel unser Augenmerk vor allem auf das PCX5-Format, das auch die
Garmin-Empfänger zum Import unterstützen.
25
PCX5-Format
Dieses Format erlaubt das Austauschen von Waypoints, Routen und Tracks zwischen PC und GPSHandempfänger. Die wichtigsten Informationen wie Name, Koordinaten, Datum, Höhe und WaypointBeschreibung sind enthalten. Vorteile dieses Formates sind, dass es als Textdatei vorliegt und von
vielen GPS-Programmen unterstützt wird.
Für die Weiterverarbeitung der von uns erzeugten Testdateien (für Routen: *.rte) verwendeten wir das
Programm MapSource der Fa. Garmin. Die Dateien können ebenfalls von anderer PCX5-kompatibler
Software genutzt werden.
Beispiel-Datei:
H SOFTWARE NAME
I Fahrradroutenplaner Bonn
H R DATUM
M E WGS 84
IDX DA
DF
DX
DY
DZ
100 +0.000000e+00 +0.000000e+00 +0.000000e+00 +0.000000e+00 +0.000000e+00
H COORDINATE SYSTEM
U LAT LON DM
R TESTROUTEinhdddmm.mmm
H IDNT LATITUDE LONGITUDE DATE
TIME ALT DESCRIPTION
W 111111 N5045.985 E00708.001 17-AUG-01 09:34:08 -9999 XXXXXXXXX
Jede Zeile beginnt mit einer speziellen Kennung:
H = Header Record (enthält keine Daten, sondern dient nur als Überschrift)
I = Identifikation der Software
M = Map Datum (Datum der Karte)
U = Koordinatensystem
R = Route
W = Wegepunkt
Die Festlegung des benutzten Kartendatums (Zeile 5 im Beispiel) erfolgt durch eine vordefinierte
Identifikationszeile (Zeile 4 im Beispiel). In unserem Beispiel liegt als Referenzsystem R ein Ellipsoid E
im WGS84-Datum vor. Des Weiteren legen IDX die Indexnummer des Kartendatums fest, DA (?
Erdradius), DF (? Abplattung), DX, DY und DZ (? der Ursprungskoordinaten) beschreiben die
Abweichung vom Referenzdatum (WGS84).
Danach erfolgt die Definition des Koordinatensystems (Zeilen 7 und 8). In unserem Fall liegen
geographische Koordinaten mit Länge LON, Breite LAT in Dezimalminuten DM vor.
Ab Zeile 9 beginnt die eigentliche Ausgabe der berechneten Routen. Hierbei werden die einzelnen
Daten jeweils durch ein Leerzeichen getrennt. Es kann neben einer Identifikationsnummer IDNT
(immer 6 Zeichen!) noch das Datum DATE, die Zeit TIME, die Höhe ALT und eine Beschreibung
DESCRIPTION der Wegepunkte festgelegt werden. Bei der Höhe bedeutet der Wert –9999, dass
keine Höhe vorhanden ist.
Trotz der oben genannten Festlegungen können in verschiedenen Software-Programmen Probleme
auftreten, da jede Software sich nicht an die exakt definierten Formate hält. Gegebenfalls muss der
Nutzer selbst kleine Änderungen an der Datei vornehmen. Dies sollte allerdings keine Schwierigkeiten
darstellen, da die Datei im Texteditor gelesen und bearbeitet werden kann.
Beschränkung der Anzahl der Wegepunkte in einer Route
Ein weiters Problem besteht darin, dass bei der Routenberechnung meist sehr viele Wegepunkte eine
Route ergeben. Unnötiger Weise werden neben Richtungswechseln auch auf Geraden alle
26
vorhandenen Knotenpunkte ausgegeben. GPS-Handempfänger können jedoch nur eine begrenzte
Anzahl von Wegepunkten (25 bzw. 50) als Route verarbeiten. Aus diesem Grund, muss eine
Punktreduzierung implementiert werden, wobei die Navigation auf der Route erhalten bleiben muss.
Dazu wird die Knotenliste von Anfang bis Ende durchlaufen und jeweils die Differenz der
i +1
Richtungswinkel t i
i +2
und t i
gebildet. Unterschreitet diese Differenz einen festgelegten Schwellwert,
so kann der mittlere Knoten ( K i +1 ) gelöscht werden. Dabei darf allerdings die Strecke K i Ki +1 nicht
größer als ein vorgegebener Schwellwert (100 m) sein. Ist nach einem vollständigen
Knotenlistendurchlauf die maximal mögliche Anzahl von Wegepunkten überschritten, so werden die
beiden Schwellwerte erhöht und eine erneute Punktreduzierung gestartet.
Dieses Verfahren hat sich nach etlichen Testläufen (mit Anpassen der Schwellwerte zueinander) als
brauchbar erwiesen. Nur bei sehr langen Routen, muss der Benutzer eventuell den Reiseweg in
Teilstrecken unterteilen und mehrere Anfragen starten. Eine Automatisierung dieser Aufgabe konnte
nicht implementiert werden, da die Ausgabe von nur einer Datei vorgesehen ist.
27
.3.3 Gruppe Technik
2.3.3.1 Aufgaben der Gruppe Technik:
Die Aufgabe der Gruppe Technik bestand in der Bereitstellung der Infrastruktur (ArcIMS, Webserver,
Servlet-Engine) und in der Realisierung der Kommunikation zwischen den verschiedenen
Komponenten. Im folgenden soll zunächst ein knapper Überblick über den Aufbau und die
Funktionsweise des ArcIMS gegeben werden, welcher zum Verständnis der darauf folgenden
Beschreibung unserer Tätigkeiten hilfreich ist.
2.3.3.2 Überblick ArcIMS
Komponenten auf Serverseite:
• ArcIMS Application Server Connectors
o Servlet Connector
o ColdFusion Connector
o ActiveX Connector
• ArcIMS Application Server
• ArcIMS Spatial Server
• ArcIMS Manager
Connectors
Stellen die Verbindung zwischen WebServer und ArcIMS-Server her. Diese Komponenten leisten
beim ArcIMS reine Übersetzerdienste. Sie wandeln die Anfrage des Clients in ein für den ArcIMS
verständliches Format (AXL=ArcXML)
• Servlet Connector
Standard-Programm zur Verbindung von ArcIMS mit dem Web-Server. Nutzt die JavaPlattform-Technologie. ArcXML-Anfragen werden unmittelbar an den ArcIMS-Server
weitergeleitet, d.h. es ist keine zusätzliche Übersetzung notwendig. Unter einem Servlet
versteht man generell ein auf dem Server laufendes Javaprogramm, das über den Webserver
angesprochen wird.
• ActiveX Connector
COM-DLL für alle COM-Programme z.B. ASP. Zus. Programme können z.B. in Visual Basic,
C++, Delphi usw. geschrieben werden. Anweisungen werden in ArcXML übersetzt
• ColdFusion Connector
ColdFusion Anweisungen werden in ArcXML übersetzt
Spatial Server
Die Spatial Server sind die eigentlichen „Arbeitstiere“ des ArcIMS. Sie beinhalten die
grundlegenden Funktionen für die Erstellung und den Zugriff auf Karten.
XML-Parser
Diese Komponente parst das AXL-Document, nachdem es vom ServletConnector an den
Application-Server übergeben worden ist und wandelt es in ein vom Computer
bearbeitbares Format um. Informationen eines AXL-Dokumentes lassen sich
vom Computer einerseits als DOM (Document Object Modell) [einer
Baumartigen Datenstruktur] speichern. Dies ist ein genaues Abbild des AXLDomumentes. Es besteht jedoch auch die Möglichkeit den Inhalt des AXLDocumentes in die Anwendungslogik des Programms zu übersetzen.
28
Data Access Manager
Verbindung zwischen dem Spatial Server und einer Datenquelle
Map-Services haben folgende Möglichkeiten Daten zu beschaffen:
o Image Rendering (Image MapService)
§ JPEG, PNG oder GIF zum Web-Server
§ Generiert aus
• Shapefiles
• ArcSDE Datenquellen
• Unterstützte Bildformate:
ADRG, ASRP, BIL, BIP, BMP, GeoTiff, GIF, Tiff, Jpeg, usw.
§ Karte wird im Spatial Server generiert und Link auf die Karte an den Client
gesendet.
o Feature Streaming
§ Shapefiles und ArcSDE-Datensätze zum Java Applet (komprimiert)
§ Karte wird vom Client generiert
o Query
§ Liefert Daten aus Datenquellen
§ Notwendig bei der Nutzung von Attributen
o Geocoding
§ Findet Adressen auf Karten basierend auf Informationen aus Shapefiles oder
ArcSDE-Datenquellen.
o Data Extraction
§ Liefert einen Auschnitt der Daten als Shapefiles
§ Wird aus Shapefiles oder ArcSDE-Datenquellen generiert
§ ZIP-Format
ArcIMS Manager
Hierbei handelt es sich um eine gemeinsame Oberfläche von Author, Designer und Administrator. Sie
ist browserbasiert und läuft nur im Internetexplorer ab Version 5
ArcIMS Author
Hierbei handelt es sich um eine graphische Oberfläche zur Erstellung von Karten. Der Author bietet
die Möglichkeit Daten auszuwählen und Gestaltungsrichtlinien festzulegen. Die Daten können hierbei
aus Shapefiles, ArcSDE Datenquellen oder aus georeferenzierten Rasterdaten bestehen. Das
Ergebnis ist eine AXL Datei, die das Aussehen der Karte bestimmt. Es hat sich jedoch gezeigt, dass
das Tool momentan noch nicht ausreichend gut funktioniert. Es eignet sich um das Grundgerüst einer
Karte festzulegen. Das Feintuning muss jedoch per Hand geschehen. Unsere Einschätzung der
mangelnden Stabilität und Funktionalität wurde uns auch von Mitarbeitern von Esri auf der Intergeo
2001 bestätigt.
ArcIMS Designer
Mit diese Komponente lassen sich einfach Webseiten gestalten. Es lassen sich die benötigten
Kontrollelemente und der Mapservice bestimmen. Es wird dann automatisch die Webseite erstellt.
Hierbei lassen sich HTML- und JAVA-Viewer generieren. Wir haben uns für einen HTML-Viewer
entschieden, weil somit der Nutzer kein Java 1.2 Plugin benötigt.
ArcIMS Clients
Bezeichnen Möglichkeiten auf den ArcIMS zuzugreifen
Funktionen:
• Pan und Zoom
• Räumliche und thematische Anfragen
• Pufferung um Objekte
• Distanzen auf der Karte messen
• Annotation
o Text und Bilder hinzufügen
o Wird zum Server gesandt, aber nicht direkt integriert
29
•
•
Geometrie
o Editieren und ergänzen
o Wird zum Server gesandt, aber nicht direkt integriert
Adressen auffinden
Einige Beispiele für ArcIMS Clients sind:
ArcExplorer:
• Eigenständiger Viewer. Muss nicht über Webbrowser gestartet werden, sondern ist ein
eigenständiges in Java geschriebenes Programm, welches vom Nutzer installiert werden
muss.
HTML/DHTML Viewer:
• Wird im Webbrowser gestartet
• Nutzt Java-Script zur Übersetzung der ArcXML-Befehle
• Nur Image MapService
• Nur ein MapService gleichzeitig
• Alle Berechnungen auf dem Server
• Sourcen sind vorhanden
• Ausgangspunkt für eigene Anpassungen
Java Viewers:
• Wird im Webbrowser gestartet
• Feature Streaming und Image MapServices
• Kombination mehrerer MapServices
• Java 2 Applet
• Client führt einen Teil der Berechnungen durch
• 2 Downloads notwendig
o Java Run-time Enviroment
o ArcIMS Viewer Applet
Java Standard Viewer:
• Netscape und Internet Explorer ab 4.0
• Vordefinierte Tools und Funktionen
• Geschwindigkeitstuning beiUmfangreichen Karten notwendig.
Java Custom Viewer:
• Nur Internet Explorer 4.0 und 5.0
•
Viewer Object Model API: Individuelle Anpassung des Viewers
2.3.3.3 Schnittstelle für Routenplanung
Eine der Aufgaben der Gruppe Technik bestand in der Realisierung der Schnittstelle zwischen der von
der Gruppe Navigation entwickelten Routenplanung und der durch die Gruppe Gestaltung realisierten
Darstellung.
Für die Schnittstelle wurden verschiedene Möglichkeiten exploriert, aus denen schließlich das
getrennte Servlet für die Routenplanung ausgewählt wurde.
Anbindung im ArcIMS
Die erste Möglichkeit, die uns in den Sinn kam, setzt Modifikationen am ArcIMS Webserver voraus.
Dort sollten Anfragen, die im Zusammenhang mit der Routenplanung stehen an ein eigenständiges
Programm weitergeleitet werden.
Hierbei bieten sich folgende Möglichkeiten an:
• Anbindung über
o Servlet Connector
o ColdFusion Connector
o ActiveX Connector
• Erstellung eines eigenen „Spatial Server“
• Servlet in die Kommunikation zwischen Webserver und ArcIMS einschalten
30
Bei den „Connectors“ handelt es sich um Programmschnittstellen, mit deren Hilfe von außen auf den
ArcIMS zugegriffen werden kann. Leider haben wir keine Möglichkeit gefunden, von Seiten des
ArcIMS über die „Connectors“ auf externe Programme zuzugreifen. Die einzige Möglichkeit, die wir
gefunden haben, besteht in der Möglichkeit eigene Clients für den ArcIMS zu schreiben.
Die „Spatial Server“ sind die eigentlichen Arbeitstiere des ArcIMS. Daher bietet es sich an, einen
eigenen Server zu entwickeln, der für die Routenplanung zuständig ist. Leider haben wir keine
Informationen gefunden, die für die Entwicklung und Anbindung eines solchen Servers benötigt
werden.
Die dritte angedachte Möglichkeit besteht aus einem Servlet, das zwischen den Webserver und
den ArcIMS geschaltet werden sollte. Die gesamte Kommunikation wird abgefangen. Befehle, die für
den ArcIMS bestimmt sind, werden durchgeschleust und Befehle für die Routenplanung werden
abgefangen.
Auch hier lagen uns recht wenig Informationen über den Aufbau und die Schnittstellen vor. Daher
wurde auch diese Möglichkeit verworfen.
Der komplette ArcIMS-Server auf Server-Seite stellt eine recht abgeschlossene Einheit dar. Die
Clients hingegen sind relativ offen ausgelegt. Für den HTML-Client liegen sämtliche Source-Codes
vor. Aus diesem Grund haben wir uns dazu entschlossen, den Server auf Seiten des Clients
einzubinden.
Anbindung auf Clientseite
Die Anbindung der Routenplanung auf Clientseite setzt die
geringsten Veränderungen am ArcIMS Gesamtsystem voraus. Aus
diesem Grund haben wir uns auch für diese Variante entschieden.
Nach längeren Überlegungen haben wir uns zu folgenden
Modifizierungen am HTML-Client entschlossen:
Der HTML-Client wurde um einen zusätzlichen Frame ergänzt, der
aus der Ausgabe des zu entwickelnden Servlets besteht. Über diesen
Frame (Vom Servlet generiert und ausgelesen. Siehe Abbildung) wird
die Kommunikation zwischen den Bedienelementen der Gruppe
Gestaltung und der Klasse Routenplanung der Gruppe Navigation
realisiert.
Kommunikation zwischen Client und Servlet
Die erste Idee zur Kommunikation waren AXL-Kommandos, wie sie
auch zwischen HTML-Client und ArcIMS-Server verwendet werden.
Erste Tests brachten aber diverse Probleme mit sich. Diese hingen
mit den Sun Java-Klassen für AXL zusammen. In normalen Applets
funktionieren diese Klassen einwandfrei, aber in Servlets kam es zu
diversen Fehlermeldung zur Laufzeit, die sich nicht nachvollziehen
ließen und zu denen auch keine Lösung gefunden wurde.
Ein weiteres Problem stellt die Codierung der AXL-Befehle auf ClientSeite dar. Hier wären auch diverse neue Programmroutinen zu
erstellen gewesen, um die Benutzereingaben im entsprechende AXLKommandos umzusetzen. Daher wurde diese Idee verworfen.
Stattdessen werden die Benutzereingaben in verschiedene „Textareas“ (Eingabefelder in HTMLSeiten) geschrieben und diese Einträge vom Servlet ausgewertet.
Aufbau des Frames
Sämtliche für die Steuerung des Servlets notwendigen Angaben werden über visuelle Elemente
(HTML Forms) übermittelt. Man hätte ebenso Variablen im HTML-Code implementieren können. Der
Vorteil von visuellen Elementen liegt in der besseren Überprüfbarkeit der Einträge und Ergebnisse in
der Entwicklungsphase des Gesamtprojektes. Alle Elemente sind von der Webseite aus zugänglich
und ermöglichen somit zum Beispiel das Setzen der Route und Starten der Routenplanung. Da der
Frame (PostFrame) später nur mit der Höhe 1 angezeigt wird, sind diese Elemente für den Benutzer
nicht sichtbar und stören somit auch nicht weiter.
Im oberen Teil befinden sich Radio-Buttons über die dem Servlet mitgeteilt wird, welche Funktion als
nächstes ausgeführt werden soll.
31
•
Route berechnen: Hiermit wird das Servlet aufgefordert, beim nächsten Aufruf die Route zu
berechnen und das Ergebnis an den Client zu übermitteln.
• GPS berechnen: Servlet berechnet anhand der zuvor erstellten Route eine GPS-Datei mit den
entsprechenden Wegpunkten.
• Steigungsdiagramm: Anhand der zuletzt berechneten Route wird ein Steigungsdiagramm
berechnet.
Unterhalb der Radio-Buttons sind mehrere Schalter angeordnet. Diese dienen nur zum Test des
Servlets außerhalb des Gesamtprojektes. Die Buttons sind mit Java-Script Funktionen verknüpft, die
auch von den Bedienelementen der Gruppe Gestaltung genutzt werden.
Die sechs Eingabefelder unterhalb der Buttons sind für die einzelnen Gewichtungsfaktoren
vorgesehen. Der Inhalt wird direkt an die Klasse Routenplanung weitergeleitet.
Darunter befindet sich ein größeres Eingabefeld, in dem die einzelnen Wegpunkte für die
Routenplanung eingetragen werden. Die Ergebnisse der Routenplanung werden dann in das darunter
liegende Feld eingetragen. Das Ergebnisfeld wird immer mit einem „Dummy“-Eintrag gefüllt, da bei
jedem Aufruf des ArcIMS automatisch das Ergebnisfeld ausgelesen wird und die dort eingetragene
Route hervorgehoben wird. Der Dummy-Eintrag ist notwendig, da der ArcIMS sonst alle Elemente
highlightet
.
Über die Radio-Buttons „NMEA Format“ und „PCX5 Format“ wird das Datenformat der zu erstellenden
GPS-Datei festgelegt. Über das nächste Eingabefeld kann die max. Anzahl von Zeilen der GPS-Datei
festgelegt werden, dieser Wert wird auch direkt an die Klasse Routenplanung weitergeleitet.
Das letzte Eingabefeld dient der Zwischenspeicherung der Wegpunkte. Bei der Routenplanung wird
eine Liste der Zwischenpunkte für eine spätere Generierung einer GPS-Datei erstellt, die
zwischengespeichert werden muss. Der Inhalt wird bei der Generierung der GPS-Datei dann wieder
vom Servlet ausgelesen und an die Klasse Routenplanung übergeben.
Durch die Zwischenspeicherung aller Ergebnisse im Frame des Clients ersparen wir uns die Arbeit mit
Cookies bzw. eines Sessionmanagments. Dadurch werden auch Probleme mit Browsern vermieden,
bei denen Cookies deaktiviert sind.
Entwicklung des Servlets
Entwicklungsumgebung
Mit den kostenlos erhältlichen Versionen der Java-Entwicklungsumgebungen ist es zumeist nicht
möglich Servlets zu entwickeln. Borland bietet nur in der Enterprise Version seines JBuilders
entsprechende Möglichkeiten an. Mit Hilfe einer Testversion des Programms (60 Tage Laufzeit)
wurden die ersten Entwicklungsschritte für das Servlet durchgeführt. In die Borland
Entwicklungsumgebung ist der Apache-Tomcat-Server integriert, so dass sich Servlets auf eine recht
einfache und unkomplizierte Weise entwickeln und debuggen lassen.
32
Um das Problem der 60-Tage Beschränkung zu umgehen, haben wir uns auch mit der kostenlos
erhältlichen Netbeans Entwicklungsumgebung beschäftigt. Von Sun wird ebenfalls eine, auf Netbeans
basierende, Entwicklungsumgebung für Servlets angeboten, die aber leider auch nicht kostenlos ist.
Zu unserem Glück befand sich die Version 3 der Forté-Entwicklungsumgebung im Teststadium, so
dass man sich eine Testversion herunterladen konnte, mit der dann auch alle weiteren Änderungen
am Servlet durchgeführt wurden. Die Integration der Servlet-Engine und das anlegen eines neuen
Projektes sind zwar nicht ganz so komfortabel realisiert wie im Borland JBuilder, aber dafür bietet der
Editor weitaus mehr Funktionalität.
Aufbau des Servlets
In der Funktion „Init“ wird die Klasse für die Routenplanung erzeugt und in dieser dann die Funktion
zum laden der Daten aufgerufen. Diese Funktion wird durch die Generierung des Servlets in der
Servlet-Engine beim ersten Aufruf ausgelöst.
Wird das Servlet von einer Web-Seite aus angesprochen, so wird automatisch die Funktionen
„doGet()“ ausgeführt. In dieser Funktion wird ein HTML-Code erzeugt, der dann auf dem Web-Client
dargestellt wird. In unserem Fall stellen die Ausgaben das oben beschriebene Frame-Routenplanung
dar. Für die Generierung des HTML-Codes ist man als Programmierer selbst verantwortlich. Der Code
wird mit „print“-Anweisungen in einen Stream (vergleichbar mit Dateiausgaben z.B. in C) geschrieben,
der dann an den HTML-Client zurückgeschickt wird.
Werden vom Benutzer Eingaben im Frame gemacht und dieser dann an das Servlet zurückgeschickt,
so wird automatisch die Funktion „doPost()“ ausgelöst. Auf die einzelnen Elemente des Frames kann
dann mit Hilfe der Funktion „getParameter“ wie auf Variablen zugegriffen werden. Entsprechend den
Einstellungen werden dann auch die drei verschiedenen Teilaufgaben (Routenplanung, GPS-Datei,
Steigungsdiagramm) ausgeführt. Die Inhalte der Eingabefelder (z.B. Liste der Wegpunkte) wird in eine
sogenannte „ArrayList“ überführt. Der Vorteil dieser Listen ist, dass sie mit beliebigen Variablentypen
(in unserem Fall zumeist Strings) gefüllt werden können und dass die einzelnen Elemente einfach
ansprechbar sind. Diese ArrayList wird dann an die Klasse Routenplanung übergeben, deren
Ergebnisse auch wieder als ArrayList zurückgeliefert werden. Die Ergebnisse werden dann bei der
Generierung des HTML-Codes in die Seite eingebaut. Die Funktion „doPost“ erstellt genau wie
„doGet“ eine neue HTML-Seite, in der aber jetzt auch die Ergebnisse enthalten sind.
Um den Client zu veranlassen, nach der Routenplanung auch die berechnete Route anzuzeigen,
wurde eine JavaScript Startup-Funktion in die HTML-Seite integriert. In dieser Funktion werden in
Abhängigkeit der durchgeführten Aufgabe verschiedene Aktionen ausgelöst. Nach der Routenplanung
wird z.B. veranlasst, dass die Karte neu gezeichnet wird. Bei der Generierung des
Steigungsdiagramms wird in dieser Funktion der HTML-Code für ein neues Fenster integriert, damit
das Steigungsdiagramm nicht in dem unsichtbaren Frame erscheint, sondern in einem Popup-Fenster.
Der HTML-Code für dieser Fenster wird dabei in einer JS-Variablen abgelegt und diese Variable dann
in der Funktion „window.open“ verarbeitet.
Wenn eine GPS-Datei erzeugt wird, liefert das Servlet keinen HTML-Code , sondern eine Text-Datei.
Da dies dem HTML-Client über den sogenannten „contenttype“ mitgeteilt werden kann, reagiert dieser
entsprechend darauf und zeigt eine Dialogbox zur Eingabe eines Dateinamens an.
Probleme bei der Einbindung
Die eigentliche Integration des Servlets auf dem Server stellte sich als absolut Problemlos heraus.
Die größten Probleme betrafen den Zugriff auf die Datenquellen nach dem Schritt aus der
Entwicklungsumgebung auf den Server. In der Entwicklungsumgebung funktionierte das Laden der
Daten aus der ODBC-Datenquelle (Access-DB) einwandfrei. Auf dem Server kam es aber immer zu
einer nichtssagenden Fehlermeldung. Erste Recherchen im Internet ließen die Vermutung
aufkommen, dass es Probleme mit der verwendeten Servlet-Engine (JServ) geben könnte. Daraufhin
wurde Testweise die Tomcat-Engine auf einem anderen Rechner installiert. Leider trat auch dort der
gleiche Fehler auf. Nach weiteren Recherchen und Versuchen haben wir dann festgestellt, dass
ODBC-Datenquellen für Servlets nicht als „Benutzer-DSN“ angelegt werden dürfen sondern als
„System-DSN“ definiert werden müssen, da auch die Servlet-Engine als Systemprozess läuft und
somit unabhängig vom angemeldeten Benutzer ist.
Die ersten Versuche mit den kompletten Navigationsdaten erbrachten Ladezeiten von fast einer
Stunde beim ersten Aufruf. Zusammen mit der Gruppe Navigation konnte aber eine Lösung gefunden
werden, mit der die komplette Datenbank innerhalb weniger Sekunden komplett eingelesen werden
kann. Da dieser Schritt auch nur beim ersten Aufruf des Servlets notwendig ist, kommt es für die
Benutzer zu keiner Verzögerung bei der Routenplanung.
Ein weiteres Problem trat im Zusammenhang mit dem Speichern der GPS-Dateien auf.
33
Der InternetExplorer und Netscape verhalten sich recht unterschiedlich im Zusammenhang mit
zurückgelieferten Textdateien. Der IE zeigt diese sofort im Browser-Fenster an, womit die
Bedienelemente des Servlets gelöscht würden. Aus diesem Grund musste der „ContentType“ von
„text/plain“ auf „application/octet-stream“ umgestellt werden. Damit geht der Browser dann davon aus,
dass ein unbekanntes Binärformat folgt, das in eine Datei gespeichert wird.
Anzeige der gehighlighteten Route in der Karte
Nach Berechnen der Route wird eine Liste von Kanten an den Client übergeben. Damit die Kante in
der Karte angezeigt wird, sind einige Modifikationen am ArcIMS notwendig. Der ArcIMS unterstützt
werksseitig keine Möglichkeit zur Routenplanung. Esri hat hierfür ein eigenes Produkt, den
RoadMapIMS, entwickelt. Unser Ansatz beruht darauf, dass man im ArcIMS Anfragen erstellen kann
und das Ergebnis der Abfrage gehighlightet wird. Zur Verwirklichung der Anfragen haben wir die
Javascriptfunktion, die die ArcXML Anfragen für den Server generiert, geändert, so dass hier
standardmäßig eine Anfrage der Form: Erstelle neues Layer, Zeige in diesem Layer Elemente aus
Shapefile x an, und zwar jene mit der ID y oder ID z ...
Diese Lösung arbeitet bei einer geringen Anzahl von hervorzuhebenden Kanten recht gut und schnell.
Jedoch besteht eine Beschränkung bei der Abfrage auf ca. 40 Elemente. Werden mehr als diese
Anzahl von Elementen angefragt, ignoriert der ArcIMS die Anfrage einfach. Dies lässt sich jedoch
durch eine Aufteilung der Anfrage in mehrere Teilanfragen umgehen. Nachteil dieser Lösung ist
jedoch, dass die Bearbeitungszeit linear zur Anzahl der Anfragen steigt. Im Falle unseres Projektes
übersteigt deswegen die Zeit, die der ArcIMS zum Highligting der Route braucht, die Zeit zur
Routenberechnung um ein Vielfaches. Demzufolge ist diese Lösung eigentlich als nicht geeignet
einzustufen.
2.3.3.4 Anbindung der Webseite an den ArcIMS
Neben der Routenplanung war es ebenfalls Aufgabe der Gruppe Technik, die Infrastruktur für die
„normale“ Kommunikation der Webseite mit dem ArcIMS zur Verfügung zu stellen. Diese Aufgabe
beinhaltet die Installation der einzelnen Komponenten.
Für die Auswahl der Komponenten waren vor allem auch Kostengründe entscheidend.
Obwohl wir uns bei Webserver und Servlet-Engine auf Open-Source Produkte gestützt haben, die laut
eigenen Angaben unter Windows noch Fehler aufweisen, haben sie sich im Einsatz als stabiler als der
ArcIMS erwiesen.
Als Webserver verwendeten wir den Apache Webserver in der Windows Version, dieser Webserver ist
unter www.apache.org verfügbar und als Windows-Version erhältlich. Die Installation dieser
Komponente ist als problemlos einzustufen.
Als Servlet-Engine wird Tomcat 3.x eingesetzt. Diese ist auch unter der Apache License auf
www.apache.org erhältlich. Bei Tomcat handelt es sich um die Referenzimplementation des Servlet
Standards 2.2 Tomcat ist komplett in Java geschrieben und deswegen plattformunabhängig. Tomcat
kann als standalone Lösung mit minimaler Konfiguration als Webserver mit integrierter Servlet-Engine
benutzt werden. Wir haben uns jedoch zur Integration von Tomcat in den Apache Web-Server
entschlossen. Die Einbindung erfordert einige Konfigurationsarbeiten, die jedoch in der
Dokumentation von Tomcat recht gut beschrieben sind.
Damit der ArcIMS unabhängig vom Benutzer des PC’s erreichbar ist werden sowohl der Apache als
auch Tomcat als Dienst gestartet. Aufgrund eines Fehlers in WindowsNT funktionierte dies bei Tomcat
nicht richtig. Überraschenderweise behob das updaten des Internet Explorers auf Version 5.5 dieses
Problem.
Anbindung des ArcIMS
Die normale Anbindung des ArcIMS an den Client funktioniert sehr ähnlich zu der oben beschriebenen
Anbindung des Clients an das Routenplanungsservlet. Der ArcIMS benutzt einen nicht sichtbaren
Frame.
Wenn der Client eine Anfrage stellen will, wird diese auf dem Client mittels JavaScript generiert und in
die HTML_Form geschrieben. Danach wird diese Form an den Servlet-Connector von Esri geschickt.
34
Hierbei handelt es sich um ein Servlet, das den AXL Code aus der Form ausliest und an den
Applicationserver weiterleitet. Die Anwort des Applicationservers wird in die neugenerierte HTML Seite
codiert und an den Client zurückgesendet. Nach der übertragung an den Client wird mittels der
JavaScript Funktion onLoad() die Verarbeitung der Antwort auf dem Client angestoßen. Dieser
decodiert die in AXL codierte Antwort und zeigt die generierte Karte an.
Der hier von ESRI gewählte Weg das AXL auf Clientseite zu erzeugen und zu parsen, ist für die recht
schlechte Performance des HTML-Clients verantwortlich. Die zur Erzeugung und Verarbeitung des
AXL benötigten Funktionen machen den Clienten sehr groß und unübersichtlich.
Übersicht über die Kommunikation von Client und Server
2.3.3.5 Schlussbetrachtung
Zusammenfassend kann man sagen, dass die Erstellung eines Routenplaners mit den von ESRI
standardmäßig zur Verfügung gestellten Tools aus Performancegründen nur eine suboptimale Lösung
sein kann. Die Erzeugung von AXLCode und das Zwischenspeichern der kompletten SessionInformationen in diesem AXLCode auf dem Client sind aufgrund der gewählten Lösung in Javascript
35
sowohl recht sperrig als auch langsam. Aufgrund der schlechten Code-Qualität des von ESRI
gelieferten Javascriptcodes (z.B. gleichlautende Funktionen, die an verschiedenen Stellen
eingebunden werden) ist eine Erweiterung und Optimierung nur mit vergleichsweise hohem Aufwand
zu bewerkstelligen. Als besonders nachteilig hat sich herausgestellt, dass der ArcIMS nicht in der
Lage ist, Datenbankanfragen mit vielen Elementen schnell zu verarbeiten. Auch sonstige
Unzulänglichkeiten des ArcIMS machen die Arbeit mit diesem Programmsystem recht schwierig, und
oftmals muss man getrennte Testszenarien erzeugen, um den Fehlern des ArcIMS auf die Spur zu
kommen. So ist zum Beispiel zu beobachten, dass eine Anfrage nach Features auf einem Shapefile
eigenartigerweise nicht auf der ersten Spalte und dann nur bis zu einer bestimmten Anzahl von
Spalten funktioniert. Die restlichen Spalten werden einfach ignoriert und die Anfrage liefert kein
Ergebnis.
2.3.3.6 Zusammensetzung der Gruppe
Markus Tondorf:
Ralf Müller:
Ariane Middel:
Annette Eicker:
Exploration verschiedener Kommunikationsmöglichkeiten zwischen Client und
Server, Realisierung Anbindung Routenplanung
Infrastruktur, Installation und Wartung ArcIMS, Anpassung HTML-Viewer
Skripte
Anpassung HTML-Viewer Skripte, Schnittstellenbeauftragte, Graphisches
Konzept Webseite.
Pflichtenheft, Projektdokumentation, Exploration Kartographische
Möglichkeiten ArcIMS
36
2.3.4. Gruppe Gestaltung
Die Aufgabe der Gruppe „Gestaltung“ umfaßte im wesentlichen zwei Aufgaben. Zum einen mußten die
Karte mit den Symbolen für die verschiedenen Sehenswürdigkeiten erstellt werden und zum anderen
die Website und die Kommunikation zwischen Client und Server.
Um eine Übersicht über die vielen anstehenden Arbeiten zu erhalten, entschlossen wir uns, eine
Graphik zu erstellen, welche die Funktionsweise und die Möglichkeiten der zukünftigen Website
aufzeigen sollte. Die Graphik ist nachfolgend dargestellt:
Startseite
Bericht über das Projekt
Hauptseite
Bedienungsanleitung
Route
berechnen
Logo von
Bonn
Bedienelemente
Auswahl Unterpunkte
Auswahl
Oberpunkte
Layer
aus / ein
Auflistung
Sehenswürdigkeiten
Karte
2.3.4.2. Gruppenaufteilung
Anhand der Graphik konnte man recht gut erkennen, welche Aufgaben im Verlauf der
Durchführungsphase zu erledigen waren. Die verschiedenen Themenbereiche wurden wie folgt
aufgeteilt:
Kathrin Haverkamp:
- Erstellung der Karte mit ArcMap und ArcIMS
- Sonstige Arbeiten mit ArcIMS
- Gruppensprecherin
37
Markus Kosbab:
- Programmierung der JavaScripts
- Bearbeitung des Quell – HTML- Codes
Dirk Schröder:
- Programmierung der JavaScripts
Alexandra Höfer:
- Gestaltung der Website
- Arbeiten mit Macromedia Fireworks und Dreamweaver
Thomas Krompholz:
- Erstellung der Signaturen mit Macromedia Fireworks
Boris Giesen:
- Bedienungsanleitung
2.3.4.3. Durchführung
Karte
Bei der Gestaltung der Karte gingen wir wie folgt vor:
Die Grundlage der Karte bildet zum einen eine Rasterkarte im Maßstab 1:10.000 sowie die Shapefiles.
Die von uns ab einem Maßstab von 1:10.000 oder kleiner verwendete Rasterkarte wurde aus
Bildschirmfotos (Screenshots) der TK10 erstellt und anschließend georeferenziert. Mit ArcMap legten
wir zunächst die Optik der Karte fest, da ArcIMS zu Beginn noch nicht zur Verfügung stand. Diese
ArcMap Vorlage wurde dann farblich an die Rasterkarte angepaßt, damit der Übergang von den
Vektor- zu den Rasterdaten harmonisch abläuft. Weiterhin waren noch die verschiedenen
Linienbreiten und Strichstärken sowie die Größen der Signaturen für die unterschiedlichen
Zoomstufen zu ermitteln und umzusetzen.
Linienförmigen Darstellungen:
Bundesautobahn
Die Art der Linie ändert sich während der Zoomvorgänge nicht, lediglich die Breite wird in den
einzelnen Maßstäben verändert. Die Vektordaten werden vom Maßstab 1:10000 – 1:1000000
dargestellt. Dabei ist die Linie im größten Maßstabsbereich 1:10000 – 1:15000 mit 7 Pt am
breitesten und im kleinsten Bereich 1:100000-1:1000000 mit 3 Pt am Schmalsten.
Schnellstrassen
Die Liniendarstellung ist vom Maßstab 1:10000 – 1:50000 zweifarbig und wird bei den
kleineren Maßstäben aufgrund der geringen Linienbreite nur noch einfarbig angezeigt. Der
Shapefile der Schnellstrassen wird wie die BAB vom Maßstab 1:10000 – 1:1000000
dargestellt. Linienbreiten variieren von 7 Pt im größten Maßstabsbereich bis zu 2 Pt im
kleinsten.
Durchgangsstrassen
Die Liniendarstellung ist bis zum Maßstab 1:25000 zweifarbig und wird anschließend aufgrund
der geringen Linienbreite einfarbig angezeigt. Die Durchgangsstrassen werden nur bis zu
einem Maßstab von 1:100000 dargestellt. Linienbreiten variieren von 6 Pt im größten
Maßstabbereich bis zu 2 Pt im kleinsten.
Nebenstrassen
Die Nebenstrassen werden nur bis zu einem Maßstab von 1:75000 dargestellt. Eine
zweifarbige Darstellung erfolgt dabei in dem Maßstabsbereich 1:10000 – 1:50000 und
wechselt danach auf eine einfarbige Darstellung. Linienbreiten variieren von 6 Pt im größten
Maßstabbereich bis zu 1 Pt im kleinsten.
Fußgängerzonen
Die Fußgängerzonen werden wie die Nebenstrassen nur bis zu einem Maßstab von 1:75000
angezeigt. Eine zweifarbige Darstellung findet bis zu einem Maßstab von 1:25000 statt. Im
Maßstabsbereich von 1:25000 – 1:75000 werden die Vektordaten einfarbig präsentiert. Die
Linienbreiten variieren von 6 Pt im größten bis zu 1Pt im kleinsten.
38
Fuß-, Feld- und Waldwege
Die Fuß-, Feld- und Waldwege werden ab einem Maßstab von 1.50000 dargestellt.
Eisenbahnlinien
Eisenbahnlinien werden immer in der Karte dargestellt
Signaturen
Für die Darstellung in der Karte sollten Signaturen verwendet werden, die
1.)
2.)
3.)
4.)
5.)
eindeutig die darzustellende Begebenheit anzeigen
einfach strukturiert sind
farblich voneinander zu unterscheiden sind
sich optisch in das Bild der Karte eingliedern und dennoch leicht aus ihr heraustreten
eine geringe Größe haben, damit es wenig zu Überschneidungen kommt und das Umfeld um die
Begebenheit sichtbar bleibt.
Beispiele für solche Signaturen haben wir aus Fahrradkarten und verwandten Projekten wie
Routenplanern verwendet. Alle Signaturen wurden neu erstellt oder überarbeitet und auf das
Fahrradprojekt abgestimmt. Dazu musste jeweils der Nutzen und die Notwendigkeit für die Zielgruppe
im Vordergrund stehen.
Wir haben für jede einzelne Signatur 2 verschiedene Größen entworfen, die nach der Implementierung
in die Karte je nach Maßstab, bzw. Zoomstufe unterschiedlich groß angezeigt werden.
Stufe 1: Signaturgröße 30*30 Pixel im Maßstab >1:10000
Stufe 2: Signaturgröße 16*16 Pixel im Maßstab 1:10000 – 1:25000
Folgende Signaturen wurden verwendet:
Schwimmbäder
Zeltplätze
Fähren
Friedhöfe
Sport und Freizeit
Denkmäler
Hotel
Jugendherbergen
Kirchen und Burgen
Krankenhäuser
Museen
39
Park- und Grünanlagen
Polizei
Taxistände
Theater
Als die Karte mit ArcMap dann komplett erstellt war, mußte das Ergebnis noch in ArcXML übertragen
werden. Dies bedeutete, daß wir die komplette Karte mit dem ArcIms Author noch einmal gestalten
mussten, da es keine Möglichkeit gab die mit ArcMap erzeugte mxd-Datei in den ArcIms Author zu
importieren. Zur Neuerstellung benutzten wir den ArcIms Author. Die Shapefiles konnten über den
ArcCatalog, wie auch bei ArcMap, in den Author importiert werden. Anschließend wurden die Daten in
gleicher Weise wie zuvor in ArcMap bearbeitet. Es kam dann aber zu massiven Problemen bei der
Darstellung der georeferenzierten Rasterkarte und bei den Signaturen, die als Image für die Punkte
eingeführt werden sollten. Die einzige uns bekannte Möglichkeit zur Lösung dieses Problems war die
Editierung des AXL-Files per Hand. Dies führte aber zu einem weiteren großen Problem, denn nach
der Editierung von Hand war die Datei mit dem Author nicht mehr zu lesen. Dieses Problem hat uns
dann auch sehr lange aufgehalten, da wir zunächst davon ausgingen, daß das Problem durch einen
Fehler in der editierten AXL-Datei hervorgerufen wurde. Es stellte sich aber heraus, daß die Datei
korrekt war und das Problem beim Author lag. Damit wir uns nun die überarbeitete Datei überhaupt
ansehen konnten, mußte ein MapService eingerichtet und gestartet werden. Wir hatten somit nun die
Möglichkeit die Karte mit einem konventionellen Browser zu betrachten. Es bedeutete aber auch, daß
bei jeder kleinsten Änderung der Karte der MapService neu gestartet werden mußte, was jeweils ca.
fünf Minuten in Anspruch nahm und auf die Dauer sehr nervte.
Website
Bevor mit dem Kreieren des Layouts für die Internetsite begonnen werden konnte, mußten wir prüfen,
welche Komponenten der ArcIms benötigt, damit die Funktionsfähigkeit der Karte und aller anderen
Funktionen gesichert ist. Aus diesem Grund haben wir als ersten Schritt zunächst ein Testprojekt mit
einer „Dummy Karte“ erstellt. Der ArcIms Designer bot uns die Möglichkeit, bei Projekten zwischen
verschiedenen Layouts und Funktionalitäten zu wählen. Wir haben nun eine für uns am besten
geeignete Struktur ausgesucht und uns das zugehörige Frameset vom Designer erstellen lassen.
Dieses vorgegebene Frameset haben wir nun eingehend analysiert. Wir kamen zu dem Schluss, dass
nur zwei Frames des vorgegebenen Framesets wirklich für unser Projekt notwendig waren (im
Schaubild in pink). Somit hatten wir nun die Möglichkeit, unser eigenes Frameset zu entwerfen und
mussten lediglich die beiden ArcIms-Frames integrieren. Das von uns verwendete Frameset hat
folgende Struktur:
40
Logoframe
Toolframe
Layerframe
Topics
Mapframe
Listenframe
Postframe
Unsichtbar für den User
Route
Es werden im Folgenden kurz die einzelnen Frames und Ihre Funktionen erläutert.
Logoframe:
Vordergründig wird dieser Frame benutzt um das Logo unseres Projektes
darzustellen. Da sich dieser Frame aber während der ganzen Nutzungsphase des
Users nicht verändert und in jeder Projektphase vorhanden ist, wird er intern von uns
benutzt, um die verschiedensten Variablen und auch die Punktliste für die
Routenplanung zwischenzuspeichern.
Toolframe:
In diesem Frame liegt ein großer Teil der Programmierarbeit, da hier die
Bedienelemente angeordnet sind und ein Hauptteil der Javascripte untergebracht ist.
Man könnte ihn als eine Art Zentrale bezeichnen, in dem die meisten Verknüpfungen
unserer Seiten zusammen laufen. Hinter den Bedienelementen verbergen sich direkt
von ArcIms übernommene Funktionen, wie z.B. zoomen, verschieben etc., aber auch
selbst entwickelte Funktionen (Punkt in Route aufnehmen, letzten Routenpunkt
löschen, Route berechnen).
Topics:
Im Frame Topics können die verschiedenen Layer ausgewählt werden. Bei Klick auf
einen der hier aufgeführten Oberpunkte öffnet sich im Layerframe eine dem
Oberpunkt entsprechende HTML-Seite mit den jeweiligen Unterpunkten. So stehen
unter dem Oberpunkt Sport/Freizeit z.B. die Unterpunkte Bäder, Parks und
Sportplätze zur Verfügung. Durch einen Klick z.B. auf Bäder erscheint im Listenframe
eine namentliche Auflistung aller in der Karte vorhandenen Bäder unter Punkt
Listenframe. Oberhalb dieser Liste befinden sich noch zwei Buttons, mit denen der
zuvor gewählte Layer
oder
geschaltet werden kann. Drückt man den EIN
Button, wird eine von uns geschriebene Javascriptfunktion aufgerufen, welche aber im
Grunde nur die von ArcIms vorgegebenen Funktionen „Set active Layer() und Set
Layer visible() aufruft .Mit diesen beiden Funktionen werden der Layer aktiv gesetzt
und die Signaturen, in diesem Fall die Bäder, eingeschaltet. Ein Druck auf AUS
bewirkt, dass die Symbole mit einer weiteren Javascriptfunktion wieder ausgeschaltet
werden, der Layer bleibt jedoch aktiv.
Layerframe:
In diesem Frame werden, wie oben schon erwähnt, die jeweiligen Unterpunkte zu
einem Oberpunkt angezeigt. Hier trifft man die Auswahl, welcher Layer aktiviert
werden soll.
41
Listenframe:
Der Listenframe hat momentan nur zwei Aufgaben. Zum einen befinden sich die
Buttons zum Ein- und Ausschalten der Layer in diesem Frame, des weiteren werden
die im Kartenbild dargestellten Objekte hier namentlich aufgeführt. Hinter den
Objekten liegt eine Javascriptfunktion, durch die das entsprechende Objekt beim
Anklicken in der Mitte des Kartenausschnitts angezeigt wird. Der angezeigte
Kartenausschnitt stellt eine Fläche von 1 km² dar.
Routeframe:
Im Routenframe ist das Applet der Routenplanung eingebunden. Dieser Frame ist für
den User nicht sichtbar.
Mapframe,
Wir haben von ArcIms lediglich den Mapframe, der zur Darstellung der Karte benötigt
wird, und den Postframe, der zum zwischenspeichern interner Variabeln dient,
übernommen.
Postframe:
Der Postframe ist ebenso wie der Routeframe nicht für den Anwender sichtbar.
Bei der Integrierung der ArcIMS Frames war es sehr wichtig, die von ArcIMS
vorgegebenen Framebezeichnungen beizubehalten. ArcIMS wäre sonst nicht in der
Lage gewesen, die internen Informationen korrekt abzulegen bzw. wiederzufinden.
Zur Erstellung unserer Framesets und zur weiteren Bearbeitung unserer Seite benutzten wir die
Programme Macromedia Dreamweaver, Macromedia Fireworks sowie Corel Draw und Corel
PhotoPaint. Diese Programme haben uns gerade bei der Gestaltung der Website viel Arbeit erspart.
Macromedia Dreamweaver ist einem Grafikprogramm sehr ähnlich ist, und man die Möglichkeit hat,
HTML-Seiten nach der Methode WYSIWYG (What You See Is What You Get) zu erstellen. Die Seiten
werden auf einer grafischen Oberfläche gestaltet und Dreamweaver erstellt den entsprechenden
HTML-Code, sowie benötigte Standart Javascripte. Die Nachbearbeitung der Frames und der
Quelltexte musste jedoch von Hand erfolgen, da gewisse Feinheiten oder unsere speziellen
Javascriptfunktionen anders nicht zu realisieren waren.
Kommunikation zwischen Client und Server
Beim Einstieg in das Projekt hat man zunächst zwei Hauptbedienelemente, zum einen die Toolbar, mit
der man Kartenfunktionalitäten und die Routenplanung steuern kann, zum anderen die Topics, mit
denen man die verschiedenen Layer ein und aus schalten kann.
Zu den Layern:
Die Layer haben wir wie bereits erwähnt unter‚Topics zu vier Hauptthemenbereichen
zusammengefasst. Beim Klick auf einen der Unterpunkte, wie z.B. Krankenhäuser (unter
Informationen) wird auf drei verschiedene Grundfunktionalitäten von ArcIMS zugegriffen. Zunächst
wird ein bestimmter ArcIMS Layer aktuell und anschießend auf visible, also sichtbar, gesetzt. Zum
Schluss wird die Karte noch aktualisiert. Das aktuell setzen wird benötigt, um Aktionen die im
Kartenbild stattfinden, wie z.B. einen Punkt auswählen, erfassen zu können. Das visible setzen des
Layers bewirkt, dass die Symbole des gewählten Unterpunktes, hier ein rotes Kreutz, in die Karte
eingeblendet werden. Zusätzlich wird eine Liste aller Krankenhäuser im Listenframe angezeigt.
Zur Toolbar:
Im folgenden wird eine Übersicht über die Toolbar aufgezeigt und die verschiedenen Buttons erläutert
Grundfunktionalitäten:
Zu den von uns verwendeten Grundfunktionalitäten von ArcIMS zählen:
Gesamtübersicht:
Diese Funktion blendet eine kleine Übersichtskarte in der linken oberen Ecke des
Kartenfensters ein.
42
Zoom in:
Wird dieser Button angeklickt, hat man die Möglichkeit in der Karte ein Rechteck aufzuziehen,
dessen Inhalt dann vergrößert dargestellt wird. Man Zoomt sich also in die Karte.
Zoom out:
Diese Funktion bewirkt das Gegenteil der zuvor beschriebenen Funktion. Hier wird schrittweise
die Zoomstufe verkleinert.
Letzte Zoomstufe:
Mit diesem Button wird die zuvor eingestellte Zoomstufe wiederhergestellt.
Pan:
Mit dieser Funktion hat man die Möglichkeit, das Kartenbild „anzufassen“ und nach Belieben
zu verschieben. Man kann so z.B. einer Route folgen, indem das Kartenbild nachgeschoben wird,
wenn der Weg der Route aus dem Kartenfenster herausläuft.
Informationen zu einem Punkt:
Die Funktion Identify zählt zwar zu den Grundfunktionen von ArcIMS, war für unsere Zwecke
jedoch so nicht zu verwenden. Die identify Funktion liefert alle Informationen, die zu einem
Kartenpunkt abgelegt worden sind. Da dies zum Teil sehr viele Informationen waren, welche zudem
noch ohne jegliche Formatierung vorhanden waren, konnten wir identify so nicht verwenden.
Zur Funktionsweise: Ist ein Layer aktiviert, so werden die betreffende Symbole in der Karte angezeigt.
Klickt man nun den „I Informationen zu einem Punkt“ Button an, und anschließend auf eine Signatur in
der Karte, so werden die zu diesem Objekt vorhandenen Informationen angezeigt. Da wir jedoch nicht
an allen Informationen interessiert waren, haben wir nur die für uns interessanten herausgefiltert.
Diese geben wir dann mit dem „Alert-Befehl“ an den Anwender weiter. Sind z.B. Museen ausgewählt,
so kann man sich nun beispielsweise Informationen zu Öffnungszeiten, Eintrittspreisen oder
Telefonnummern ansehen.
Kleinste Zoomstufe:
Diese Funktion setzt den Zoomfaktor auf die kleinste Stufe. Somit erhält man eine
Gesamtübersicht unserer kompletten Karte im Kartenfenster.
Im folgenden wir kurz am Beispiel „Kleinste Zoomstufe“ beschrieben, wie diese von ArcIms gebotenen
Grundfunktionalitäten aufgerufen werden. Es handelt sich lediglich um eine Zeile:
„ href="javascript:parent.MapFrame.clickFunction('fullextent')" “
Von unserer Seite Aus wurden dann noch die zwei Funktionen „Legende“ und „Bedienungsanleitung“
hinzugefügt:
Legende:
Erklärung der verschiedenen Signaturen und Layer
Bedienungsanleitung:
Hier kann sich der User über die Benutzung des Karthographie-Projektes informieren. Es
werden die Schritte vom Einstieg in die Seite bis zur fertigen Route, sowie alle möglichen
Einstellungen erläutert.
Diese beiden Buttons führen jeweils in ein Popup Fenster, welches dann den jeweils betreffenden
Inhalt anzeigt.
43
Als drittes haben wir noch die Buttons für die Routenplanung. Hinter diesen verbirgt sich dann der
Hauptteil der Javascriptprogrammierung:
Punkt in Route aufnehmen:
Hier haben wir unter anderem wieder die von uns modifizierter Funktion identify verwendet.
Wird der „In Route aufnehmen“ Button betätigt, startet eine Javascriptfunktion, welche
zunächst überprüft, welcher Layer momentan aktiviert ist. Diese Information wird festgehalten und
anschließend der Layer mit allen Knoten aktiv gesetzt. Nun startet die selbe Funktion, die auch bei
den „Informationen zu einem Punkt“ verwendet wurde. Wenn der Nutzer nun in die Karte klickt, wird
aus den Informationen die uns die identify Funktion zurücksendet die Punkt ID herausgesucht. Diese
wird dann als Variable im Logoframe zwischengespeichert.
Nun geht ein Popupfenster auf, in welchem man angeben muß, ob der Punkt Startpunkt, Endpunkt
oder ein Zwischenpunkt werden soll.
Wird „Startpunkt“ angewählt, so überprüfen wir zunächst, ob schon ein Startpunkt existiert. Ist dies
nicht der Fall, wird die Punkt ID des gewählten Punktes im Logoframe als Startpunktvariable
abgespeichert. Existiert bereits ein Startpunkt, wird der Benutzer gefragt, ob er den alten Startpunkt
durch den neuen ersetzen möchte. Analog geschieht dies auch beim Endpunkt. Zwischenpunkte
werden in einem Array abgelegt, welches sich ebenfalls im Logoframe befindet. Zwischenpunkte
werden einfach nur an das bestehende, zunächst leere Array angefügt. Eine Route muß also
mindestens aus einem Start- und einem Endpunkt bestehen. Zwischenpunkte sind optional. Als letzter
Schritt wird der zuvor aktivierte Layer wieder aktiv gesetzt.
Route verwerfen:
Wie gerade beschrieben, werden die Zwischenpunkte in einem Array abgelegt. Wird nun die
44
Funktion „Route verwerfen“ angeklickt, erscheint ein Popupfenster, worin man die Wahl zwischen
„ganze Route verwerfen“ oder „letzten Routenpunkt löschen“ hat.
Route Berechnen:
Hier geht zunächst ein Popup Fenster auf, in welchem die Einstellungen für die
Kostenfunktionen getätigt werden können. Diese Einstellungen werden ebenfalls im Logoframe
zwischengespeichert. Beim Klick auf BERECHNEN werden sämtliche Daten die sich inzwischen im
Logoframe angesammelt haben, an das Servelet übergeben und an den Server versendet.
2.3.4.4. Resümee der Gruppe Gestaltung
Das Arbeiten in der Gruppe Gestaltung erwies sich gerade in den ersten Wochen der
Durchführungsphase als nicht besonders einfach. Die Kommunikation zwischen den einzelnen
Gruppenmitgliedern war sehr schlecht, wodurch anstehende Arbeiten oft doppelt getätigt wurden oder
gar nicht. Erst nachdem wir auf Anraten der Betreuer eine Übersicht über die Website gefertigt hatten,
wurden die Aufgabenfelder klar und die Arbeiten konnten besser verteilt werden.
Als sehr störend empfanden wir die Instabilität des ArcIMS. Gerade gegen Ende des Projektes wurden
wir durch diese Softwareschwäche immer wieder aufgehalten, so dass einige Gruppenmitglieder
tagelang im Gislabor verbringen mussten.
45
3. Resümee:
Zunächst finden wir es sehr erfreulich, feststellen zu können, dass das Ziel, welches wir uns am
Anfang des Projektes gesetzt hatten zum größten Teil erreicht werden konnte. Auch wenn nicht alle
anfangs geplanten Ideen verwirklicht wurden, so sind wir von studentischer Seite aus durchaus
zufrieden mit dem erzielten Ergebnis. Es ist uns gelungen, eine lauffähige Version eines
Fahrradroutenplaners für die Stadt Bonn zu erstellen, welche in eine Webseite eingebunden ist und
demnächst im Internet für die Allgemeinheit zugänglich gemacht werden kann.
Der Lernerfolg dieses Projektes ist aus unserer Sicht ebenfalls als gut zu bewerten. Besonders die
schon unter Punkt 1.2 erwähnten Schlüsselqualifikationen wie Team- und Organisationsfähigkeit
wurden im Laufe der Zeit gesteigert. Zu Beginn der Durchführungsphase war die Kommunikation
innerhalb der einzelnen Gruppen und zwischen den verschiedenen Gruppen noch relativ dürftig. Dies
änderte sich jedoch mit zunehmendem Verlauf deutlich, so dass zum Ende hin von einer guten
Zusammenarbeit geredet werden konnte. Allerdings können diese Aussagen nicht verallgemeinert
werden, denn es stellte sich schnell heraus, dass sich nicht alle Teilnehmer mit gleichem Engagement
beteiligten. Dies führte zu einer sehr unterschiedlichen Verteilung des Arbeitsaufwandes (und somit
auch des Lernerfolges) zwischen den einzelnen Teilnehmern.
Trotzdem fanden wir im Nachhinein die Aufteilung in selbständig arbeitende Einzelgruppen sinnvoll,
da bei einer so großen Gesamtgruppe das Projekt vermutlich gar nicht anders hätte bewerkstelligt
werden können.
Eine Verbesserungsmöglichkeit hätte vielleicht darin bestehen können, die Anzahl der
Projektteilnehmer zu reduzieren, da ein effektives Arbeiten mit einer Gruppenstärke von über 20
Personen sehr schwierig und unübersichtlich ist. Auch innerhalb der Einzelgruppen hätte eine
Reduzierung eventuell die Motivation der einzelnen Mitglieder verstärken können und die
Kommunikation wäre dadurch wesentlich erleichtert worden.
Ein Problem, welches unsere Arbeit an dem Projekt wesentlich behinderte, war die Tatsache, dass die
softwarebezogenen Randbedingungen oft nicht optimal waren. In diesem Zusammenhang ist
besonders die Instabilität des ArcIMS zu nennen, welche bis zum Ende des Projektes immer wieder
zu Verzögerungen führte. Gerade Gruppen, die für ihr Fortkommen auf die Lauffähigkeit des ArcIMS
angewiesen waren, hatten mit großen Nachteilen zu kämpfen.
Ein weiterer Punkt den wir noch ansprechen möchten, ist die Vorbereitung und Betreuung des
Projektes. In diesem Zusammenhang ist zunächst die große Motivation und Hilfsbereitschaft von
seiten der Projektleiter sehr positiv hervorzuheben. Man konnte ihnen zu jeder Zeit ihren
Enthusiasmus für dieses Projekt anmerken, welcher auch förderlich für die Motivation der gesamten
Gruppe war. Allerdings hatten wir manchmal das Gefühl, dass die Erwartungen, die in uns gesetzt
wurden oft zu hoch angesetzt und der Arbeitsumfang von den Betreuern oft unterschätzt wurde.
Ein Ansatz, der bei zukünftigen Projekten eventuell zu einem effektiveren Arbeiten führen könnte,
wäre eine optimalere Nutzung der Seminarphase. Es ist zwar vorteilhaft, dass durch Vorträge ein
einheitliches Grundwissen geschaffen wurde, unserer Meinung nach wäre es jedoch sinnvoll
gewesen, die Einteilung der Einzelgruppen schon vor Beginn der Seminarphase vorzunehmen und die
Vorträge dann mehr auf die Problematik der einzelnen Gruppen zuzuschneiden. Dies hätte ein
vorzeitiges Einarbeiten der Gruppen ermöglicht.
Insgesamt lässt sich sagen, dass das Projekt „Fahrradroutenplaner“ für uns als Studenten eine
interessante und reizvolle Aufgabe dargestellt hat, welche uns auch einige Erfahrungen und
Erkenntnisse ermöglicht hat, die für uns bei späteren Tätigkeiten mit Sicherheit sehr wertvoll werden
können. Auf der anderen Seite bleibt jedoch auch die Einsicht, dass ein solches Projekt mit sehr viel
Arbeit verbunden ist, denn zumindest für die unter uns, die sich sehr engagiert haben, lag der
Arbeitsaufwand ein Vielfaches höher als dies bei anderen Vertiefungsfächern der Fall war.
Dies führt dann auch zu einer etwas gespaltenen Meinung der einzelnen Teilnehmer, wenn es um die
Frage geht, ob sie ein zweites Mal an solch einem Vertieferprojekt teilnehmen würden
Last but not least möchten wir uns noch bei allen Projektbetreuern für ihre Bemühungen und die gute
Zusammenarbeit bedanken!
46
Persönliche Stellungnahmen der Projektbetreuer
Liebe Mitstreiter,
das nunmehr fast hinter Euch liegende Vertieferseminar hat allen eine
Vielzahl von Eindrücken und Erfahrungen gebracht. Eigenverantwortliches
Handeln im Rahmen dieses Projektes zu erlernen, sich und seine Umgebung
dabei fortfährend zu motivieren sowie die Unzulänglichkeiten der
GIS-Technologie als Herausforderung der kommenden Software-Generationen zu
erkennen, waren aus meiner Sicht die Gründe, ein derartiges Projekt
durchgeführt zu haben.
Am Ende eines derartigen Projektes die positiven oder negativen Erlebnisse
individuell gewichten zu wollen, wird dem von Euch erzielten Ergebnis nicht
gerecht. Arbeitseinsatz und Motivation vieler Teilnehmer haben sich im
Verlauf des Projektes zunehmend gesteigert und zu einem meine Erwartungen
übertreffenden Projektergebnis geführt. Die teilweise im vergangenen
Sommersemster zu beobachtende Eigendynamik hatte schon etwas Verblüffendes
an sich. Sie vermittelte dann den sich am Ende wohl zu bestätigenden
Eindruck, dass dieses Projekt zu einem erfolgreichen Abschluß kommen würde.
Meine aus diesem Projekt gewonnene Erfahrung ist, dass auch etablierte und
marktverfügbare Softwareprodukte mit ihren Schwächen einen ganzen Jahrgang
von Vertieferstudent/en/innen für Tage und Wochen aushebeln und an der
Weiterarbeit hindern können. Auch an dieser Stelle wieder einmal
diesbezüglich darauf hingewiesen worden zu sein, betont den weitreichenden
Bedarf an Forschungsaktivitäten im Umfeld der GIS.
Am Ende des Vertieferseminars angekommen wünsche ich allen einen weiteren,
positiven Verlauf des Studiums und bedanke mich herzlich für das faire und
offene Miteinander in den vergangenen 12 Monaten.
Christoph Averdung
47

1. Einleitung / Motivation - Institut für Geodäsie und Geoinformation

Transcrição

Documentos relacionados

Inspektor Gadget

Liste anfordern - ADFC

Karte * - ESSEN.Neue Wege zum Wasser

Presse-Information - Terra-Film

Reiseverlauf herunterladen

Das Streckennetz am Großen Arber

Bildausgabe http://epaper3.neue-westfaelische.de

Page 1 of 1 K+K Hotel George, London nach The Pembroke (ex

Köln Cologne

Benutzerhandbuch