geographischer Daten
Manfred BORTENSCHLAGER, Nicolas GÖLL, Daniel PLATZER und Harald RIESER
Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als „reviewed paper“
angenommen.
Zusammenfassung
Geographische Informationen bilden die Grundlage für viele ortsbezogene Dienste. Eine wesentliche Schwachstelle bei der Erfassung dieser Daten ist zum einen die Komplexität der Erfassung selbst, zum anderen die mangelnde Unterstützung durch Software Werkzeu- ge. In diesem Beitrag wird ein dreistufiger Prozess für die Geodaten Erfassung durch mobi- le Benutzer vorgestellt. Um diesen Prozess mit Werkzeugen zu unterstützen, wurde das mCollect Framework implementiert, welches den Nutzungskontext und die Qualität der vorhandenen Daten ermittelt und ausnutzt, um eine intuitivere, konsistentere und effiziente- re Datenerfassung zu ermöglichen.
1 Herausforderungen bei der Erfassung geographischer Daten
Geographische Information erweist sich mehr und mehr als hilfreich für verschiedenste Anwendungen und durchdringt unterschiedlichste Domänen. Sie bilden die Grundlage für zahlreiche ortsbezogene Dienste wie Navigationsanwendungen, elektronische Reiseführer oder Augmented-Reality-Applikationen. Seit Langem ist auch bekannt, dass räumliche Informationen Entscheidungsprozesse maßgeblich beeinflussen (DENNIS et al.1998). Häu- fig werden solche Anwendungen schon auf mobilen Endgeräten genutzt, entweder mithilfe spezialisierter Hardware wie KFZ-Navigationssysteme oder als App auf das persönliche Smartphone heruntergeladen. Ermöglicht wird diese zunehmende Durchdringung durch technische Weiterentwicklungen im Bereich der Internet und Web Technologien und der Verortungs- und Übertragungstechnologien.
Die für viele LBS Dienste notwendigen Geodaten sind allerdings häufig schlecht verfügbar, von geringer Qualität oder sehr teuer in der Beschaffung. Die Ursachen dafür sind, dass die Datenerfassung zeitaufwändig und fehleranfällig ist sowie die Tatsache, dass oftmals nur erfahrene Experten in der Lage sind, Geodaten qualitativ hochwertig zu erfassen. Gerade im Bereich der mobilen Geodatenerfassung bietet sich durch die neuen Entwicklungen und Technologien jedoch großes Potenzial, einige der erwähnten Hindernisse zu auszuräumen.
Dies kann erreicht werden durch (1) Qualitätssteigerung mittels mobiler Datenerfassung direkt vor Ort mit domänenspezifischer Validierung sowie (2) auf den mobilen Einsatz- zweck optimierten Benutzerinterfaces.
Viele der erwähnten Aspekte spiegeln sich auch im offenen Projekt OpenStreetMap1 wider.
Die Anzahl der auf den freien Geodaten aufbauenden Anwendungen steigt stetig (z.B.
OpenRouteService, Roadee, Skobbler, Peak.AR etc), die Qualität der Daten ist aber in vielen Bereichen noch stark verbesserungswürdig. Der Prozess der Datenerfassung ist noch ziemlich aufwendig (Vorbereitung, Durchführung und Nachbereitung). Auch die Werkzeu- ge für die Datenerfassung bieten entweder nur sehr eingeschränkte Möglichkeiten (Pot- latch2) oder sind sehr komplex in der Bedienung (JOSM3). Im mobilen Umfeld sind die Interfaces zudem oft sehr komplex (ArcPad4). Könnte man die Erfassung einfacher und intuitiver gestalten und viele der Tätigkeiten automatisieren, dann würde man zum einen mehr Personen dazu bewegen können, und zum anderen könnte es sich positiv auf die Qua- lität der erhobenen Daten auswirken. Eine Möglichkeit zur Verbesserung der Benutzer- interaktion ist ein so genannter multimodaler Ansatz zur Eingabe von Daten (DOYLE et al.
2008). Das heißt, es sollen unterschiedliche Eingabemöglichkeiten vorgesehen werden (Touchscreen, Sprache), aber auch bereits am Mobilen Gerät verfügbaren Daten, wie z.B.
von Sensoren, die Erfassung von geographischen Daten unterstützen.
Genau das ist der wesentliche Beitrag dieser Arbeit: Es wird ein vereinfachter Prozess für die Datenerfassung durch mobile Benutzer vorgestellt und eine Implementierung in Soft- ware für mobile Endgeräte diskutiert. Der Artikel ist dafür folgendermaßen strukturiert:
Das nachfolgende Kapitel 2 beschreibt ein Szenario und identifiziert dabei drei immer wie- derkehrende Schritte bei der mobilen Geodaten Erfassung. Kapitel 3 zeigt, wie der Kontext des Benutzers dazu genutzt werden kann, die Erfassung von Daten zu vereinfachen. Kapitel 4 stellt den Erfassungsprozess und die Implementierung von unterstützenden Software- werkzeugen (mCollect) vor, in dem diese Konzepte umgesetzt sind. Kapitel 5 wiederholt das eingangs vorgestellte Szenario mit Unterstützung der mCollect Implementierung und Kapitel 6 schließt den Artikel mit einer Zusammenfassung und Hervorhebung der wesentli- chen Ergebnisse ab.
2 Mobile Geo-Datenerfassung: Ein OpenStreetMap Szenario
Das folgende Szenario beschreibt einen typischen Ablauf einer Erfassung von Geodaten für die OpenStreetMap Plattform.
Bob ist aktiver Hobby-Mapper und sorgt oft dafür, Daten für OpenStreetMap zu erfassen.
Ebenso kümmert er sich um die Qualität der bereits vorhandenen Daten, indem er die At- tributierung der Daten überwacht und anpasst.
Am PC verwendet er dafür Tools, wie JOSM oder Potlatch, um die erfassten Daten für die OSM bereitzustellen. Ist er unterwegs, verwendet er mobile Karten-Applikationen auf Basis der OpenStreetMap.
Bob und ein Freund brechen in der Früh mit dem Auto von Salzburg auf. Sein Freund fährt, und da Bob sich nicht auf dem Beifahrersitz langweilen möchte, surft er wenig in der
1 http://www.openstreetmap.org
2 http://wiki.openstreetmap.org/wiki/Potlatch
3 http://josm.openstreetmap.de/
4 http://www.esri.com/software/arcgis/arcpad/index.html
OpenStreetMap. Er stellt anhand der Karte fest, dass die Straßenzüge innerhalb Salzburg schon nahezu vollständig erfasst sind, er kann anhand der Karte aber nicht feststellen, dass die beiden vor der Autobahnauffahrt zwei Straßenkreuzungen passieren, bei denen noch die Abbiegerelationen fehlen.
Die Kartenapplikation, die Bob verwendet, zeigt auch sogenannte OSM-Bugreports an.
Während der Fahrt auf der Autobahn notiert sich Bob die Informationen einer durch einen Bugreport gekennzeichnete, geänderte Geschwindigkeitsbegrenzung, sowie erfasst die GPS-Position einer neuen Radaranlage. Am Parkplatz angekommen starten die beiden die Wanderung.
In der Karte erkennt Bob, dass der Weg noch nicht erfasst ist. Bob startet die Aufzeichung des GPS-Tracks, und notiert sich einige Meta-Informationen (wie den Namen des Wander- wegs). An einer Hütte angekommen beschließt Bob, dass diese Hütte unbedingt dokumen- tiert gehört, also erfasst er die GPS-Position und notiert sich auch zur Hütte einige Meta- Informationen (wie Öffnungszeiten).
Am Abend nach der Wanderung setzt sich Bob am den PC und überträgt die erfassten In- formationen mittels JOSM in OSM. Dabei stellt er fest, dass er einige der Attribute der erfassten Daten nicht angeben kann, oder sie aus dem Gedächtnis eintragen muss.
Das beschriebene Szenario ist typisch für eine Datenerfassung für OSM. Grundsätzlich kann man den aktuellen Erfassungsprozess meist als dreistufigen Prozess beschreiben, bei dem jeder Schritt bestimmte Problematiken birgt:
1. Identifizieren von fehlenden Daten
Zuerst sollte untersucht werden, welche Daten schon vorhanden sind und welche noch fehlen. Fehlende Wege bzw. Wegsegmente können entweder durch ortskundige Personen oder durch visuellen Vergleich der OpenStreetMap mit anderen Karten – z.B. Google Maps oder Orthofotos – ausgemacht werden. Andere fehlende Daten, wie z.B. Points of Interest, oder auch Attribute wie Straßenbelag, Geschwindigkeitsbeschränkungen und Abbiegerela- tionen sind dagegen wesentlich schwieriger festzustellen, da sie nicht oder nur ungenügend in der Kartendarstellung der OpenStreetMap erscheinen.
2. Erfassen der fehlenden Daten
Da die Datenerfassung für OpenStreetMap auf Basis von bestehendem Kartenmaterial unter Umständen den Lizenzbedingungen widerspricht und rechtswidrig ist, müssen die fehlen- den Daten üblicherweise vor Ort erhoben werden. Zuerst muss der Benutzer zu der betref- fenden Stelle gelangen, wozu häufig Kartenteile ausgedruckt und betreffende Stellen darauf markiert werden.
Dort angekommen kann ein neues Wegsegment durch Aktivierung einer GPS-Maus oder eines GPS-fähigen Mobiltelefones und anschließendem, physischen „Abgehen“ der Route aufgenommen werden. An Kreuzungen, Hinweisschildern oder anderen wichtigen Stellen kann ein Wegpunkt gesetzt werden und mit handschriftlichen Vermerken auf der ausge- druckten Karte ergänzt werden. Attribute wie Wegtyp, Straßenbelag etc. werden dort eben- falls per Hand eingetragen. Abbildung 1 zeigt ein Beispiel einer solchen Hilfskarte.
Abb. 1: Hilfskarte mit handschriftlichen Annotationen 3. Einpflegen der erfassten Daten
Im letzten Schritt können die aufgenommenen Daten mithilfe eines Editors wie Potlatch oder dem Java OpenStreetMap Editor (JOSM) eingepflegt werden. Die aufgezeichneten GPS-Tracks können zumeist nicht direkt übernommen werden, sondern werden üblicher- weise im Editor importiert und nachgezeichnet. Grund dafür sind die enorme Anzahl der aufgezeichneten Trackpunkte sowie Ungenauigkeiten und Ausreißer beim GPS-Empfang.
Points of Interests und Attribute müssen einzeln von den händisch ergänzten Karten im Editor nachgetragen werden.
Mithilfe eines Software Werkzeuges für mobile Endgeräte lassen sich Punkt 2 und 3 zu- sammenfassen. Eine Vorbereitung ist aber oftmals trotzdem notwendig.
3 Kontext-sensitive Datenerfassung
Grundidee zur Unterstützung der Erfassung von geographischen Daten im Allgemeinen, und OSM-Daten im Speziellen, ist den in Kapitel 2 beschriebenen dreigeteilten Aufnahme- prozess zu vereinfachen und alle Schritte mit einer mobilen Anwendung direkt zu unter- stützen. Dabei ist es wichtig, dass die Anwendung dem Benutzer durch Automatisierung möglichst viel Arbeit abnimmt, sehr einfach in der Handhabung ist und somit möglichst geringe geographische Kenntnisse erforderlich sind (DOYLE et al.2008). Der Nutzungskon- text kann dafür vorteilhaft ausgenutzt werden. Unter Kontext versteht man dabei jegliche Information, die ausgenutzt werden kann, um eine Situation zu beschreiben (DEY et al.
1999). Somit gibt es eine sehr breite Palette an unterschiedlichen Kontextfaktoren. Durch die zunehmende Miniaturisierung der Hardware und sehr gut abstrahierte Softwareschnitt- stellen werden diese Kontextfaktoren immer besser auslesbar und auswertbar. Mobile End- geräte wie Smartphones sind mit einer Vielzahl an unterschiedlichen Sensoren ausgestattet – wie GPS Lokalisierung, Kompass, Beschleunigungs-, Helligkeits- oder Temperatursen- sor. In Zukunft werden noch weitere Sensortypen ergänzt werden. Mithilfe dieser Umge- bungsfaktoren kann auf den Nutzungskontext geschlossen werden, wodurch Benutzerinter-
aktionsmöglichkeiten einer mobilen Anwendung wesentlich verbessert werden können (HASLINGER et al.2009).
Die folgenden Abschnitte beschreiben, wie der drei-stufige Prozess der mobilen Geodaten- erfassung durch Kontext-Sensitivität optimiert werden kann.
1. Identifizieren von fehlenden Daten
Geographische Daten werden häufig mithilfe von geometrischen Objekten modelliert und zugehörige Eigenschaften in Form von Attributen gespeicher. Eine mobile Anwendung kann selbständig feststellen, ob wichtige Attribute zu einem Point of Interest oder Weg- segment fehlen und diese farblich auf einer Karte hervorheben (z.B. fehlender Straßenname oder Abbiegerelation). Zusätzlich kann der aktuelle Standpunkt mithilfe einer Lokalisie- rungstechnologie (z.B. GPS-Modul) ermittelt und fehlende Daten in der näheren Umge- bung des Benutzers bestimmt und darauf aufmerksam gemacht werden.
Fehlende Wegsegmente können erkannt werden, sobald sich ein Benutzer mit seinem Mo- biltelefon in einem Bereich bewegt, für den kein Wegsegment in OSM erfasst ist (z.B. eine fehlende Wander- oder Radroute). Diese Vorgehensweise funktioniert für dicht bebaute, innerstädtische Gebiete voraussichtlich nur unzureichend, da hier einerseits die GPS- Genauigkeit beeinträchtigt ist und gleichzeitig die Straßenzüge sehr eng beieinanderliegen können, sodass unter Umständen keine eindeutige Identifizierung möglich ist.
Geometrische Analysen zur Fehlererkennung werden am Server durchgeführt. Dazu wer- den im Allgemeinen geometrische Operationen zur Analyse von topologischen Beziehun- gen zwischen Objekten genutzt. So können beispielsweise potenzielle Fehler im Straßen- netz eraknnt werden.. Endet die Geometrie einer Straße in der Nähe einer anderen, berührt sie aber noch nicht, kann dies auf einen Fehler in der bestehenden Geometrie hinweisen.
Ein weiteres Beispiel, das speziell in OpenStreetMap häufig auftritt, sind einander über- kreuzende Straßen ohne gemeinsamen Schnittpunkt. Hier sind 2 Fälle denkbar: die Straßen treffen einander in einer wirklichen Kreuzung, oder eine der beiden Straßen ist eine Über- oder Unterführung. Die Unterscheidung ist speziell relevant für Routing-Algorithmen, aber auch für die Darstellung der Daten in Karten. Für den ersten Fall müssen die beiden Geo- metrien einen gemeinsamen, modellierten Punkt besitzen. Im zweiten Fall muss für eine der beiden Straßen ein Layer-Attribut gesetzt sein (und zusätzlich die Straße als Brücke oder Tunnel beschrieben sein).
Um fehlende Attribute zu erkennen, wird die vollständige Beschreibung der Daten in einem semantischen Objektmodell, einer Ontologie benötigt, in der jedes Objekt mit einem spezi- fischen Datentyp und damit assoziierten Eigenschaften beschrieben wird. Die Eigenschaf- ten sind dabei durch Schlüsselname, Werttyp und Wert modelliert. Zusätzlich kann für jede Eigenschaft festgelegt werden, ob es sich um eine optionale oder zwingend erforderliche Information handelt. Fehlt zu einem Objekt ein zwingend erforderliches Attribut, wird das gesamte Objekt als unvollständig erkannt und anschließend in der Darstellung entsprechend hervorgehoben.
Ein möglicher Anwendungsfall könnte ein Linienzug sein, der als Typ „Straße“ gekenn- zeichnet. Aus der Ontologie lässt sich ableiten, dass das Attribut zur Beschreibung der Straßenart zwingend erforderlich ist, da es sich um eine wesentliche Eigenschaft handelt, und so beispielsweise für Navigationsanwendungen unabdingbar ist.
2. Erfassen der fehlenden Daten
Zunächst unterstützt die Anwendung den Benutzer bei der Auffindung des Zielorts mithilfe einer Karte, auf der Objekte mit fehlenden Attributen bereits hervorgehoben sind. Sobald der Benutzer sich in der Nähe eines solchen Datenmangels befindet, macht die mobile Ap- plikation darauf aufmerksam und fragt die fehlenden Daten explizit nach – beispielsweise:
„Bitte geben sie den Namen der Straße an, auf der sie sich befinden“ oder „Bitte geben sie die Abbiegemöglichkeiten der vor ihnen liegenden Kreuzung an“ mit den Auswahlmög- lichkeiten links, rechts, geradeaus.
Neue Points of Interest kann der Benutzer durch einfachen Klick auf die Karte und an- schließende Angabe der wichtigsten Attribute wie Name und Typ erstellen.
Wenn sich der Benutzer auf einer noch nicht erfassten Straße befindet, wird er gefragt, ob die Straße automatisch erfasst werden soll. Danach wird die beschrittene Route im Hinter- grund aufgezeichnet, bis wieder ein bekanntes Wegsegment erreicht wird.
3. Einpflegen der erfassten Daten
Das manuelle Einpflegen der Daten mithilfe eines externen Editors entfällt für viele Daten vollständig und wird durch die mobile Anwendung übernommen.
Die aufgezeichneten GPS-Tracks werden automatisch aufbereitet. So können beispielswei- se unnötige Routenpunkte entfernt und grobe Ausreißer herausgefiltert werden. Daraufhin können die bereinigten Daten auf den OSM-Server hochgeladen werden. Da die Datenauf- bereitung vollautomatisch erfolgt und Fehlerfreiheit nicht garantiert werden kann, sollen die Tracks entsprechend gekennzeichnet und nicht sofort in der OSM dargestellt werden. Die so markierten Wegsegmente werden in einer eigenen Liste zusammengefasst und erst nach einem kurzen Review durch die Community für alle sichtbar gemacht.
4 Der mCollect-Prozess
Auf Basis der Überlegungen, die in den vorangegangenen Kapiteln vorgestellt wurden, wurde das mCollect Framework konzipiert. mCollect ist eine Implementierung des zuvor beschriebenen Prozesses zur Erfassung von Daten mit räumlichem Bezug für mobile End- geräte. Im Hinblick auf aktuelle Entwicklungen im Web, wie Community-driven Initiativen (z.B. Wikipedia) oder soziale Netzwerke besteht eine zentrale Aufgabe dieses Frameworks darin, nicht nur professionellen Benutzern von geographischen Informationen die Möglich- keit zu geben, Daten zu erfassen, sondern vor allem Daten auch im alltäglichen Gebrauch der mobilen Geräte zu erfassen, und somit die Hürde für die Mitglieder der angesprochenen Communities so gering wie möglich zu gestalten. Dazu werden die in Kapitel 3 beschriebe- nen Konzepte zur automatisierten Datenerfassung verwendet, um die Benutzer zu unterstüt- zen, Daten einfach erfassen zu können.
4.1 mCollect Client
Abbildung 2 zeigt die Architektur der mCollect Implementierung auf dem mobilen Endge- rät. Die Verfügbarkeit von unterschiedlichen Sensoren auf einer großen Anzahl von Gerä- ten macht es möglich, den Kontext des Benutzers zu analysieren, und diese Information in
die Darstellung von geographisch basierten Daten einfließen zu lassen. Die Darstellung selbst ist dabei ebenso abhängig vom Kontext wie den Daten.
Die Architektur des Clients für mobilee Endgeräte ist in drei Schichten gegliedert. Die unterste Schicht beschreibt die Kommunikation zu geographischen Datenquellen. Diese Datenquellen können grundsätzlich beliebig gewählt werden, die eigentliche Kommunika- tion erfolgt dabei über das erweiterbare Konzept der Konnektoren. Beispiele für mögliche Datenquellen sind OpenStreetMap oder das mCollect Serversystem, in dem aufwendigere Analyseprozesse durchgeführt werden können. Beliebige Datenquellen können über weitere Konnektoren eingebunden werden.
Abb. 2: mCollect Architektur (mobil)
Die Daten aus den Server-basierten Quellen und aus den Sensoren werden der zweiten Schicht übergeben, in der lokale Datenanalyse sowie die Analyse des Kontexts durchge- führt wird.
Wurden durch die Analyse der Daten in Einbeziehung des Kontexts Fehler erkannt, werden diese in unterschiedlichen Darstellungen am Bildschirm (der dritten und obersten Schicht) des mobilen Endgerätes angezeigt. Dabei wird ebenfalls anhand des Kontexts, der Präfe- renzen des Benutzers sowie der Art des Fehlers versucht, die für die aktuelle Situation optimale Präsentation zu wählen. Mögliche Präsentationsformen in der gegenwärtigen Implementierung sind kartenbasierte Darstellung, Listen-basierte Darstellung von Attribu- ten oder eine Augmented Reality Darstellung.
Die Abbildungen 3 und 4 zeigen zwei Beispiele einer solchen Interaktion mit dem Benut- zer. In Abbildung 3 befindet sich der Benutzer auf einer Straße, die vom System als unvoll- ständig markiert, und deshalb farblich hervorgehoben ist. Der Benutzer hat die Möglichkeit hat, das Objekt anzuklicken und so die Beschreibung zu öffnen. In diesem Fall ist der Typ und die Breite der Straße nicht erfasst. Nun kann der Benutzer beispielsweise auf den Typ klicken, um diesen zu editieren. In Abbildung 4 bewegt sich der Benutzer auf eine Kreu- zung zu. Die Abbiege-Relationen dieser Kreuzung sind unvollständig erfasst. Das System generiert aus den Daten eine oder mehrere Fragen, die auch von Laien problemlos beant-
Abb. 3: Hervorhebung fehlerhafter Daten
Abb. 4: Einfügen von Abbiegerelationen
wortet werden können. Die Beantwortung dieser Fragen durch Dateneingabe hilft, den Datensatz für diese Kreuzung zu vervollständigen. Zusätzlich wird eine Karte angezeigt, die die Kreuzung sowie die aktuell befahrene Straße hervorhebt.
4.2 mCollect Server
Das mCollect Serversystem dient einerseits als Schnittstelle zur OSM und anderen Fremd- systemen, andererseits werden hier geometrische Operationen und Analysen durchgeführt, die am Client nicht möglich sind. Die Ergebnisse dieser Analysen können vom Client wie- derum abgefragt werden, und als Unterstützung zur Erfassung von Daten dienen. In Kapi- tel 3 wurde beschrieben, dass vor allem die Analyse von Fehlern in Straßennetzen eine Unterstützung zur Erfassung am Client geben kann.
Abb. 5: Beispiel für Fehler in der OSM
Abbildung 5 zeigt einen solchen Fehler in der OpenStreetMap5, der über die Analyse- Methoden automatisch erkannt wurde, und im Client als solcher dargestellt wird. In der Kartendarstellung (links) erkennt man zunächst keinen Fehler. Nur in einer Darstellung, die die Rohdaten zeigt (rechts), erkennt man, dass die „Willibald Hauthaler Straße“ nicht mit der Querstraße verbunden ist. Fehler dieser Art sind speziell für Routing-Algorithmen rele- vant. Diese Fehler werden, wie in Kapitel 3 beschrieben, im Server über automatische Pro- zesse erkannt, und können über ein WFS-Interface vom Client abgerufen werden.
5 Ein Szenario zur Geo-Datenerfassung mit mCollect
In diesem Kapitel wird das Szenario aus Kapitel 2 repliziert – allerdings wird dieses Bei- spiel unter Zuhilfenahme der mCollect Implementierung und der daraus resultierenden Verbesserungen beschrieben.
Bob ist aktiver Hobby-Mapper, und sorgt oft dafür, Daten für OpenStreetMap zu erfassen.
Ebenso kümmert er sich um die Qualität der bereits vorhandenen Daten, indem er die At- tributierung der Daten überwacht und anpasst.
Er verwendet dafür mCollect, eine mobile Software. Er plant mit einem Freund eine Wan- derung.
Die beiden brechen in der Früh mit dem Auto von Salzburg auf. Sein Freund fährt, und da Bob sich nicht auf dem Beifahrersitz langweilen möchte, startet er mCollect auf seinem Smartphone. Die Straßenzüge innerhalb Salzburg sind schon nahezu vollständig erfasst, doch vor der Autobahnauffahrt passieren sie zwei Straßenkreuzungen, bei denen noch die Abbiegerelationen fehlen. Die Anwendung weist ihn auf diesen Umstand hin, und durch einfache Fragen („Welche Möglichkeiten abzubiegen stehen zur Verfügung?“) ergänzt er diese Daten.
Während der Fahrt auf der Autobahn korrigiert Bob noch eine durch einen Bugreport gekennzeichnete, geänderte Geschwindigkeitsbegrenzung und erfasst eine neu aufgestellte Radaranlage. Am Parkplatz angekommen starten die beiden die Wanderung.
Kurz danach meldet sich das Mobiltelefon, dass der Weg noch nicht erfasst sei. Bob stimmt der automatischen Aufnahme zu. An einer Hütte angekommen beschließt Bob, dass diese Hütte unbedingt dokumentiert gehört und erstellt einen entsprechenden Point of Interest.
5 Zum Zeitpunkt des letzten Daten-Updates (April 2010). Die OpenStreetMap ist ähnlich der Wiki- pedia ein sehr aktives Projekt, es ist daher möglich, dass die Fehler inzwischen korrigiert wurden.
Nach Abschluss der Wanderung wird die im Hintergrund aufgezeichnete Route automatisch aufbereitet, atttributiert und an den OSM-Server geschickt.
Dieses Szenario beschreibt die Unterstützung der Datenerfassung durch mCollect. Dabei wird der Kontext (automatische Datenerfassung über Sensoren) ebenso in Betracht gezogen wie direkte Eingaben des Benutzers.
Durch die Kontextanalyse mittels der am mobilen Endgerät verfügbaren Sensoren werden die Attribute der Wege automatisch erkannt. So kann beispielsweise eine Fahrt mit dem Auto über Beschleunigungssensoren und GPS-Gerät erkannt werden, wobei die Attribute dementsprechend automatisch bestimmt werden können. So kann der Straßentyp einer Straße, bei der die Fahrer konstant mit Geschwindigkeiten um 100 km/h unterwegs sind, relativ eindeutig als „Hauptstraße“ erkannt werden.
Der Wanderweg im Szenario wird über die Analyse bestehender Daten (in dem Fall sind bisher keine Daten über einen Weg vorhanden) und über den Kontext („zu Fuß unterwegs“) erkannt. Dabei wird der Benutzer zur Sicherstellung noch einmal befragt, da es ist immer- hin möglich ist, dass sich die Benutzer außerhalb gekennzeichneter Wege aufhalten.
6 Zusammenfassung und Beitrag
Dieser Beitrag beschäftigt sich mit der Optimierung und der Verbesserung der Datenquali- tät bei der Erfassung von geographischen Daten. Für diese Erfassung wurden drei wieder- kehrende Schritte identifiziert: (1) identifizieren von fehlenden Daten, (2) erfassen der fehlenden Daten und (3) einpflegen der erfassten Daten. Um diese Schritte unterstützen zu können, wurde in diesem Artikel ein Prozess und dessen Implementierung im mCollect Framework vorgestellt. Diese Implementierung bietet Software Werkzeuge für mobile Endgeräte, die zum einen den Kontext eines Benutzers und zum anderen fehlende geogra- phische Daten ermitteln. Diese Information kann über mehrere Präsentationsmöglichkeiten dargestellt werden und erlaubt es somit dem Benutzer Daten gezielter, intuitiver und somit effizienter zu erfassen.
Literatur
DENNIS,A.R.&CARTE,T.A. (1998): Using Geographical Information Systems for Deci- sion Making: Extending Cognitive Fit Theory to Map-Based Presentations. In: Informa- tion Systems Research, 9 (2), S. 194-203.
DEY,A.K.,ABOWD,G.D.&SALBER,D. (1999): A context-based infrastructure for smart environments. 1st International Workshop on Managing Interactions in Smart Environ- ments (MANSE99), S. 114-128.
DOYLE,J., BERLOTTO,M. &WILSON,D.(2008): Evaluating the benefits of multimodal interface design for CoMPASS – a mobile GIS. In: GeoInformatica, 14, (2), S. 135-162.
HASLINGER,S.,JIMÉNEZ,M.&DUSTDAR,S.(2009): Correlation of context Information for mobile services. In: Proceedings of the 11th International Conference on Enterprise In- formation Systems. Springer.
