scenarios given so far. This section gives an overview on the mainfeatures of the system, for more details please refer to [13]. TheTUGeoWiki system is based on the well-known open sourceMediaWiki implementation. We have chosen MediaWiki for tworeasons.First, it provides two well-defined mechanisms for extension of functionality:
special pages
and
templates
.
Special pages
are pages without Wiki content, which are generated on demand andare used to provide additional tools for users, e.g., file upload[14].
Templates
are pages created for transclusion purposes, andusually contain repetitive materials or blocks of information (e.g.,infoboxes) [15].And second, the user interface of MediaWiki is probably the best-known Wiki user interface, among others, due to the immensely broad use and high popularity of Wikipedia [16].TUGeoWiki modifies the MediaWiki paradigm of
pages
for theindividual entries in order to define
places,
which are relayed togeographical coordinates, and thus represent real-world
locations
.In our terminology
place
thus defines the entity in the system,while
location
denoted the actual geographical entity. Thismodification is achieved by using MediaWiki’s
special pages
tocreate location-based entries as well as templates to display them.Figure 1 depicts the concept of creating a
place
. These templatesare designed as mashups, thus extending the Wiki entries withmapping material from Google Maps or Microsoft Live SearchMaps. Additionally, a hyperlink to the MediaWiki extension
Geohack
provides access to numerous other map sources [17].
Figure 1: General notion for creating places in TUGeoWiki
This Wiki application can be used in classroom or remote learningscenarios to provide a tool for collaborative activities ongeospatial information, resulting in two application scenarios: a“desktop application scenario” and a “mobile applicationscenario”.The
desktop application scenario
is based on collaborativeauthoring with the Wiki and fosters
process-oriented learning
and
task-based learning.
Possible use cases in this context are the preparation for field trips as well as post-processing and review of the information gained in such an excursion. The focus of thisscenario is set on collaborative authoring in order to supportinformal learning on the topics of such an excursion.The
mobile application scenario
provides access to the learner’scurrent location by querying internal or external GPS sensors. Thecoordinates retrieved from the GPS sensors are used inTUGeoWiki to search for
places
in the vicinity of the currentlocation or to create a new
place
in the Wiki and startcollaborative learning about the topics of the current location. Themain goal behind this scenario is to satisfy an information-need
just-in-time
concerning the current location as well as enabling
real-time
sharing of resources (mainly images) concerning thelocation. Due to the restrictions of the user interface (cf. i.e. [18]),collaborative authoring in this mobile scenario is a non-trivialtask, and thus the editorial work on
places
has been restricted toThe
mobile application scenario
provides access to the learner’scurrent location by querying internal or external GPS sensors. Thecoordinates retrieved from the GPS sensors are used inTUGeoWiki to search for
places
in the vicinity of the currentlocation or to create a new
place
in the Wiki and startcollaborative learning about the topics of the current location. Themain goal behind this scenario is to satisfy an information need
just-in-time
concerning the current location as well as enabling
real-time
sharing of resources (mainly images) concerning thelocation. Due to the restrictions of the user interface (cf. i.e. [18]),collaborative authoring in this mobile scenario is a non-trivialtask, and thus the editorial work on
places
has been restricted tothe creation and annotation of so-called
place stubs
. Place stubs(also called
article stubs
) can be seen as temporary mini-placeobjects that learners use at their mobile devices, and after submitting them to the Wiki server, they can be described in moredetail. Additionally for the mobile application scenario,TUGeoWiki provides a feature to create geotagged images withthe mobile phone’s camera and embeds the GPS coordinates inthe Exif headers of the image files. In a separate step, theseimages (or images created with any other application for geotagging images) can be uploaded and relayed to existing
places
or used to provide an article stub for a new
place
in anarbitrary location around the corresponding coordinates.We have stipulated these two aforementioned scenarios in order toimprove learning activities
in-the-field
and
on-site
by supportingseveral steps in such learning journeys, i.e., activities before andafter the journey with the desktop scenario and activities duringthe journey with the mobile scenario.The component architecture of the TUGeoWiki system as well asthe interactions among the individual parts (with focus on themobile scenario) is shown in Figure 2. The mobile device (mobile phone or PDA) is equipped with the TUGeoWiki client and aWeb browser. The client retrieves the current coordinates of thedevice either from an internal GPS sensor, or, via Bluetooth, froman external sensor.The client relays requests for upload of images to the mobile browser or directly to a server side
application programming interface
(API). Requests for information about the currentlocation or requests for creating a new
place
for the currentlocation are always relayed to the mobile browser. The browser ismainly used to access the adapted MediaWiki on the TUGeoWikiserver side, which shares a common database with the API. For each new entry, the Wiki displays a
place
template, which embedsa Google Map, and links (relaying the
place
’s coordinates) to the
Geohack
extension as well as Google Maps and Microsoft LiveSearch Maps.
Add a Comment