Alternative Access Project: Mobile Scoping Study Final Report

goatishspyMobile - Wireless

Dec 10, 2013 (3 years and 7 months ago)

129 views


1






















Alternative Access Project: Mobile
Scoping Study Final Report












Version

Date

Comment

Author(s)

1.0

18
th

June 2010


Ben Butchart
Murray King

Addy Pope

Joe Vernon

James Crone

Jennie Fletcher

1.1

07
th

July

Minor Changes

Ben Bu
tchart

1.2

16
th

July

Minor format changes

Ben Butchart

1.3

3
rd

August

Reformat, readability
changes and section
numbering; minor edits

James Reid



2


Acknowledgements


Edina would like to thank the following people and groups who gave up some of
their tim
e to talk to us about their work and experiences in using mobile in
educational settings. We learnt a great deal from the conversations we had and
we are sure that our analysis and recommendations are much closer to genuine
needs and expectations as a resu
lt.



Mike Sharples /Professor/ of Learning Sciences and Director of the Learning
Sciences Research Institute at the University of Nottingham


Anthony Steed
-

Professor of Virtual Environments & Computer Graphics
Department of Computer Science, UCL


Dav
id Mountain
-

Lecturer
-

City University London


Claire Jarvis, Lecturer in Geographic Information, University of Leicester


Jen Dickie, Research Associate
-

University of Leicester


Gemma Polmear, Researcher University of Nottingham


Gary Priestnall,
Associate Professor
-

University of Nottingham


Chris Kray, Lecturer at the School of Computing Science and the Digital Institute
at Newcastle University.


James Goulding, Research Associate, University of Nottingham


Liz Brown, Research Associate, Unive
rsity of Nottingham

The CGS Postgrads at Nottingham


Phil Stenton, Managing Director, Calvium


Jon Trinder, Researcher, University of Glasgow


Chris Speed, Lecturer/Reader, Edinburgh College of Art


Chris Lowry, Lecturer, Edinburgh College of Art


Mark
Wright, Research Fellow, University of Edinburgh


Simon King, Reader, EPSRC Advanced Research Fellow, Centre For Speech
Technology Research, University of Edinburgh


Kevin McDonagh, Executive Director, Novoda



3



Table of Contents


Executive Summary

................................
................................
................................
............

4

1.

Background and Context
................................
................................
.............................

6

1.1

Why do we need Digimap mobile?

................................
................................
......

6

1.2

Methods and Deliverables

................................
................................
....................

6

(I)

User engagement

................................
................................
..............................

6

(ii)

Technical evalua
tion

................................
................................
........................

7

(iii)

Digimap Mobile Prototype

................................
................................
...............

7

1.3

Technical requirements

................................
................................
.........................

7

1.4

Technical approaches

................................
................................
............................

8

1.4.1

Native Apps

................................
................................
................................
.

8

1.4.2

Mobile Web

................................
................................
................................
.

8

1.4.3

Hybrid Applications

................................
................................
....................

9

2

Technical Evaluation Strand

................................
................................
.....................

11

2.1

Summary of technical evaluation experiments conducted

................................
.

11

2.1.1

Testing OpenLayers with iPhone and Android

................................
.........

12

2.1.2

Integrating OpenLayers and HTML5 Canvas

................................
...........

13

2.1.3

HTML5 local database SQL database and OpenLayers

...........................

16

2.1.4

GeoLocation API first impressions

................................
...........................

17

2.1.5

3d objects for AR browsers

................................
................................
.......

18

2.1.6

Building a native mapping app with Route
-
me

................................
.........

21

2.1.7

Automatic geo tagging
of photos

................................
..............................

22

2.1.8

A Phone Gap for a Map App

................................
................................
.....

23

2.1.9

HTML5 Cache

................................
................................
...........................

25

2.2

Summary of Technical Evaluation Strand Key Recommendations

...............

25

3

User engagement

................................
................................
................................
.......

26

3.1

Field study

................................
................................
................................
..........

26

3.1.1

Field Study User Engagement Recommendations

................................
....

31

3.2

Augmented Reality

................................
................................
.............................

32

3.2.1

Augmented Reality User Engagement Recommendations

.......................

35

3.3

Virtual reality

................................
................................
................................
......

36

3.3.1

Virtual World User Engagement Recommend
ations

................................

38

3.4

Campus applications

................................
................................
...........................

38

3.4.1

Campus Apps Engagement Recommendations

................................
.........

40

4

Digimap Pilot

................................
................................
................................
............

41

4.1

Security

................................
................................
................................
...............

41

4.2

Sustainability

................................
................................
................................
......

43

4.3

Deployment

................................
................................
................................
.........

43

4.4

Digimap Pilot Recommendations

................................
................................
.......

44

References

................................
................................
................................
.........................

44



4


Executive S
ummary


As part of the Digimap Service Enhancement programme for 2009
-
2010, JISC
funded EDINA to undertake a scoping study to investigate the potential for
delivering Digimap data and services to mobile platforms. Within EDINA we
needed to develop skills a
nd competence in relevant mobile technologies and
get a feeling for what skill sets and technology infrastructure would be necessary
to achieve a sustainable mobile delivery platform.


We organized the project into three separate strands to cover the goal
s above. A
technical evaluation

comprised a series of experiments using different
technologies to help us understand the tradeoffs and merits of different technical
approaches, code libraries and frameworks available to mobile application
developers. To un
derstand our users’ needs better we undertook a
user
engagement

exercise in which we researched extensively how people in HE/FE
are currently using our data and services for mobile applications and organized a
series of interviews with research groups and
academics across the country to
gain feedback on what EDINA could do to facilitate their activities. Finally we
designed and implemented a Digimap4Mobile
pilot application
.


The main conclusion from the technical evaluation is that the Mobile Web
approac
h is the best medium term option for rolling out the Digimap service for
mobile. Our work optimizing the OpenLayers web mapping framework for mobile
has demonstrated that this approach is feasible, although some technical issues
arose that still need some
investigation before committing fully to this approach.
Where a sustainability model requires end users to make payment to use the
service we suggest the higher speed and usability afforded by a native
application is a necessary to meet users’ expectations
. Another outcome of the
technical evaluation was the “geomobile” blog which has attracted 600 hits a
week with technical posts covering our work on integrating OpenLayers with
HTML5 particularly popular. This suggests there is some outside interest in our

approach. We therefore recommend the EDINA take a leading role in providing
an Open Source browser based mapping solution for mobile and continue to
promote this through our blog and other channels to maximize the impact of our
ongoing activity.


The user

engagement strand of the project led us to understand our users much
better. A key finding was that in areas such as fieldwork and augmented reality,
where we expected Digimap data to be in great demand, only teachers and
researchers highly skilled in GIS

and 3d visualization were making any
significant use of our data for mobile. Therefore we only found very sophisticated
applications of Digimap data (such as 3d visualizations of retreating glaciers)
while much simpler applications (such as displaying the

name and height of a
mountain) were notable by their absence.



Based on discussions with various people working in HE/FE we believe that
there may be a skills mismatch preventing more widespread use of our data in
mobile devices. For the people who want
to exploit our data for simple field

5

applications the technical barriers are too high, while for those who have the
necessary skills the barriers are too low, that is, they cannot justify standard
technical work against research goals.


We believe EDINA c
ould play a role in bridging this gap by providing easy to use
authoring and publishing tools which will enable educators to add content that
can be deployed far more easily on mobile devices. To support field exercises
we suggest a tool similar to HP’s MS
cape ( now spun off into Calvium) that has
already proved very popular in the mLearning community and schools sector.
Similarly we recommend investment in tools that make it easier to publish
content that can be consumed by emerging augmented reality brows
ers such as
Layar and Wikitude. For users aiming to create sophisticated 3d models to drive
their mobile applications, we recommend that a new tool is developed to facilitate
the process of creating these models and automating much of the laborious
manual
work currently involved
-

possibly hosting these models in virtual world
servers and 3d engines.


Talking to several users in different fields of study we discovered that our
existing tools do not always make life easy for those wanting to use Digimap
data

in fieldwork contexts and therefore we suggest some enhancement to
existing downloader facilities to allow multiple products to be downloaded at the
same time in a mobile friendly format. Further we recommend a facility that
allows users to cache their fa
vourite maps on the mobile device so that a small
area can be viewed without any data connection.


The main output from our work on the Digimap pilot is a new security model
based on a long lasting token, rather than a short lived login session used in
des
ktop applications. We recommend that EDINA follow up the Digimap pilot
with a short service transition project that will allow us to rollout a new
Digimap4Mobile product as soon as possible. Data providers such as Ordnance
Survey will need to be consulted

to ensure they are comfortable with the new
security model we have developed. The main offering will be a web based
application (for HTML5 compliant mobile browsers) that incorporate features
such as Ordnance Survey , Historic and BGS mapping, cacheable “
MyMaps”,
and “Unlock” feature search. We may also consider rolling out the iPhone
version of the pilot but a sustainability model is required for this as it is not
certain that EDINA will be able to retain the skill set needed for this and other
native ap
plications.


At the end of this project EDINA is in a much stronger position both in its
technical capability and in its links to the academic community to invest in
delivering mobile based content in a way that will address the community’s
needs. The stud
y has revealed some gaps in our current offerings and
opportunities for new services. We have gained experience and expertise
allowing us to make judgements on a sustainable approach for future
development and have generated several new ideas for research
projects and
collaborations with educators and researchers across the academic community.





6


1.

Background and Context


1.1

Why do we need Digimap mobile?


There are already many mapping products readily available on mobile devices
so delivering yet anot
her one might seem unnecessary. But the kinds of map
offered by Digimap go beyond simple road navigation and “knife and fork”
features to include historic maps, geology maps, terrain and landscape, as well
as political and administrative boundaries. The le
vel of detail and coverage is
consistent across the country, covering remote areas as well as densely
populated towns and cities. For educational uses this level of detail of coverage
is crucial as the remote, inaccessible places are often those of most in
terest to
academic study.


The Digimap service offers comprehensive information about places, not just
through maps, but through access to rich feature sets. As this report will
demonstrate, there is great potential for Digimap services to offer a unique
mobile educational experience ranging from fieldtrips to augmented reality. This
scoping study explores in detail ways in which Digimap is already and could be
further used to develop location based services for learning and teaching within
the HE/FE secto
r. We review the various technical approaches and frameworks
that could be employed to deliver these services and report our prototype
Digimap mobile service, indicating the technical and sustainability issues that
need to be resolved to roll out a fully f
eatured service.



1.2

Methods and Deliverables


We organized the Digimap mobile scoping study into three strands as below:



(I)

User engagement


The aim of the user engagement activity was to find out how people are using
Digimap already for creating lo
cation based services, what they would like to do
in future and what we could do better to support their activities. We held
interviews with people working in a range of academic and teaching disciplines
to ask them about their experience and expectations.

The feedback from these
interviews is provided throughout this report and many of our recommendations
came directly from the people we spoke to.



7

(ii)

Technical evaluation

The purpose of the technical evaluation was to review frameworks and emerging
sta
ndards that enable delivery of maps and other geographic data to mobile
devices. In particular, we targeted location aware smart phone devices such as
iPhone. The challenge is for EDINA to provide a service that will work on a range
of devices without havi
ng to develop in depth expertise in all the different native
operating systems and platforms, as this would not be easy to sustain.
Frameworks / standards such as Google geo
-
location API, PhoneGap, Layar
and HTML5 were evaluated to give an overview of how
web services can be
delivered in a portable way. While semi portable frameworks such as those
mentioned above may be sufficient for some applications it is important to
understand what the limitations are. So a comparison with what can be achieved
using a
pure native approach (such as a Android or Objective
-
C ) application
was also undertaken. Another issue to overcome is offline access to data
-

are
there solutions to serving maps from a local cache
-

again finding ways to port
the solution across differen
t platforms, browsers?

The main criteria for evaluation will be:



portability



access to sensors ( geo
-
location, camera, compass, accelerometer)



usability ( touch screen controls / gestures )



sustainability



speed



offline access

Drawing on this work we summar
ize the current state of technology and make
recommendations on how to proceed with a future service implementation. Also
a
blog

will provide comment and analysis in a more informal way as we go along.

(iii)

Digima
p Mobile Prototype


As an extension to the general technical evaluation described above we
implemented a prototype mobile application to serve OS maps to a smart phone
platform. We tried two approaches: the first implementing the map application on
a mobil
e web browser; the second using a native iPhone application framework.
We report on the usability and sustainability of each approach and make
recommendations for future rollout of a service considering different
sustainability models.



1.3

Technical req
uirements



8

Without specifying any formal requirements or use cases we have kept in mind
the overall objective of delivering a map to a smart phone device within a range
of educational contexts including field trips in remote areas, where network
connectivi
ty may be limited. It was also anticipated that the application might
assist data collection, for example, taking pictures of rocks during a field study.
The general functional and non functional requirements for such a client are
shown below.


1.

Must be abl
e to obtain a location fix through GPS.

2.

Must be able to take advantage of touch screen user gestures (e.g. pinch
to zoom in and out)

3.

Should be able to access sensors and gadgets such as the camera,
accelerometer and compass.

4.

Should be able to cache data so

that application can be used in remote
areas with limited connectivity.

5.

Should work on a range of devices.




1.4

Technical approaches


In the technical evaluation strand of the mobile scoping project we investigated
three general approaches to developin
g location based services for mobile
devices, native applications, mobile web applications and hybrid applications.
These categories are explained below:


1.4.1

Native Apps


A native application is developed using the programming language and APIs for
a sp
ecific platform. The app developer has full access to the device operating
system, sensors and user interface primitives. For example a native application
for the Apple iPhone uses the Objective
-
C language and Cocoa Touch API to
create rich internet applic
ations such as mapping clients. A developer
programming a native application for Android based devices will typically use the
Java language; for Blackberry PDAs the native language is RIM, while for
Symbian, programming is done in a specialized version of

C++. While native
applications offer the best outcomes in terms of speed and usability, the
fragmented technology base makes it hard (and expensive) for small
organizations to obtain the necessary skills to support such a heterogeneous
range of platforms
.


1.4.2

Mobile Web


Mobile Web applications make use of the mobile phone web browser to deliver
applications. Before the current generation of smart phones came to market,
most mobile web browsers were limited in their functionality compared to

9

desktop eq
uivalents and did not support technologies such as JavaScript or
Flash which are used to create rich internet applications such as mapping
clients. But the current generation of smart phones do support standards such as
JavaScript and HTML5 [1] opening up
the possibility of creating rich applications
for mobile web. Many of these new generation mobile browsers support HTML5
Cache and HTML5 Storage, enabling access to the application even when
network coverage is not available. Because the browser built in s
ecurity prevents
developers from accessing the native operating system it is not possible to get
programmatic access to some parts of the device equipment, such as camera,
accelerometer and phone. Crucially though, access to location sensors such as
GPS an
d compass can be achieved using the Geolocation API [2], which most
browsers support. This means that rich location based services can now be
developed for mobile web browser with fairly good compatibility across devices
and platforms. However, the speed a
nd usability of these applications is not
always as good as native equivalents. Also, the application can not be sold in
this format on popular app stores such as the Apple App Store or Android
marketplace. This means that developer has to find another mec
hanism to allow
the user to make payments for the service or find other ways to monetize the
application.


1.4.3

Hybrid Applications


A hybrid application is a native application with an embedded web browser so
that the advantages of both a web and native
approach are combined. Most of
the code is implemented in the web browser using standards such as JavaScript
and HTML5, which means most of the code is still portable across platforms.
Where access is needed to devices such as the camera or accelerometer,
this
can be achieved through a framework such as PhoneGap [3], which provides a
single JavaScript API for accessing sensors and devices that is the same across
platforms. Using an application with an embedded web browser or a framework
such as PhoneGap req
uires relatively little knowledge of the native language and
APIs
-

so it is much easier to develop cross platform applications without having
to develop expertise in a plethora of low level languages. However, developers
will still require basic familiar
ity with the native development environment and
knowledge of how to package, deploy and publish the applications. You can
also market the application on the App Store, although sometimes the App Store
review process may impose restrictions on the use of f
rameworks, for example,
mandating a particular stable version.


The table below shows how each of the approaches above meet the overall
requirements.


Requirement

Native

Mobile Web

Hybrid

Location
sensors

yes

Yes (via
HTML5 geo
location API)

Yes (via
HTML
5 geo
location API)

Touch
gestures

yes


Yes (partial)

Yes (partial)

Sensors and
yes

No

Yes (usually

1
0

gadgets

via framework
API)

Local storage

yes

Yes (via
HTML5
Cache and
Storage API)

Yes (via
HTML5
Cache and
Storage API)

Portable

no


Yes

Yes (partial)






The diagram below shows how we see functions fall into each of the three
approaches. In cases where the feature (e.g. “developer happiness”) could fall
into more than one category we choose the one we felt matched the feature best
based on our exper
ience, but it a subjective decision and is meant to inform
rather than dictate decision making,





One approach that does not feature in the diagram above is outsourcing. We do
not have any direct experience of outsourcing code development but we are
cer
tainly open minded about this option. As part of the project we attended
several “Mobile Monday” events in Edinburgh and it clear that many dynamic
small firms have sprung up over the last year specializing in mobile app
development for a range of platform
s. Given the market is so competitive it may

1
1

well prove cost effective to outsource development and maintenance of mobile
delivery to such firms, at least until the rapid rate of change and increasing
fragmentation in the mobile app market subsides.


2

Tec
hnical Evaluation Strand

There is a lot of debate and hype surrounding the different approaches to
developing mobile applications and the situation is constantly changing making it
difficult to reach an objective decision on which approach best suits your
organizational needs.

We were determined in this study to find out for ourselves which technologies
and frameworks worked best for our needs by actually trying out each
technology in a series of small experiments designed to tease out the pros and
cons of
each approach and particular issues related to delivery of maps and
geographic data.


To evaluate the native application approach we used an open source mapping
client framework called Route
-
me [4]. For the Mobile Web evaluation we used
the popular OpenLay
ers [5] AJAX framework and the Layar [6] and Wikitude [7]
augmented reality frameworks for testing Augmented Reality. For investigation
into hybrid application we experimented with the PhoneGap [3] framework and
our own purpose built hybrid application.


2.1

Summary of technical evaluation experiments conducted

The technical experiments conducted as part of the technical Evaluation Strand
of the work are summarised in the table below. Fuller explanation of each follows
in the narrative.


Experiment name

De
tailed in

Section

Page

2.1.1

Testing OpenLayers with iPhone a
nd
Android

2.1.1

12

2.1.2

Integrating OpenLayers and HTML5
Canvas

2.1.2

13

2.1.3

HTML5 local database SQL database and
OpenLayers

2.1.3

16

2.1.4

GeoLocation API first impressions

2.1.4

17

2.1.5

3d objects for AR browsers

2.1.5

18

2.1.6

Building a native mapping app with Route
-
me

2.1.6

21

2.1.7

Automatic geo tagging of photos

2.1.7

22

2.1.8

A Phone Gap for a Map App

2.1.8

23

2.1.9

HTML5 Cache

2.1.9

25



1
2




2.1.1

Testing OpenLayers with iPhone a
nd Android


Summary
-

A web browser based mapping client using the OpenLayers mapping
API. Modifications made to the OpenLayers event handling so that iPhone and
Android touch screen gestures can be used for panning and zooming on the
map.


In this evaluat
ion we looked at how we could best deliver Digimap content to a
mobile web browser on touch screen device such as iPhone or Android. As
these devices have built
-
in mapping applications such as Google Maps the
device owners will expect a similar level of us
er experience, in particular fast
panning and zooming and a touch screen controls.


Most web based mapping clients such as Google maps use a JavaScript (AJAX)
codebase to create a rich user experience on a web browser, where a “slippy
map” effect is achie
ved by caching many surrounding tiles in the browser to
reduce calls to the server as the user pans and zooms around the map. The
Digimap service does not use the Google API as the terms and conditions are
too restrictive. Therefore Digimap ROAM uses an o
pen source JavaScript
(AJAX) library called OpenLayers [5] instead. This popular API provides a similar
rich user experience on desktop browser to the Google offering but does not
impose restrictions. Crucially, the current version of OpenLayers does not
s
upport touch screen events and is not optimized for much smaller smartphone
screens. So to provide a version of Digimap on mobile web browser we needed
to investigate how the OpenLayers mapping API could be adapted to provide
touch screen support and impro
ved performance on mobile device such as
iPhone.


Searching through the OpenLayers mailing lists we soon found a way of applying
touch gestures to panning and zooming and posted a
blog

on this technique.
There is no doubt that the OS Mastermap product is ideally suited for the
smartphone touch screen display, with details such as house numbers rendering
very crisply and adding greatly to the user experien
ce ( see screenshot below).
Freely available applications such as Google Maps look barren in comparison
and it is clear that providing such a level of detail will greatly enhance the
potential for mobile mapping in an educational setting.


We were disapp
ointed though with the responsiveness of the panning. The
Goggle API achieves a highly responsive drag effect where the map moves with
your finger just like pressing down and shifting a piece of paper on a table. The
OpenLayers pan method in comparison is
slow and jittery with a significant delay
between the finger movement and image shift. Interestingly this problem only
becomes apparent when OpenLayers is running on an iPhone type device. On a
desktop the responsiveness of OpenLayers seems to be more than

adequate,
presumably due to the much greater CPU power. Given many other mapping
applications based on Google’s API have raised user expectation this is a
problem we need to redress if we are going to deliver a browser based mobile

1
3

map application. As we
already use OpenLayers API as the core mapping
technology in other products such as Digimap ROAM, some investment in
contributing to the project is justified. Our blog on this topic was one of the
popular we posted (over 1000 views) suggesting there is a w
ider interest in using
OpenLayers on mobile. Therefore we will work on improving the OpenLayers API
panning and zooming functionality to provide the same experience as Google
API offers, but without restrictions imposed by Google. Based on this evaluation,

we recommend the EDINA take a leading role in providing an Open Source
unrestricted browser based mapping solution for mobile.





Screen shot of OS Mastermap

on iPhone Safari browser.





2.1.2

Integrating OpenLayers and HTML5 Canvas


Summary
-

A web br
owser based mapping client using the OpenLayers mapping
API. The demo shows how the map images can be drawn on an HTML5 Canvas
allowing 2d graphics to be superimposed on the map images. Demonstrated how
this can be used to create an elevation bar chart sho
wing difference in height as
the user draws a path over the map.


As part of a series of evaluations exploring the potential of HTML5 technologies
we looked at the HTML5 Canvas 2d Graphics API [8] tried to see how this could
be used to augment the user ex
perience of a mobile mapping application.
HTML5 Canvas provides for the first time a standard way for web developers to
access the image in an HTML page at the pixel level. This means that the
developer can draw arbitrary graphics on top of the image, for
example, tracing a
route on a map ( see screenshot below). While this is potentially useful way to
annotate online maps in a browser agnostic way, we think the real potential for
HTML5 Canvas is to get inside the image itself enabling us to extract informa
tion

1
4

from it and use that information to create our own graphics on the map. We
demonstrated (see
blog
) one application, where we extracted pixel data from t
he
base map layer ( greyscale showing high regions as white and low regions as
black)


and used the extracted height data to draw an elevation graph on the
overlayed Ordnance Survey map layer. Taking this one step further we added a
Geology 50k layer, and
showed the elevation bar using the same colour as the
underlying rock type, providing a 2d geology cross section.


Other possible uses include:


Feature selection: redrawing map with features such as buildings switched on/off
similar to Digimap ROAM. Advan
tage of using Canvas to do this is that all
feature extraction is done on mobile device meaning no connection to server is
required to redraw map. Also, feature selection will work on raster map products
( such as OS 50k ) as well as vector database produc
ts ( such as Mastermap).


Reduced Map Legend: Image processing techniques can be used to perform a
statistical analysis of the map. This analysis could be used to show a reduced
map legend with just the most prominent symbols displayed in the limited spac
e
available on the mobile device rather than a full map legend showing dozens of
symbols that are not relevant to the map being displayed. Again it should be
possible to make this work offline as the information about currently visible map
items are extrac
ted from the image itself (which can be cached ) rather than from
online access to a spatial database.


Voice summary: Image processing techniques can be used to perform a
statistical analysis of the map so that a spoken summary of the area can be
construc
ted. This has potential use for sight impaired users or even to overcome
the persisting issue of sun glare or rain conditions that have been shown to
hamper map use in the field.


To achieve information extraction from an online map using HTML5 Canvas we
n
eeded to solve two problems. The first was to integrate HTML5 Canvas with the
Open Layers Mapping API. We found a method for doing this integration using
the AJAX JQuery library [9] to dynamically replace the downloaded image with
an HMTL5 Canvas element.
While there is still a bit of work to perfect this
technique the evaluation did demonstrate that it is a viable solution. This again
was a very popular post on the blog with 765 views in 3 months suggesting
others are interested in exploiting this techniqu
e.






1
5


Elevation demo: The terrain model provides a base layer where white is high and black is low.
Extracting the pixel colour using HTML5 Canvas we can get an approximation of terrain height at
a particular point on the map.







Elevation dem
o: drawing a line on a map using HTML5 Canvas. At each point on the line, the
height is extracted from the base terrain layer (above) and plotted on the bar chart.





Elevation demo: A trail around Arthur’s Seat in Edinburgh is plotted using the elevatio
n
technique.


For more complicated applications such as feature selection, reduced map
legend and voice summary the feature extraction itself is an issue as these
applications require more than simple pixel colour extraction. We implemented
some simple ima
ge processing algorithms in JavaScript, including colour
histogram comparison and Sobel Edge detection in order to identify what
symbols were present on a map image. These experiments were encouraging
but also suggested that we might struggle to get the pr
ocessing speed fast
enough, particularly on mobile CPU capacity. There is still a lot of optimization
possible in the image processing techniques and it is likely that having these
techniques available in JavaScript will prove popular with the HTML5
develo
pment community. The recommendation coming from this evaluation is
that we develop the elevation chart demo and geology cross section as part of
the Digimap service as we believe we have proved this as a concept. The
second recommendation is to try to opti
mize the image processing techniques
further and open source the JavaScript code to wider AJAX development
community.




1
6

2.1.3

HTML5 local database SQL database and OpenLayers


Summary
-

In this demo we show how HTML5 storage can be used to enable
access to

geographic features in a mobile web browser even when the device is
off line. While online, the user can enter a search term which triggers a feature
request to the Unlock service. The results of the search can be stored in the
client using the HTML5 loca
l storage interface. Once offline, these results can be
retrieved and displayed as pins on an OpenLayers map.


In this evaluation we investigated how HTML5 storage can be used to enable
access to geographic features in a mobile web browser even when the de
vice is
offline. HTML5 Local Storage provides a way for developers to cache data in the
browser using a lightweight SQL database. Following the HTML5 specification
[1] any browser supporting the technology is required to alert the user that a
website is tr
ying to cache data and imposes an initial limit of 5MB on the amount
data stored.


While online, the user can enter a search term which triggers a feature request to
the EDINA Unlock service [10]. The results of the search can be stored in the
client usi
ng the HTML5 local storage interface. Once offline, these results can be
retrieved and displayed as pins on an OpenLayers [5] map. The technique we
developed retrieved features in JSON format [11] from the Unlock Places service
and stored the JSON as a str
ing in the iPhone browser database. When offline
the application could use the Local Storage API to retrieve the JSON and this in
turn this JSON could be rendered in the OpenLayers mapping API. It is clear
this technology has great potential in educationa
l settings such as fieldtrips both
for offline data retrieval and caching user generated data. Other potential uses
include storing feature data to allow feature selection, reduced legends, active
legends, text and speech summary and even simple vector map
ping. Again this
was a very popular topic on our
blog

with total 828 views in 3 months, averaging
250 views month or 10 vies a day.





Example of cached data
retrieved


1
7

While offline using HTML5 Cache





2.1.4

GeoLocation API first impressions


Summary
-

Experiment with using the HTML5 geo location API to obtain a user’s
location on different devices such as iPhone and Android. The demo uses a
lightweight versi
on scholarly portal to perform a journal search and reorders the
search results based on the user’s proximity to the holding library.


Without the Geolocation API [2] it would not be feasible to deliver a pure web
(browser) mapping tool for mobile. Smart
phone owners are used to native
applications such as Google Maps, and therefore expect a mapping application
on a smart phone to show their current location on the map (the ubiquitous blue
dot) using built in location sensors such as GPS. The problem is th
at web
browser security model prohibits remote code such as JavaScript from being
able to access the operating system and therefore native hardware and sensors
devices such GPS are not normally available to web developers. Fortunately the
Geolocation API [
2] has been adopted by most mobile browsers making it
possible for web developers to obtain information on the users’ location in a
secure, browser agnostic and standard complaint way that respects the privacy
of user. When a user accesses a web site that
attempts to use the Geolocation
API the browser alerts the user that the website wants to access the device
location and prompts the user to confirm that they are willing to allow the website
access to the information. If the user accepts the browser will
access the
operating system to obtain the device location coordinates which the web
developer can then use in their application.





1
8

Geolocation API demo screenshot

on Android simulator showing warning that

m2m.edina website is trying to access user’s lo
cation.




The application can now use location coordinates

reorder search results.


Our first use of this was in a simple
library search application
, where a sk
inned
version of the scholarly portal was used to run a SUNCAT journal search,
passing in coordinates obtained from the geolocation API and using these to
reorder results so that the nearest holding library was shown first. We found very
few problems using

the Geolocation API and found it worked fairly consistently
across browsers. An issue does seem to arise when an attempt is made to
access location when the browser is working offline. It seems the implementation
tries to access location first by making a

call a location broker, before attempting
the device GPS. As no data connection is available the system fails and no
location is returned. Generally some extra parameters that allow more fined grain
control over the mechanism for obtaining user location w
ould be a useful
enhancement to the current standard, although as is the case with most
standards, the interface converges to lowest common denominator.


One of our first
blog postings

the stats show reasonable interest in the
geolocation API with 410 total views, averaging 50 views a month or 2 views a
day.


2.1.5

3d objects for AR browsers


Summary
-

Experiments with the Layar augmented reality browser by showing

a
3d image of a building internal structure superimposed over the camera view.



1
9

In this evaluation we set up a service that could display 3d images in the Layar
augmented reality browser [6]. The model adopted by the Layar framework is
that the Augmented

Reality browser application is provided by Layar “out the
box” for users to download to their iPhone or Android phone. Users can then
browse “Layars”, which are published collections of “points of interest” which the
Layar browser is able to access from t
he web and display as text or images on
the camera view. The “point of interest” content provider must make their data
available following the Layar API specification for the browser to consume using
their own hosting software and infrastructure. The conte
nt provider must also
publish metadata to the Layar site so that the user can discover (e.g. search for
) Layars using the mobile client.


We were fortunate to have some help from an architect called Chris Lowry from
the Edinburgh College of Art who has

a teaching method called "Building
Anatomy" where 3d models are used to show students the intricate details of the
inner structures behind building facades. We tried implementing one of Chris
models’ in a Layar provider service so that the 3d model could
be superimposed
on the camera view as the student holds up the device in front of the actual
building.


The first problem to overcome was adapting the rich 3d model from Chris
Lowry’s study into a format that the Layar browser could consume more easily.
After a fair bit of manipulation to the 3d model we did get something working and
learnt some interesting lessons around the process. First we established that
some degree of technical knowledge and infrastructure is necessary to publish to
Layar. At a min
imum, the content provider needs to implement the Layar API as
a web service using a server side language such Java. The documentation for
the API was good, but not always 100% accurate


for example some fields
specified as mandatory in the specification
were not in fact included in the Layar
browser request and it was clear from frequent updates to the wiki that the API
specification was still in a fair amount of flux.


A more pressing issue for an application such as BuildingAnatomy is the
accuracy of

GPS in urban landscapes. In built up areas GPS accuracy was less
than 70m whereas we estimate we need 0.5
-
1m accuracy to align a 3d model to
a building façade. Our workaround was to enter the location manually using the
Layar Settings page which is fine f
or testing but not a compelling solution in the
field.


We have a few ideas about ways to overcome this. One involves setting up
predefined vantage points (perhaps using QR codes [12]) to obtain an accurate
GPS reading that could be used for viewing a poin
t of interest from a known
location or to calibrate the device. Another approach that has been adopted
elsewhere [13] is to employ 3d image recognition techniques to accurately
pinpoint the users location relative to known building footprints. We recommend

further investigations into these techniques as clearly improve the accuracy of
the device geo fix is crucial to many teaching and learning applications of AR.





2
0



Building Anatomy Application: 3d image of stairwell in Evolution House




BuildingAnatom
y application:

Mock
-
up of 3d model superimposed on building facade



2
1





BuildingAnatomy application: 3d model superimposed on Layar browser AR view at 29m from
point of interest. The 3d model is slightly misaligned from the reality view. Map view

shows user
location relative to point of interest.


2.1.6

Building a native mapping app with Route
-
me


Summary
-

Using the Objective
-
C map client framework called RouteMe we
implemented a simple iPhone mapping application using Digimap historic map
data.
Functionality included panning, zooming and geo location.


To get an idea of the work involved in building a native application we developed
a simple mapping client for the iPhone. The application was tested with Digimap
Historic Town Plan maps and Ordnanc
e Survey Mastermap maps. We employed
the Route
-
me open source library [4] to get a head start in developing the
application. The Route
-
me library provides a skeleton mapping client with full
support for zooming and panning, layering and vector graphics.


The main challenge for us was that the Route
-
me framework does not support
WMS [14] directly. Instead it prefers the Tile Mapping Service (TMS) [15]
approach adopted by Google and OpenStreetMap. Fortunately, our WMS usually
sits behind a TileCache service
[16], that stores most of the maps in fast memory
and it turns out the tile cache service can be configured to accept TMS requests
without any need to change the WMS backend. While convenient, the
workaround does in some instances reduce the quality of the

rendered map as
the stack of map products and layers used for zooming has been optimized for a
WMS client where more fine grained control over the zoom level is possible.
Some more investigation is required to understand if a purpose built map stack
optim
ized for the TMS addressing system would create acceptable quality of
rendering.



2
2

This evaluation also gave us a better understanding of the learning curve for
developer to get up to speed with iPhone technologies such as Objective C and
Cocoa Touch. Ther
e are excellent resources available for learning and
developing code but nevertheless the time and effort obtaining and retaining
necessary skills is high, particularly as the technology base is changing very
rapidly with major releases of the operating sy
stem and hardware occurring
almost every year.






Screenshots of Route
-
me evaluations with OS Open and Historic data shown. Feature opacity
slider and location fix marker


At the point of writing, an open version of the native app with Ordnance
Survey
Open Data and Open Historic Maps from the National Library of Scotland is
being prepared for submission to the Apple App Store as a free app. This is to
provide us with some experience in pushing apps through the App Store review
process and to esta
blish EDINA’s presence in the market place. At the same
time, the iPhone version of the “Walking Through Time” application has been
built on top of the prototype from this evaluation and will be released to the
AppStore as part of the second phase of the “
Walking Through Time” project.


2.1.7

Automatic geo tagging of photos


Summary
-

A custom build hybrid iPhone application which integrates an
embedded web browser for online mapping with photo capture functionality
implemented in objective
-
C so that photo
s could be taken and geo tagged (using
information from the Unlock feature service) and viewed on a map interface.


In this evaluation we extended the native application described above to allow a
user to integrate the camera into the application so that
the user could geo tag a
photograph with additional gazetteer information related to the place the photo
was taken from. Typically smart phone cameras already geo tag the photograph
with longitude and latitude. In this application the photograph was tagged

with
additional information such as administrative boundaries retrieved from a query

2
3

to the Unlock [10] service. The user can then upload the image to a repository
and can thereafter switch back to a map view showing flags at the location of
photographs t
aken with the system.


The aim of this evaluation was to explore the potential for user generated data
gathering in the field. The integration of the camera device into the application
proved simple and we can see this functionality as a useful addition to

a
Digimap4Mobile client, particularly useful to help students share experiences in
the round up session after a field exercise. An earlier version of this app
integrated the camera with an embedded web browser to create a hybrid
application where the map
ping was achieved using mobile web technologies but
seamlessly integrated with the camera, something that would not be possible
with a pure mobile web application.




Screenshot from geo tagging evaluation. The photo is augmented with extra geographic
in
formation obtained from unlock service.



2.1.8

A Phone Gap for a Map App


Summary
-

Work in progress. A very early version of PhoneGap [3] was
evaluated to obtain a geo fix ( as an alternative to the geo location API) which
could then be used in web based

mapping client. We successfully deployed an
app to the Android simulator. Reviewing PhoneGap eight months later we note
significant changes in the framework so we are planning to do some further work
on evaluating the PhoneGap solution.



2
4

Early in 2008 (p
rior to the project kick
-
off) we did an evaluation of a very early
version of PhoneGap [3] framework, which provides a mechanism for developers
to access native gadgets and sensors such as GPS, accelerometer and camera
using familiar JavaScript rather than

native languages normally required (e.g.
Objective C). The framework provides a skeleton code base for each of its
supported platforms ( Android, iPhone, Blackberry) that implements access to
various sensors and gadgets in the device using a standard inte
rface that is
accessible in a special embedded browser. This means that developers can
write code for the embedded browser that can be deployed without change in
each of the supported PhoneGap platforms. While the developer needs to know
enough about the p
latform specific development environment to compile and
deploy (publish) an application, he does not need to learn a new programming
language.


In our evaluation we used PhoneGap [3] to obtain a geo fix from the GPS (this
was before widespread adoption of

the geo location API) and used the fix to
centre a web based mapping (OpenLayers) client. At the time, we found the
PhoneGap documentation for Android patchy and difficult to follow. We did
eventually manage to get the application working on an Android si
mulator but
only after considerable tweaking of both the JavaScript and native code base.
Reviewing PhoneGap more than a year later we note significant changes in the
framework and solid documentation including several books. So we are planning
to do some

further work on evaluating the PhoneGap solution as it clearly has
moved on considerably since our first look. Similarly it may be worthwhile to
evaluate W3C Widgets [17] that work in a similar way to PhoneGap but is based
on an industry consortium standa
rdization process rather than grassroots
support.


One thing we have learnt is that there is some developer resistance to using a
hybrid framework such as PhoneGap. To deploy a PhoneGap based application
on the iPhone, the developer has to sign up as a reg
istered Apple developer, pay
a license fee for the XCode development environment, learn how to compile and
deploy an application and submit it to the AppStore for review. Given all this,
many developers feel tempted to learn something about native developm
ent
techniques and as the occasional “tweak” of the PhoneGap skeleton code will be
necessary every now and then, the developer may soon become frustrated with
the constraints of the framework and insist on developing an app from scratch,
defeating the poin
t of the exercise. As well “tweak creep” another non technical
issue that emerged is the danger of the Developer License terms and conditions
restricting use of frameworks such as PhoneGap. Recent changes to the Apple
Developer licence agreement throw into

question whether applications based on
3
rd

party APIs such as PhoneGap will continue to be accepted by the Apple App
Store vetting process. A similar framework that Adobe released for Flash
developers has been rejected by Apple and although PhoneGap appea
rs to have
escaped similar treatment, the risk remains that Apple may not allow applications
to be published unless Apple approved coding libraries are used. Already only
specific versions of PhoneGap are permitted and this may reduce a developers
ability
to take advantage of new functionality (e.g. front facing camera) being
released in the latest version of the iPhone OS.



2
5

2.1.9

HTML5 Cache

Summary
-

Experiment showing how HTML5 cache might be used to create an
offline version of a mapped area. While mob
ile device is connected through a
strong network such as WIFI or 3G the user requests a cached version of the
map which is downloaded and stored in the device browser application cache.
The map can later be accessed offline when 3G connectivity is not avai
lable


In this evaluation we investigated how HTML5 Cache [1] might be used to create
an offline version of a mapped area. We attempted to implement this using the
OpenLayers mapping framework [5] with mixed success. The experiment
demonstrated that in pr
inciple this technique would work but a number of
restrictions would be placed on the service and some technical issues would
need to be resolved to put the solution into a production service.


The first restriction is that the map area has to be organize
d into a fixed set of
tiles. This is because the HTML5 specification relies on URLs to locate the
cached resource (in this case a map image) in the browser application cache. If
the parameters in the URL specifying the geographic extent (bounding box) of
t
he map are allowed to vary freely then the URL would be different even for very
similar maps. Having a fixed set of map tiles to choose from resolves this
problem.


A second effect we noticed is that once the map has been cached only the
cached version is

used from that point on even when the device resumes its
online data connection and the page refreshed. In the OpenLayers experiment
this meant that no new requests could be obtained even when the user panned
to a non cached area


essentially once offlin
e you stay offline. Finally we
noticed that the location fix obtained from the Geolocation API [2] failed when the
browser was in offline mode. This is because the browser defaulted to use Wi
-
Fi
or cell triangulation to obtain the location fix before attem
pting to access the
device GPS. In the Firefox desktop browser and Safari mobile browser we were
testing on this caused an unexpected error and the location fix failed. Clearly
some more investigation on different configurations of mapping APIs (e.g.
OpenL
ayers), the geolocation API and HTML5 Cache is needed to resolve these
issues.


Nevertheless, we think this is a mechanism that would work given some
tweaking. One way to implement this on Digimap would be to integrate caching
into the “MyMaps” function o
n ROAM and other desktop clients. When a user
saves a map the details of URLs for all tiles within a 1km area of map are
recoded and saved. While still connected to a high bandwidth data connection
the user can retrieve the “MyMap” bookmark from the mobile

device and the
mobile browser will automatically download and cache all the map images for
later use when the device has no data connection.


2.2

Summary of Technical Evaluation Strand Key




Recommendations



2
6



EDINA should take a leading role in providin
g an Open Source browser
based mapping solution for mobile.




Optimize HTML5 canvas image processing techniques further and open
source the JavaScript to wider AJAX development community to
maximize impact of the technical evaluation phase of this project.




For the time being we believe it is more cost effective for EDINA to build
relationships with external contractors and small software companies to
outsource development of native applications rather than invest in training
and maintaining native app devel
opment skills internally.


3

User engagement



The aim of the user engagement activity was to find out how people are using
Digimap already for creating location based services, what they would like to do
in future and what we could do better to support th
eir activities. We held
interviews with people working in a range of academic and teaching disciplines
to ask them about their experience and expectations. In addition, we gathered
information from papers and conferences and review these below. While by n
o
means an exhaustive, we demonstrate the range of uses that Digimap data has
been put to use on mobile devices for teaching and conducting research. We
also identify gaps where we think there is potential for greater use of Digimap
and make recommendation
s on improvements. We would like to thank the many
people who took time to speak to us and explain their work during the course of
the project.


3.1

Field study


Perhaps the most obvious use of Digimap on mobile is for field trip work,
particularly where
the subject matter is relevant to opaque aspects of the target
site, such as its history, geology, social and political characteristics, flood levels,
the built environment and land use. Pioneering work in this area has come from
the SPLINT programme [18],

where researchers have explored 2D and 3D tools
for a range of learning and teaching tasks. For example, Priestnal [19] describes
a first
-
year undergraduate geography field trip course near Keswick, Cumbria
where 3d digital models were deployed to mobile
devices to augment real
scenes with hidden (geological) and past (glaciated) landscapes. A key teaching
objective was for students to think more critically about the accuracy of 3d digital
models and by seeing the digital model imposed on the real world vi
ew they
were able to acquire a better appreciation for “ground truth”. The JISC funded
“Walking Through Time” project [20] also demonstrated how Digimap and mobile
can reveal the hidden features of place by placing historic maps “under your
feet”. Dr. Ian
Stimpson [21] reported informally on using Digimap data on PDA
device for geology field trips. Claire Jarvis and Gemma Polmear [18] have used
Digimap as background maps to provide context for students and school children

2
7

taking part in field exercises, and

integrated Digimap data with the popular
mediascape authoring tool [22]. Researchers at the University at Nottingham
developed a system that enables mobile phones to query web services offering
metadata of geoscientific datasets [23], including resources

exposed by the
EDINA GoGeo portal.




Augmented reality view of past glaciated landscape from Priestnal et al. [11]



A Kingston University group led by Ken Field report on using Geology data along
with OS topology and terrain data during a Geology field

course in Ullapool,
Scotland, where students were able to develop data collection skills for marking
geological boundaries [24]. The Kingston group also report on a fieldwork trip in
Malta where students were able to deal with problems identifying terms f
or
features by uploading pictures from mobile devices to Twitpic [29] where others
could comment creating a shared understanding of terms and improving the
consistency of data collection between groups [25]. Similarly the Kingston group
have experimented w
ith Flickr [26], 3banana [27] and MyTracks [28] for sharing
pictures, notes and location trails between students. As well as providing a
mechanism for delivering and uploading data the Kingston group have focused
on using mobile to support collaborative an
alysis of findings. In the past the
analysis of findings, reflection and sharing of data between groups occurred after
the fieldwork exercise rather than during it. The Kingston group found that the
immediacy afforded by mobile added significantly to the e
ducational impact of
the field exercise. Some tutors however raised concerns that replacing the
analogue notebook and sketchpad with instant data capture tools might reduce
the opportunity for reflection and mental abstraction.


There may be a role for Di
gimap in bringing together some of the features
needed for students to share and comment on their findings replacing the
eclectic collection of tools employed by the Kingston group with an integrated
application for gathering data, recording trails, taking

notes, annotating and

2
8

sharing pictures and communicating in the field with students and tutors. Or it
might be more pragmatic to simply integrate with the tools already available. We
have not reached a clear position on this and perhaps the best option fo
r now is
to monitor activity of Kingston and others.


While these examples of the use of Digimap in mobile is encouraging, the overall
use of Digimap to support field exercises is perhaps a little disappointing given
the potential educational applications
for Digimap in field work. Based on
discussions with individual academics we believe that a major barrier to adoption
is the technical expertise required to port Digimap data sources to mobile
applications. The relative success of more accessible technolog
ies such as the
HP’s Mediascape [22] (now Calvium [30]) and FutureLab’s school version
“Create
-
A
-
Scape” [31] suggests that if barriers are removed educators will exploit
mobile for supporting field trips far more readily. The concept of location
triggered

media is an interesting prospect for EDINA as we are in the process of
geo coding some of our media collections that could be incorporated along with
maps into a Mediascape style application. The success of institutional
podcasting initiatives such as th
e Oxford Steeple project [32] suggests there is
strong demand for delivering educational content such as lecture audio podcasts
to mobile. An interesting prospect for EDINA is to explore is the potential for geo
coding audio material using speech recogniti
on technology. So for example an
architecture student walking in a city could be alerted to part of a podcast of
lecture that mentions a building in the vicinity. Speaking to Simon King at
Edinburgh’s Centre for Speech Technology Research, the state of art

technology
may well be able to achieve a reasonable first parse, allowing the podcast author
to correct an automated transcription of places mentioned in the audio file.
However King stressed that a small scale research project would be necessary
to find
out how well speech technology could perform in this context.





2
9


Mediascape application incorporating maps downloaded from Digimap showing some point and
polygon triggers.


However, the “Ambient Woods” study [33] where c
hildren explored a woodland
with various augmented digital media sounds a note of caution, concluding that
student
initiated requests for digital information were more successful in
promoting “independent activity and reflection” than environmentally (loca
tion)
triggered media. This concurs with concerns tutors at Kingston had with the
immediacy of data capture using digital devices and suggests that convenience
of mobile can reduce rather than enhance the learning experience if applied
unthinkingly. That s
aid, we strongly believe that a well designed tool such as
Mediascape that makes it easy to create powerful location based learning
experiences would lead to a substantial increase in the use of Digimap and other
EDINA content for fieldtrip work.


The “Am
bient Woods” concept [33] of the mobile device as a data logger, where
the device is connected to a sensor or probe and records measurements for
immediate or later analysis can be extended beyond a learning experience to
large scale scientific data gatheri
ng employing members of the public to crowd
source data.
Anthony Steed and Richard Milton [34] from UCL report on a study
of environmental carbon monoxide pollution that uses a set of tracked, mobile
pollution sensors attached to a PDA device that recorded

measurements as
volunteer pedestrians and cyclists navigated an area in central London. The
authors found that the accuracy of GPS in urban environment was a significant
limiting factor obscuring identification of pollution hotspots by placing pedestrians

in the middle of the road or wrong side of junctions.



3
0



Example of a GPS trace where you cannot immediately tell which side of the road the pedestrian
is on


from Steed and Milton [34]


Digimap OS Mastermap was essential in the analysis stage both to v
isualize
results but perhaps more importantly to improve the accuracy of the GPS traces.
Using knowledge of building footprints, the geographic extent of trail and features
such as bus stops and junctions on the route the authors were able go from
plotting

maps of pollution at a 20m scale to a 5m scale.


Even for those that do possess advanced skills in GIS, interviews we conducted
suggest that we could do a lot more to assist educators in exploiting Digimap for
field trip work. The suitability of data dow
nload is critical, as most of the time field
trip cannot rely on web access, so the data has to be downloaded and cached on
the device. Those that have been through the process of downloading our data
and transferring it to mobile have not found it particu
larly easy. Typically more
than one product is wanted for fieldtrip work so download facilities that only allow
one product ( e.g. OS Mastermap, Historic, Geology) to be downloaded are not
optimal. Even when the field trip organizer has downloaded all the
content they
will often have to use a desktop GIS to realign and rescale the products so that
they can be layered into a composite map of the field trip area. Speaking to field
trip organizers it is clear that for the purposes of mobile a much simpler
dow
nload tool is needed, that simply allows the user to select an area of interest
and obtain a cacheable dataset that incorporates data from a number of products
and collections ( OS, Geology, Historic) that can be easily deployed on a range
of mobile devic
es.


One solution is to create a new download service that allows downloads of data
across collections in addition to the existing collection oriented downloaders.
Changes to the current licensing regime may facilitate this as it should lead to
more insti
tutions subscribing to the full set of Digimap collections rather just
Ordnance Survey. However we need to recognize that only a limited number of
people will have the technical skills to make use of raw data and deploy it to a
mobile device. We suspect a
much wider group of people would want to use
Digimap data for fieldtrip work if we could make the process as simple as
panning to an area in a map a clicking a “make this map mobile” button.


Bringing this requirement together with the work we have done i
n the technical
evaluation strand of the scoping study on HTML5 Cache and HTML Local
Storage we think it might be possible to extend the existing “My Maps”
functionality in Digimap ROAM so that when a map is bookmarked an HTML5

3
1

Cache manifest is created wi
th links to all the map images required to view and
navigate a 1km area around the map.



Once the map is bookmarked in this way the user can retrieve the bookmark link
(for example via QR code) on an HTML5 compliant mobile browser which will
then automati
cally download all the images and features and store them in the
browser for later use in the field. The technical issues described in the evaluation
work we did on HTML5 Cache and HTML5 Local storage would need to be
addressed but the simplicity of the so
lution is appealing.



As well as use in the field, Digimap also has an important role in the preparation
and planning of the trip. For example a botany graduate[35] employed both
modern and historic maps to locate potential sites for monkshood native habi
tats.
Ideally we would be able to go one step further, allowing Digimap users to easily
transfer the work they have done preparing for a field trip ( deciding where to go )
to actually using the material in the field on a mobile device. Similarly, once the

field exercise is completed any data gathered during the field exercise could be
reviewed by superimposing the data on the original field material or incorporating
the data into an automatically generated micro site that provides a summary of
the places v
isited and observations recorded [36]. The augmented “map table”
described in the section below could be another mechanism for students to
share and reflect on their experience in the field while events are still fresh in
their mind. The conclusion from t
his is that the design of a Mobile Digimap
offering to support fieldtrip work must address an integration of activity before,
during and after the field exercise. This was a point stressed by many of the
people we spoke to and must be the guiding principle

for any Digimap fieldtrip
implementation.


It is also clear from interviews that EDINA could do some low tech things to help
users without building new or amending existing software. Some simple ideas
that were suggested to us included creating pre
-
packag
ed map stacks for UK
campus locations that can be downloaded and used on mobile devices for
campus based applications without any post processing, creating a series of
simple learning resources explaining how to get started in developing location
based ser
vices and open sourcing code for performing simple geospatial
operations such as converting long/lat to various projections. Some of these
ideas are already being implemented in GoGeo, ShareGeo and the geo mobile
blog.



3.1.1

Field Study User Engagement R
ecommendations




Develop a simple multi product download tool that makes it simple to
obtain and port mapping data to mobile devices.




Investigate potential to integrate Digimap data into a Mediascape style
authoring tool. JISC should open discussion with C
alvium to leverage
existing user community.



3
2



Enhancement to ROAM “My Maps” to enable one click caching of an area
of interest on the user’s phone.




Prepare pre
-
packaged campus map stacks to support campus based
activity.




Prepare to simple “How to” geo mo
bile teaching resources and continue
to reach wider community of mobile developers through geo mobile blog.



3.2

Augmented Reality


AR is an emerging technology that has great potential for creating innovative
teaching and learning experiences by “enhanc
ing the user’s perception and
interaction with the real environment by superimposing the real world with virtual
information that appear to coexist in the same space as the real world.” [37]


The widespread use of Augmented Reality in HE/FE is suddenly fea
sible as
devices equipped with camera rendering, location and orientation sensors (GPS,
compass, accelerometers) are much more affordable and ubiquitous [38]. We
have recently seen a wave of Augmented Reality applications such as Layar [6]
and Wikitude [7]

launched on popular devices such as iPhone and Android
bringing this technology to a mass market for the first time.


There are already a few notable examples of Digimap data and services being
employed to create augmented reality applications on a range
of mobile devices.
The section on field work already highlighted the SPLINT [18] team’s use of
augmented reality to enhance real scenes with hidden (geological) and past
(glaciated) landscapes [19]. Researchers at City University, London, describe an
educa
tional game for GI Science students where a 3d urban landscape was
superimposed onto tangible marker cards which the students fit together like
pieces in a jigsaw puzzle [37]. OS Mastermap data was used, along with
separately sourced digital terrain data f
or the rooftops to create a 3d model of
urban landscape
.


The data flow for creating the 3d reconstruction in this paper is representative of
the general approach ( see for example [39] and [40] ) to creating virtual urban
landscapes for use in mobile and

elsewhere.



3
3




1. Input data is merged and pre
-
processed. 2. A desktop GIS is used to extrude 2d polygons into simple 3d
model 3. A 3d modelling tool is employed to calculate normals, faces, lighting information, texture
information and shadows improvi
ng the realism of the model. 4. The 3d model is converted to a format (
e.g. VRML) that can be used in mobile AR client. From Liarokapis et al. [37]



In a similar fashion a research group at Edinburgh University employed
Mastermap to create a speech based

augmented reality system to help people
navigate city landscapes without having to peer at a map on a screen every two
minutes. Key to this research was the ability to determine the user’s line of sight
using a 3d viewshed model. Again OS Mastermap was us
ed to provide building
footprints which combined with LiDaR data (provided by the Environment
Agency) enabled the authors to determine which points of interest were within
view, using a speech interface to notify the user of visible features [41].
Augmenti
ng location based services with line of sight information was highlighted
by several people we spoke to working in the area of mobile learning as an area
where EDINA could help educators and researchers developing mobile learning
platforms.




Speech Based Augmented reality system to navigate City landscapes [41] using line of sight
model to notify user when a feature



3
4

There has been a great buzz [42] around the use of augmented reality
frameworks such as Layar [6] in education
, but so far we have not seen any
examples of these relatively accessible AR technologies being used for teaching.
It is possibly too early to expect applications to have surfaced yet, but our own
evaluation (see technical evaluation) suggests that there a
re significant technical
barriers for educators that wish to publish content for AR. Our evaluation also
highlighted problems relating to accuracy of GPS in urban landscapes where tall
buildings reduce accuracy by as much as 90m in some areas. We think tha
t this
problem can probably be overcome by defining vantage points that users can
navigate to and serving points of interest relative to these vantage points. It
might even be possible to use a vantage point to ascertain the error in GPS for
given location

and automatically correct future readings. Another technique for
overcoming this issue may be using 3d image recognition to pinpoint the user’s
location more accurately relative to building outlines [13, 39 ,43].


So far the research we have seen focuses
on superimposing 2d and 3d models
into reality view. Digimap data has been used for building 3d models rather than
used directly. There is a notable absence of low tech solutions using simple point
of interest databases such as OS 50k gazetteer (Unlock), B
GS rock images and
height point data. It seems fairly obvious to us that an augmented reality
application that superimposes rock names and 2d rock images on a reality view
would have educational value. So why is all the attention on extremely difficult
app
lications involving 3d modelling and view shed analysis, rather than simple
text and 2d image augmented reality views?


Perhaps for the people who want to exploit these simple applications the
technical barriers are too high, while for those who have the
necessary skills the
technical barriers are too low, that is, they cannot justify the low level technical
work against their research programme objectives. We believe EDINA could play
a role in bridging this gap by providing easy to use authoring and publi
shing tools
which will enable educators to create augmented layers that can be consumed
by AR browsers such as Layer [6] and Wikitude[7]. These tools would allow
users to add their own points of interest and 2d images, and possibly 3d models.
They should a
lso be able to create their own layers from already available points
of interest database such as Unlock ( e.g. place names, administrative
boundaries).


To help those wanting more sophisticated augmentations providing a download
tool that combines Master
map data with digital terrain data and LiDaR data
sources would significantly reduce the effort for researchers wanting to use 3d
models in augmented reality applications. We quizzed people who were using
AR whether such a facility should be provided as an

API where 3d data could be
streamed to individual devices via a cloud service. Most thought that the priority
is to make the data available in a convenient format for download rather than
attempt to offer a streaming service. An ideal solution would allow

users to select
a geographic extent (bounding box) and then obtain 3d model of the area in a
useful formats such as VRML [44] or X3D [45], generated from automatic merger
of Mastermap, Digital Terrain Model and LiDaR data sources. There was more
support t
o offer a “line of sight” data as online API but again a download facility
which cut out the cumbersome data processing steps involved in merging

3
5

Mastermap with LiDaR and extruding building footprints to the correct height was
seen as the most important co
ntribution we could make.


Another take on mobile that John Traxler and others have highlighted views the
mobile device as a “virtual limb” or as Charlie Schlick, Product Manger at Nokia
put it “our new private parts” [46].A good example of this “prostheti
c” view of the
mobile device is work being done by Chris Kray at University of Newcastle [47,
48 ,49].


Kray’s research focuses on the mobile device as a tool for collaborative spatial
interaction between individuals. Rather than using the mobile screen t
o display
data from an external source, the mobile screen is used as a way for users to
show and share with others personal data they hold on their device, such as
photos or calendar schedules. One approach the Newcastle team have
developed employs spatial

proximity regions around mobile device on a normal
table to facilitate a collaborative task such as agreeing a future meeting [47]. A
camera
-
projector system uses dynamic visual markers displayed on the screen
of the mobile device to track where users are

moving their device on a tabletop.
The projector displays different regions on the tabletop where users can push
their device to share information, such as photos or calendar events. This allows
convenient transfer of data from one personal device to anot
her, or to a shared
space. A key difference between this form of interaction and a shared touch
screen display is that users retain ownership of their actions and their data as it
is possible to trace each user gesture to an individual device.


This versi
on of augmented reality has great potential for teaching and learning as
it greatly facilitates pedagogic objectives such as student initiated learning and
peer instruction. A relevant application to maps is a student project supervised
by Kray where devic
es are used to display geo
-
tagged media (photos, GPS trail)
on a tabletop displaying a map, so that individual’s geographic footprint can be
seen by a group engaging a collaborative task. We can envisage this working
well in a field trip exercise when grou
ps meet up at the end of the day to review
and share their findings.





Some screenshots of the “augmented tabletop” from Kray et al. [47]



3.2.1

Augmented Reality User Engagement Recommendations



3
6



EDINA should Source LiDaR data from MIMAS
or Environment agency or
elsewhere.




Develop a download service that automatically merges LiDaR with OS
Mastermap and DTM data to create a 3d model of a selected area in
formats such as VRML , x3d that can be used in gaming and virtual reality
engines.




Pr
ovide line of sight data as a further output.




Provide easy to use authoring and publishing tools that make it easier for
people to add simple points of interest data and 2d images to a spatial
database that can serve data to Augmented Reality browsers su
ch as
Layar and Wikitude.



3.3

Virtual reality


While the application of mobile to augmented reality was clear to us from the
start it was not until we started talking to people working in the field of mLearning
that we realized the importance of virtual
reality for mobile. Our initial thought
was “Why would you want a virtual world (metaverse) to be modelled on the real
world? What does mobile add to the virtual world?” Use cases that people have
suggested include enabling remote access to field trips for

remote learners and
disabled students; orchestrating field trip “pre
-
visits”, so that students can get
more out of planned field exercise by first familiarizing themselves with the
terrain in a virtual environment; to help students transition to a new sch
ool by
becoming more familiar with a new school environment and helping students to
make good career decisions by playing out different career options in a virtual
environment.


To a certain extent some of the use cases described might be achieved with a
3d
model rendered on a desktop computer, so it is not immediately clear how either
mobile devices or a multi player game engines such as Second Life enhance
the user experience.


The advantage of a multi player virtual reality platform in this context is
that the
virtual user can enter the same space occupied by real world “players”, so for
example a person taking part remotely in a field trip can see where other
participants are and interact with them. The role of mobile devices is to provide
the link bet
ween the real world and the metaverse. While the participant in the
real world may have a richer experience of the environment in some ways ( for
example being able to pick up and feel a rock ) the virtual participant may have
access to supplementary digit
al information ( e.g. description of rock types ). The
real world participant can use a camera phone to show the virtual player real
world features (augmented virtuality) while the virtual participant can show the
digitally augmented view to those on the g
round (augmented reality). So working
together the participants can share a space in different modes of reality, with
each perspective enriching the other.


3
7


Wright at al [50] have coined the term “virtual duality” to describe the new form of
interaction af
forded by overlaps between the real world and a social metaverse.
Wright et al. demonstrate how a novel application of the camera phone where
image processing techniques can be employed to create “portals” between the
real world and a metaverse, where imag
e matching is used to trigger the
metaverse to change. [43, 50]. The potential power of this new mode of
interaction for learning has excited many people working in mobile learning. In
the editorial to the “Big Issues in Mobile Learning” report Mike Shar
ples argues
that we have an opportunity to “…create extended learning communities, to link
people in real and virtual worlds, to provide expertise on demand, and to support
a lifetime of learning. “
[51]


Musolesi et al. describes a novel technique for det
ecting a user activity (sitting,
running, conversation) from sensors in a mobile device and mapping these to
avatar activities in Second Life such as flying (triggered by real world running),
hovering yoga (real world sitting) [52] . The authors suggest
this could be used
in social networking sites such as Facebook to provide a visual status of current
activity. The authors did not make use of geographic data but it is clear that
actions could also be mapped based on a user’s location (e.g. sitting in caf
é
maps to drinking a coffee)


As part of the Digimap 3d project, EDINA has already created models from
Digimap Mastermap and Digital Terrain datasets and imported these into an
OpenSim virtual world engine [53] hosted on our severs. We identified both
proc
essing data and infrastructure requirements as areas where EDINA
expertise may come into play. As part of the user engagement exercise we have
now established several contacts with educators who have expressed an interest
in using such a hosted virtual wor
ld to support teaching and learning activity. We
recommend that JISC encourage such collaboration with a view to exploring the
potential for EDINA to host virtual worlds as cloud based service.



3
8



SecondLife client showing screenshot of remote user intera
cting with virtual world based on
Digimap data


3.3.1

Virtual World User Engagement Recommendations




EDINA should collaborate with research groups and teaching
professionals on projects exploring the reality
-
virtuality continuum in
teaching and research, e
xploiting the network built up during this study.



3.4

Campus applications


While the focus of this study has been on the use of mobile for teaching and
research, as this is where we expect to see the greatest interest in Digimap
Mobile, the focus of mobi
le application development in HE/FE so far has been in
building Campus applications. These applications provide information to
students and staff about their daily activities such as lecture times and locations,
bus timetables, library opening times and r
esource availability ( e.g.
workstations, books). Sometimes these applications are adapted to support
conference delegates with information relevant to a particular event. While many
of these are location based services and incorporate maps, none have made

use
of Digimap, instead using Google or OpenStreetMap data and web services. We
expect that this is due to poor awareness of the Digimap service in IS
departments and restrictions on access to the data that might require an
institutional login to an other
wise open Campus application.



3
9

However it would be a mistake to think that Digimap does not have anything to
offer. There are some advantages to using OS data for these applications
including more detailed building footprints, more regular, consistent upd
ates
capturing new estate (building) developments, and access to height data
allowing better routing for pedestrians, cyclists and wheelchair users. As the
existing campus applications become more sophisticated and incorporate
augmented reality and 3d imag
es the greater accuracy and detail afforded by
Digimap services may become important to Campus application developers.
Below we briefly review current activity in Campus mobile development and
make recommendations as to how EDINA and Digimap can facilitate

this activity.
With the release of OS Open Data, we may well be able to overcome the login
issue and provide both maps and feature data in a format that is easily accessed
by departments. Although important datasets such as Mastermap would not be
availabl
e using an Open API, such a service would offer a more detail than
Google with fewer limitations on use.


Fragmentation of the mobile technology market is a significant factor for
institutions creating Campus applications as they need to offer a service to

the
entire student community. Developing and maintaining software for the range of
different devices, operating systems and technologies that students will use is
not practical given limited resources available. There is some evidence that the
penetration

of smart phone devices such as the iPhone is greater in the student
population than the general public, with an informal survey at Sheffield reporting
30% of students owning a smart phone [54] and Edinburgh University survey
report some 50% of students us
ing a smart phone [55]. A problem with
comparing such studies may lie in the definition of a smart phone with some
institutions taking the view that smart phone is a device which puts the internet at
the heart of the user experience while others include an
y device with an internet
connection (feature phones with browser).


Institutions have so far taken two paths either opting to outsource development
or use a web browser application that works on a range of devices. The easiest
option is outsourcing dev
elopment and maintenance to a software company that
specializes in making content available on a range of devices. Many such
companies have sprung up recently creating a highly competitive market and a
good choice of solution providers. Some companies such

as oMbiel [56]
specialize in bespoke products for universities and colleges. Christine Sexton,
Director of Corporate Information and Computing Services, University of
Sheffield reports that oMbiel was able to deploy a fully functional campus
application b
ased on the mCampus product within 6 weeks [54]. Such a short
time to launch is a compelling argument for an institutional manager working in
an environment where it can take at least 6 weeks to recruit a new software
developer.


Despite the obvious benef
its of outsourcing some institutions prefer to develop
applications in house. Most have chosen to take the Mobile Web route to
achieve access on a range of devices. The client itself does not prove that
difficult in most cases to develop, especially since
the geolocation API [2] has
made it much easier to implement location based services using web browser
technology. The difficulty is in obtaining the data on lectures, timetables, bus

4
0

services etc and integrating all the data so that it can be linked and r
etrieved in a
flexible way. An important factor in success is finding ways to publish the various
data in standard formats such as RSS and Atom. This allows for a lightweight
integration of data from heterogeneous sources. Once the data has been
sourced an
d published, it can be used for other purposes such as updating
plasma screen notice boards.


At Oxford, researchers working on the JISC Erewhon project [57] went one step
further and developed a semantic model for campus applications allowing more
sophis
ticated temporal searches using the SPARQL semantic query language.
The Oxford group have opened sourced their framework [58], separating Oxford
specific (including semantic) components, leaving reusable user interface
artefacts that link to a set of open
standard channels such as Service Status
RSS and Z39.50. The mapping client is based on OpenSteetMap and can import
OpenStreetMap feature data as well as public transport access points from the
NaPTAN database. Overall this provides a good basis for develo
ping web based
Campus applications and it will interesting to see if other institutions adopt it.
Similarly the Mobile Campus Assistant , from the University of Bristol have
developed their own campus system using semantic web technologies such as
SPARQL.
The motivation for this appears to be a general preference for
semantic web technologies rather than a specific requirement ( e.g. natural
language processing) for Campus applications.


In a departure from the standard “where’s the nearest PC” campus appli
cation
the innovative iBorrow project [60] focused on laptop usage within a building.
The infrastructure employed the Cisco Mobility Service Engine technology to
create a real time location system that was able to track and report on the use of
iBorrow lap
tops as they moved between different zones within a library building.
The project broke new ground in two areas


first reducing the proximity of
campus applications from the street level to spatial relationships within buildings
and second in harnessing m
obile devices to gather data to help resource
managers understand how spaces and facilities offered by the University are
being used.


It is evident that existing campus applications have not needed Digimap up to
now but as these applications become more s
ophisticated and require greater
accuracy in location based searches some opportunities are likely to emerge.
Areas where EDINA services and expertise may come into play include the
provision of augmented and mixed reality APIs, developing security solutio
ns for
shibboleth protected services and guidance on geospatial standards and spatial
ontology.


3.4.1

Campus Apps Engagement Recommendations




EDINA should provide Ordnance Survey Open Data to make it as easy for
Campus application developers to use the n
ewly released Ordnance
Survey data. This will provide developers with better quality, more
accurate and up to date data than they are able to achieve with existing
offerings.


4
1




EDINA should engage more with IS departments to see what services we
can offer
in building campus location based services and create synergies
for those managing resources.




EDINA should design and implement an Augmented Reality / Mixed
Reality API and make this available for institutions to create points of
interest with associated
media such as 3d objects and images and serve
these to AR campus clients.




4

Digimap Pilot


Bringing together lessons from the Technical Evaluation and User Engagement
study we have created two simple pilot applications: a native application for
viewing
Digimap data on an iPhone and a web based application for viewing
Digimap on full spec mobile browsers such as Safari and Opera. The aim of
these pilot applications is to understand what is needed to rollout a version of
Digimap for mobile and to gather so
me user feedback. The primary issues we
addressed were security, deployment and sustainability.



4.1

Security


Defining a workable security model is a major hurdle for both the native iPhone
app and the mobile web app. In theory, the Mobile Web approach s
hould just be
a matter of porting the desktop browser security model to the mobile browser. In
practise, we need to recognize that mobile web browsing has a very different
usage pattern to desktop browsing. Mobile devices are optimized for short bursts
of
infrequent activity whereas desktop browsing generally involves much longer
periods of user interaction. The desktop version of Digimap implements a twenty
minute timeout function, where the user is automatically logged out after twenty
minutes if there is

no activity (panning and zooming). The mobile usage pattern
does not fit this pattern at all. Even if the user is constantly checking their
location on the device, this may not involve any panning or zooming activity
needed to trigger a new request to the

server. Also the need to login on a
frequent basis is more tedious on a mobile device, particularly as many
institutional login pages are not optimized for mobile screen resolutions. The
native application has the same problems but with additional proble
m that
browser artefacts such as cookies are absent. This makes implementation of a
shibboleth login an additional hurdle to overcome.


The model we have developed for the pilot application is a pragmatic solution
that allows the user to obtain a long last
ing security token that can be appended
to the url of the pilot service and used for several weeks without the need to login
again. The user simply logs into Digimap on the desktop as usual and navigates

4
2

to Digimap4Mobile page where they can generate a lin
k based on their Digimap
id which they can then use to retrieve maps on their personal mobile device for a
fixed period of time. For convenience the link is displayed in the form of a QR
code [12] so that all the user has to do is take a picture of the scr
een in order to
transfer the link to their device. For the native iPhone app the QR code reader is
built in to the application. For the web app the user is expected to download a
separate QR code reader to their device.



Example generated QR code with u
ser specific security token. Taking picture with mobile will
enable access to map.



Although the long lasting security token can only be obtained by an authorized
user the long duration of the token increases the risk of a security breach as the
link coul
d easily be passed on to unauthorized users. To mitigate this increased
risk several additional authorization steps are introduced. First, the
authentication proxy checks that the request came from a recognized mobile
user agent ( e.g. a mobile web browser
) rather than a desktop browser. By
limiting the use of the token to mobile browsers the ability to share the link widely
is reduced. Also a limit of 500 requests per hour is enforced. This is more than
enough for a single user on a single device given typ
ical mobile usage patterns
but would be quickly exhausted if the link was shared by several users or being
used to republish data. Another check can monitor the geographic proximity of
requests using the same token to spot situations where a user appears t
o be in
two places at the same time. We think the above measures should be enough to
mitigate the risk of long lasting tokens and reassure data providers that security
standards are being maintained. At the same time it provides an easy way to
secure a mob
ile service that is practical for the user and supports mobile usage
patterns. We did also consider an option that requires the user to register their
device against their Digimap identifier. While this would strengthen the security
model we wonder whether

it is really necessary and prefer to avoid the
administration overhead and hassle for users of another registration system.


4
3



4.2

Sustainability


The purpose of developing a native iPhone as well as a browser based pilot is to
properly understand the sust
ainability issues. How long does it take to push an
app through the Apple review process? What administrative overheads are
involved? Do we need to run a separate map server for the iPhone application?
How often are we required to update an application on
the AppStore? It will take
a period of time successfully running the pilot before we know the answer to
these questions. Running at least one native application alongside a web based
app should gives us some indication of whether it is worthwhile to invest

in native
applications as well as a web browser version. While we expect the native
application to have more functionality and run faster the work we have done as
part of the technical evaluation has demonstrated that maintaining a skill base
across a num
ber of mobile platforms will require additional investment in
resources. The web based version also requires some additional resource to
maintain a new delivery channel but the skills required are roughly the same for
each mobile platform and more closely
aligned with the desktop technologies.
Therefore while it is feasible that the web based version could be absorbed by
JISC and/or institutions, it is likely a new model is needed for delivering native
applications. A model where individual users pay for a
native application ( or part
of it), while access to a web based version is free to students and staff from
subscribing institutions may merit some investigation. If the cost cannot be
absorbed even for the mobile web version, consideration needs to be giv
en to a
micro payments mechanism for web based applications. This might be more
controversial as previously all Digimap services have been free to use at the
point of delivery for students and staff. While it is true both the data and ability to
hold data
on a mobile device are already allowed by existing Terms and
Conditions, the perception around fairness of any pay service could be difficult to
manage. The underlying problem is finding a way to separate the price of the
service from the price of the data
. As institutions have already paid for the data it
is important to make a distinction in the way that the service is promoted, so that
users and institutions do not feel they are being charged twice for same thing. As
the questions raised touch on strateg
y and policy these sustainability issues
have been flagged to EDINA management and we should be able to report in
due course on the outcome of these deliberations.


4.3

Deployment


Do we want the same stack of maps on mobile as we do on desktop clients?
Wh
ile we have found the mobile screens render most maps adequately on the
devices we tested, it is clear that how we organize the maps is important.

For example, on the desktop version of Digimap the default is to start with a map
of the UK. But for mobile u
sers a map of the UK is rarely useful and defaulting to
a scale of 1:10k or larger centred on the user’s current or last known location is
essential.


4
4


Historic Digimap is a good example of how mapping needs to be organised
differently on mobile. In the de
sktop version (Ancient ROAM) a large number of
zoom levels are available to capture all the different map products across the
country at their optimum scales. When the user zooms in to a particular scale,
decades where data at that scale is available are h
ighlighted. While making best
use of the data available this would be very difficult to port to mobile. Our work
with Edinburgh IS Apps and the Edinburgh College of Art in the “Walking
Through Time” application [20] suggests that for mobile it is better to

make fewer
products and scales available even if this reduces the geographic extent of the
application. Compromises may be necessary to ensure the user can access
maps from different time periods, sometimes using products at scales that are
not optimal an
d thus reducing the quality of rendering. Similarly, some of the
detail in geographic features and symbols that make the desktop Geology client
so rich are wasted on a small mobile device. We found in experiments that
excluding some of the geology layers g
reatly improved the speed and usability of
these maps on mobile devices.


A fair amount of work is still required to understand the best configurations of
maps to include in a Digimap mobile service. It could be that slightly different
versions of the mo
bile client will be required for different user scenarios or even
for different locations.



4.4

Digimap Pilot Recommendations




Rollout Digimap4Mobile pilots for both Mobile Web Browser and iPhone
native app. Obtain feedback from users to inform decision
on long term
sustainability model.




Agree security model with data providers based on WSTERIA web service
approach.





References


[1] Hickson, I. (ed) “HTML5: A vocabulary and associated APIs for HTML and XHTML”
available at: http://dev.w3.org/html5/spe
c/Overview.html, W3C, 18th June 2010,
[accessed 21st June 2010]


[2] Popescu, A. (ed) “Geolocation API Specification” available at:
http://dev.w3.org/geo/api/spec
-
source.html, W3C, 10th February 2010, [accessed 21st
June 2010]


[3] PhoneGap,
http://www.phonegap.com/

[accessed 21st June 2010]



4
5

[4] Route
-
me, “Open Source iPhone native slippy map”,
http://code.google.com/p/route
-
me/

[accessed 21st June 2010]


[5
] OpenLa
yers: Free Maps for the Web,
http://openlayers.org/
, [accessed 21st June
2010]


[6] Layar Reality Browser, available at
http://layar.com/

, [accessed 21st June 2010]


[7] Wikitude,
Mo
bilizy

Mobile Software, available at
http://www.wikitude.org/

,
[accessed 21st June 2010]


[8] “HML5 Draft Standard 15th June 2010


the Canvas element”, available at

http://www.whatwg.org/specs/web
-
apps/current
-
work/multipage/the
-
canvas
-
element.html
, [accessed 21st June 2010]


[9
] JQuery JavaScript Library, available at
http://jquery.
com/
, [accessed 21st June

2010]


[10] Unlock , EDINA, available at

http://unlock.edina.ac.uk/
,
[accessed 21st June

2010]

`

[11
] JavaScript Object Notation, available at
http://
www.json.org/
,
[accessed 21st June
2010]


[12] ISO/IEC 18004:2006
Information technology



Automatic identification and data
capture techniques



QR Code
2005 bar code symbology specification
, 2006 , ISO,
[not
accessed]


[13
] Earthmine Localization, available at
http://www.earthmine.com/index
,
[accessed
21st June 2010]


[14] Beaujardiere, J (ed) “
OpenGIS Web M
ap Service (WMS) Implementation
Specification, version 1.3” , OGC, 2006, available at:
http://www.opengeospatial.org/standards/wms
,
[accessed 21st June 2010]

[15] Tile Map
Service

Specification, a
vailable at
ttp://wiki.osgeo.org/wiki/Tile_Map_Service_Specification,
[accessed 21st June 2010]

[16]
TileCache, MataCarta, available at
http://tilecache.org/
,
[accessed 21st June
2010]


[17]
The Widget Interface, W3C C
andidate Recommendation, available at
http://www.w3.org/TR/widgets
-
apis/

[accessed 21st June 2010], W3C,
December
2009


[18] Spatial Literacy in Teaching (SPLINT) Project Home Page, available at
http://www.le.ac.uk/gg/splint/overview.html
,
[accessed 21st June 2010]


[19] Priestnall, G. (2009) 'Landscape Visualization in Fieldwork', Journal of Geography in
Higher Education, 33:1, S104
-

S112

http:/
/www.informaworld.com/smpp/section?content=a915789282&fulltext=713240928


4
6

[20] Walking Through Time Project homepage, available at
http://walkingthroughtime.eca.ac.uk/
,
[accessed 21st June 2010]


[21] St
impson, I. Boys Toys, blog enrty available at:
http://hypocentral.com/blog/2008/02/21/boys
-
toys/

[accessed, March 2010]


[22] Mscape, available at http://www.mscapers.com/,
[accessed 21st Ju
ne 2010]


[23] Hobona, G. Jackson, M. Jordan, C. Butchart, B. Location Based Services for
Discovery of Geoscientific Datasets During Fieldwork, submitted to
Computers and
Geoscience Journal


[24] Field, K. S., Grocott, J., Lynch, K. and Smith, M. (2005) G
IS in the real world: Using
mobile technology in fieldwork (MOTIF), Proceedings of the fifth Annual ESRI Education
Conference, San Diego, 23rd
-
25th July 2005


[25] Field, K., O’Brian, J Taking GIS out of the classroom: developing effective learning
environ
ments with mobile GIS, proceedings of the GIS Reseach UK 18
th

Annual
Conference, University College London, 2010


[26] Flickr homepage, available at
http://www.flickr.com/
, [accessed 21st June 2010]


[27] 3banana, S
naptic products, available at
https://snaptic.com/products/
, [accessed
21st June 2010]


[28] MyTracks for Android project home page, available at
http://code.g
oogle.com/p/mytracks/
, [accessed 21st June 2010]


[29] Twitpic,,
http://twitpic.com/
, [accessed 21st June 2010]


[30] Calvium,
http://www.calvium.com/
, [accessed 21st June 2010]


[31] Create
-
A
-
Scape project homepage, available at
http://www.createascape.org.uk/
, [accessed 21st June 2010],

FutureLab, Feb 2007


[32] Steeple project homepage,
http://www.steeple.org.uk/wiki/Main_Page
,
[accessed 21st June 2010]


[33] Y. Rogers, S. Price, G. Fitzpatrick, R. Fleck, E. Harris, H. Smith, C. Randall, H.
Muller, C. O’Malley, D. Stanton, m. Thompson, and M. Weal. Ambient wood: designing
ne
w forms of digital augmentation for learning outdoors
. In IDC ’04 Proceedings of the
2004 conference on interaction design and children
, pages 3
-
10, New York, NY, USA,
2004. ACM


[34] Steed, A., Milton, R. (2008) Using Tracked Mobile Sensors to Make Maps

of
Environmental Effects. Personal and Ubiquitous Computing, 12(4), 331
-
342


[35] Duffel, Mark (2005) “Monkshood (Aconitum napellus agg.) in Shropshire”,
Shropshire Botanical Society Newsletter Autumn 2008, p5.
http://www.bsbi.org.uk/Botanical_Newsletter_
18.pdf


[36] T.

D. Collins, P.

Mulholland, and Z.

Zdrahal, "Using mobile phones to map online
community resources to a physical museum space,"
International Journal of Web Based

4
7

Communities
, vol.

5, no.

1, pp. 18+, 2009. [Online]. Available:
http://dx.doi.
org/10.1504/IJWBC.2009.021559


[37] F.

Liarokapis, I.

Greatbatch, D.

Mountain, A.

Gunesh, V.

Brujic
-
Okretic, and
J.

Raper, "Mobile augmented reality techniques for geovisualisation," in
Ninth
International Conference on Information Visualisation (IV'05)
.



IEEE, 2005, pp. 745
-
751. [Online]. Available: http://dx.doi.org/10.1109/IV.2005.79


[38] J. Sung
-
Hyun, a. Hudson
-
Smith GIS and Augmented Reality in 2015, The AGI
Foresight Study
-

The UK Geospatial Industry in 2015: An Expert Paper, 2010, AGI,
available
at
http://www.agi.org.uk/storage/foresight/data
-
technology/GIS%20and%20Augmented%20Reality%20in%202015.pdf

[accessed
25
th

May 2010]



[39] Stephen

Evans
, Andrew
Hudson
-
Smith

et Michael
Batty
, «

3
-
D GIS : Virtual London
and beyond

»,
Cybergeo
, Sélection des meilleurs articles de SAGEO 2005, article 359,
mis en ligne le 27 octobre 2006, modifié le 04 juillet 2007.
URL

:

http://cybergeo.revues.org/inde
x2871.html. Consulté le 31 mars 2010.


[40] C.

Alexander, S.

Smith
-
Voysey, C.

Jarvis, and K.

Tansey, "Integrating building
footprints and lidar elevation data to classify roof structures and visualise buildings,"
Computers, Environment and Urban Systems
, v
ol.

33, no.

4, pp. 285
-
292, July 2009.
[Online]. Available: http://dx.doi.org/10.1016/j.compenvurbsys.2009.01.009


[41] P.

J. Bartie and W.

A. Mackaness, "Development of a speech
-
based augmented
reality system to support exploration of cityscape,"
Transact
ions in GIS
, vol.

10, no.

1,
pp. 63
-
86, January 2006. [Online]. Available: http://dx.doi.org/10.1111/j.1467
-
9671.2006.00244.x


[42] Sandford R, Futurelab podcast transcript Episode 2: Augmented Reality

Available at:
http://media.futurelab.org.uk/podcasts/becta_talks/transcripts/augmented_reality.
pdf
, [accessed 21 May 2010]


[43] Spellbinder: a medium for social interaction in branded city space

Mark Wrigh
t, James Stewart, Richard Coyne, Penny Travlou, Robin Williams and Henrik
Ekeus

International Conference on Computer Graphics and Interactive Techniques ACM
SIGGRAPH 2007 posters, Session Interaction, Article No. 147, San Diego, California


[44] The Virtu
al Reality Modeling Language Specification version 2.0, available at
http://graphcomp.com/info/specs/sgi/vrml/spec/

,
[accessed 21st June 2010],
1996


[45] X3D International Specification Stand
ards, available at
http://www.web3d.org/x3d/specifications/x3d_specification.html
,
,
[accessed 21st
June 2010], Web 3D Consortium.


[46] Traxler, John

(2009)
Students and mobile

devices: choosing which dream.

In: ALT
-
C 2009 "In dreams begins responsibility"
-

choice, evidence and change, 8
-

10
September 2009, Manchester. Available at:
http://repository.alt.ac.uk/643/

[accessed
25
t
h

May 2010]


[47] Kray C, Rohs M, Hook J, Kratz S

Group Coordination and Negotiation through Spatial Proximity Regions around Mobile

4
8

Devices on Augmented Tabletops

3rd IEEE Workshop on Tabletops and Interactive Surfaces (
IEEE Tabletop 2008
),
Amsterdam, the Netherlands, October 1
-
3, 2008


[48] Kray C, Galani, A, Rohs M

Facilitating Opportunistic Interaction with Ambient Displays

Workshop on Designing and Evaluating Mobile Phone
-
Based Interaction with Public
Displ
ays

at
CHI 2008
, Florence, Italy, April 5, 2008.


[49] Kray C, Rohs M

Swiss Army Knife meets Camera Phone: Tool Selection and Interaction using Visual
Markers
, Proceedings of Mobile Interaction with the Real World (
MIRW
), Singapore,
September 9, 2007


[50] M.

Wright, H.

Ekeus, R.

Coyne, J.

Stewart, P.

Travlou, and R.

Williams,
"Augmented duality: overlapping a metaverse with the real world," in
ACE '08:
Proceedi
ngs of the 2008 International Conference on Advances in Computer
Entertainment Technology
.


New York, NY, USA: ACM, 2008, pp. 263
-
266. [Online].
Available: http://dx.doi.org/10.1145/1501750.1501812


[51] Sharples, M., Arnedillo Sánchez I., Milrad M., Vav
oula G. Mobile Learning: Small
Devices, Big Issues in Technology Enhanced Learning: Principles and Products (in
press) http://telearn.noe
-
kaleidoscope.org/open
-
archive/browse?browse=collection/30/publication&index=0&filter=all&param=30


[52] M. Musolesi, E
.Miluzzo, N. D. Lane, S. B. Eisenman, and A. T. Campbell. The
Second Life of a Sensor: Integrating Real
-
world Experience in Virtual Worlds using
Mobile Phones. In Proceedings of HotEmNets 2008, Charlottesville, Virginia, USA, June
2008. ACM Press.


[53] Op
enSimulator homepage,
http://opensimulator.org/wiki/Main_Page

[accessed
21st June 2010


[54] C. Sexton, Keynote Lecture, Eduserv Symposium 2010: The Mobile University, 13th
May 2010 available at
http://www.switchnewmedia.com/esym10/
, accessed 19
th

May
2010.


[55] University of Edinburgh, Information Services Survey Results: Mobile Services
2010, available at

http://www.projects.ed.ac.uk/areas/itservices/integrated/ITS045/Other_document
s/MobileSurvey2010.shtml
, [accessed 19
th

May 2010]


[56] OMbiel MCampus ,
http://www.ombiel.com/about.html

[accessed 19th May 2010]


[57] JISC Erewhon Project,
http://erewhon.oucs.ox.ac.uk/
, [accessed 19th May 2010]


[58] Molly Open Source Mobile Portal, http:
//mollyproject.org/ [accessed 19th May
2010]


[59] Mobile Campus Assistant Final Progress Report available at
http://mobilecampus.ilrt.bris.ac.uk/final
-
progress
-
report/

[accessed 1
8th June]


[60] Poole, P. Ellery, I. Wheal, A. IBorrow Final Project Report


4
9

http://www.canterbury.ac.uk/projects/iborrow/documents/iBorrow
-
Final
-
Project
-
Report.pdf
, Canterbury Christ Church University, march 2010