Geoscience Reference
In-Depth Information
LBGC, in contrast to MoGeo, is not an educational tool in its own right but some of the concepts
of coming to an understanding about the landscape though direct evidences taken from the land-
scape obviously cross over. In LBGC, the mobile app/device
•
Must take advantage of being situated in a study area
•
Should allow for iterative
model
building in the field
•
Can be performed on a single mobile device without the requirement of a network
connection
•
Should take advantage of the affordances and properties of the mobile device
MGIS, in addition to some potential influences on education and the previous discussion of LBS,
has also had a profound influence on our concept of LBGC in a manner similar to that which
desktop GIS had on GC in its infancy. Many MGIS apps employ a client-server style relation-
ship in order to gather data in the field and then usually perform some rudimentary GIS calcu-
lations and/or interrogations, providing results that are then fed back to the device in the field.
One such example is the dynamic generation of MM with a secondary objective of team track-
ing in unfamiliar or hazardous landscapes (Karunarathne et al., 2010). Although a fairly simple
implementation, in this case, of particular importance is the fact that reliability and robustness
were necessary attributes for the device and app, due to the relative cost of failure in a hazardous
environment. This clear client-server relationship is replicated in other apps due to the relatively
poor computing power of older mobile devices. In MGIS, the aim of the mobile arm of the process
is usually to take something that could be done on the desktop and, where relevant, move all or
part of it into the field. Although referred to as field-based GIS, MGIS is often not based in the
field but is actually server based with a mobile component (Pundt and Brinkkötter-Runde, 2000;
Shi et al., 2009).
15.4.1 i
MPortance
of
B
eing
in
the
S
tudy
a
rea
for
gc
Traditional GC is an attempt to create models of the world, often by combining large amounts
of processing power, smart computational algorithms and geographical knowledge, all of which
take place in an office or laboratory on a desktop machine. All geographical data that are col-
lected for the purposes of GC, which are then analysed and interpreted, by its very nature are
an abstraction of the world we are trying to understand. Points collected to understand water
flows are in the end just a set of coordinates and attributed data. It is only their context that gives
them meaning. LBGC attempts to remove some of the abstraction from the data, which is often
divorced from its original landscape context or setting, by bringing the equipment to the evidence
rather than the other way around. Using context in mobile apps has been a research area for some
time; some early principles concerning features that context aware apps can support were identi-
fied by Dey (2001):
•
Presentation of information and services to a user
•
Automatic execution of a service for a user
•
Tagging of context information to support later retrieval
In an app designed for LBGC, it is feasible that all three of these features could be implemented
and work together towards a common goal. Presentation of context-aware information to a user in
the field alone does not constitute LBGC as it falls under the category of LBS since it is entirely
concerned with consuming media. However, LBGC apps might implement a feature such as this,
for example, to let researchers know on the ground that they are in an area of interest, help identify
particular aspects of the landscape such as plant species through the presentation of supplemen-
tary information or simply show the location of some work which has been carried out previously.
