Alternative Access Project: Mobile Scoping Study Final Report

Version Date Comment Author(s)1.0 18th June 2010 Ben Butchart

Murray KingAddy PopeJoe VernonJames CroneJennie Fletcher

1.1 07th July Minor Changes Ben Butchart

Table of Contents

Executive Summary..................................................................................................3Our Goals................................................................................................................3The project..............................................................................................................3Conclusions and Key Recommendations......................................................4

Why do we need Digimap mobile?.......................................................................6Methods and Deliverables......................................................................................6

User engagement..................................................................................................6Technical evaluation............................................................................................6Digimap Mobile Prototype..................................................................................7

Technical requirements...........................................................................................7Technical approaches..............................................................................................8

Native Apps.............................................................................................................8Mobile Web..........................................................................................................8Hybrid Applications..........................................................................................9

Technical Evaluation..............................................................................................11Summary of technical evaluations.................................................................11

Testing OpenLayers with iPhone and Android.......................................11Integrating OpenLayers and HTML5 Canvas...........................................11HTML5 local database SQL database and OpenLayers.......................11HTML5 Canvas for mobile apps..................................................................12GeoLocation API first impressions............................................................123d objects for AR browsers..........................................................................12Building a native mapping app with RouteMe.........................................12Automatic geo tagging of photos...............................................................12Offline maps with HTML5 Cache.................................................................12A Phone Gap for a Map App.........................................................................12

Testing OpenLayers with iPhone and Android...........................................13Integrating OpenLayers and HTML5 Canvas...............................................14HTML5 local database SQL database and OpenLayers...........................17GeoLocation API first impressions................................................................183d objects for AR browsers..............................................................................20Building a native mapping app with Route-me...........................................22Automatic geo tagging of photos...................................................................24A Phone Gap for a Map App.............................................................................25HTML5 Cache.......................................................................................................26Technical Evaluation Key Recommendations.............................................26

User engagement....................................................................................................27Field study.............................................................................................................27Field Study User Engagement Recommendations....................................32Augmented Reality..............................................................................................33Augmented Reality User Engagement Recommendations......................37Virtual reality........................................................................................................37Virtual World User Engagement Recommendations.................................39Campus applications..........................................................................................39Campus Apps Engagement Recommendations.........................................41

Digimap Pilot............................................................................................................42

2

Security..................................................................................................................42Sustainability........................................................................................................44Deployment...........................................................................................................44Digimap Piliot Recommendations..................................................................45

Acknowledgements................................................................................................45References................................................................................................................46

Executive Summary

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. The summary below highlights the main findings and outcomes of the project and our recommendations for further enhancements.

Our Goals

Within Edina we needed to develop skills and 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. With so many technologies and platforms we also felt it was necessary to experiment with different technical approaches to mobile application development, including Mobile Web, Native and Hybrid paradigms, so that we could be confident in recommending the best approach for developing our services in the medium term. We decided at an early stage that it was important to keep an open mind on the best technical approach and to base our recommendations on evidence from experimenting with our own data, engineering capability and infrastructure rather than rely on the experience of others given the often emotional reaction people have to these technologies. As well as experimenting with technologies we also wanted to implement a fully functional mobile mapping application using popular Digimap datasets such as OS Mastermap and Landmark Historic maps to provide us with a prototype for rolling out a new service enhancement for students and staff in HE/FE.

The project

We organized the project into three separate strands to cover the goals 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 understand 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

3

facilitate their activities. Finally we designed and implemented a Digimap4Mobile pilot application.

The three main technical approaches we investigated were Mobile Web, Native and Hybrid development. In the Mobile Web paradigm, where applications are delivered through the mobile web browser (Safari, Opera , IE etc.) we focused on how mapping frameworks such as OpenLayers can integrate with emerging web standards such as the W3C Geolcoation API, HTML5 Canvas and Local Storage. To develop our skills in building native applications, where programming languages and tools are unique to a particular device or operating system, we worked on an iPhone mapping client written in ObejctiveC and Cocoa Touch. We also investigated some augmented reality frameworks and built a demonstration 3d Layar app for iPhone and Android. Finally to evaluate the hybrid approach (where a lightweight web browser is integrated into a skeleton native app), we looked at the PhoneGap framework and also built our own hybrid agent for the iPhone. To produce a pilot application we combined work we have previously done as part of the Walking Through Time project with the outputs from the technical evaluation to produce two prototype applications, one web based and the other a native iPhone application. We were able to evaluate each prototype against our requirements to arrive at recommendations for a future Digimap4mobile service.

Conclusions and Key Recommendations

The main conclusion from the technical evaluation is that the Mobile Web approach 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.

4

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 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 could 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 MScape ( 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 browsers 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 favourite 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 desktop 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 applications.

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 study 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

5

collaborations with educators and researchers across the academic community.

Why do we need Digimap mobile?

There are already many mapping products readily available on mobile devices so delivering yet another 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 level 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 interest 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 sector. 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 featured service.

Methods and Deliverables

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

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 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.

Technical evaluation

6

The purpose of the technical evaluation was to review frameworks and emerging standards 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 having to develop in depth expertise in all the different native operating systems and platforms, as this would not be easy to sustain. Framworks / 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 different platforms, browsers?

The main criteria for evaluation will be:

portability access to sensors ( geo-location, camera, compass, accelerometer) usability ( touchscreen controls / gestures ) sustainability speed offline access

Drawing on this work we summarize 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.

Digimap 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 mobile 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.

Technical requirements

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 connectivity may be limited. It was also anticipated that the application might assist data collection, for example, taking pictures of rocks

7

during a field study. The general functional and non functional requirements for such a client are shown below.

1. Must be able 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.

Technical approaches

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

Native Apps

A native application is developed using the programming language and APIs for a specific 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 applications 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.

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 desktop equivalents 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 security prevents developers from accessing the

8

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 and 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 and 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 mechanism to allow the user to make payments for the service or find other ways to monetize the application.

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 requires 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 familiarity 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 frameworks, 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 HybridLocation sensors

yes Yes (via HTML5 geo location API)

Yes (via HTML5 geo location API)

Touch gestures

yes Yes (partial) Yes (partial)

Sensors and gadgets

yes No Yes (usually via framework API)

Local storage yes Yes (via HTML5 Cache and Storage API)

Yes (via HTML5 Cache and Storage API)

9

Portable no Yes Yes (partial)

Requirement Native Mobile Web HybridLocation sensors

Touch gestures

Sensors and gadgets

Local storage

Portable

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 experience, but it a subjective decision and is meant to inform rather than dictate decision making,

10

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 certainly 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 platforms. Given the market is so competitive it may 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.

Technical Evaluation

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

11

we used the popular OpenLayers [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.

Summary of technical evaluations

Testing OpenLayers with iPhone and Android 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. Integrating OpenLayers and HTML5 Canvas

A web browser 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 showing difference in height as the user draws a path over the map.

HTML5 local database SQL database and OpenLayers

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 local storage interface. Once offline, these results can be retrieved and displayed as pins on an OpenLayers map.

HTML5 Canvas for mobile apps

In this evaluation we experiment with HTML5 canvas and show how it can be used for pixel based feature selection on mobile web browser.

GeoLocation API first impressions

Experiments 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 version scholarly portal to perform a journal search and reorders the search results based on the users proximity to the holding library.

3d objects for AR browsers

Experiments with the Layar augmented reality browser by showing a 3d image of a building internal structure superimposed over the camera view.

12

Building a native mapping app with RouteMe

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.

Automatic geo tagging of photos

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

Offline maps with HTML5 Cache

Experiment showing how HTML5 cache might be used to create an offline version of a mapped area. While mobile 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 available

A Phone Gap for a Map App

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.

Testing OpenLayers with iPhone and Android

In this evaluation 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 user 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 achieved 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 open 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 support touch screen events and is not optimized for much smaller smartphone screens. So to provide a version of Digimap on

13

mobile web browser we needed to investigate how the OpenLayers mapping API could be adapted to provide touch screen support and improved 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 experience ( 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 disappointed 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 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 wider 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

14

on iPhone Safari browser.

Blog stats for Open-Layers with iPhone. Total views by 18 May 2010 is 1,201. Average views per day 13; Average per month 350.

Integrating OpenLayers and HTML5 Canvas

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 experience 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 information 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 the 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. Advantage 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 products ( 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 space available on the mobile device rather than a full map legend

15

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 extracted from the image itself (which can be cached ) rather than from online access to a spatial database.

Vocie 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 constructed. 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 needed 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 technique.

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 demo: 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.

16

Elevation demo: A trail around Arthur’s Seat in Edinburgh is plotted using the elevation 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 image 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 processing 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 development 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 optimize the image processing techniques further and open soruce the Javascript code to wider AJAX development community.

Blog stats for Open-Layers with HTML5 canvas. Total views by 18 May 2010 is 765. Average views per day 14; Average per month 300.

HTML5 local database SQL database and OpenLayers

17

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 device 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 trying 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 using 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 string 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 educational 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 mapping. 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 retrievedWhile offline using HTML5 Cache

18

Blog usage stats for HTML5 locat SQl database. Total views by 21 May 2010 is 828. Average views per day 10; Average per month 250.

GeoLocation API first impressions

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 that 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.

19

Geolocation API demo screenshoton Android simulator showing warning that m2m.edina website is trying to access users location.

The application can now use location coordinatesreorder search results.

Our first use of this was in a simple library search application, where a skinned 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

20

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 would 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.

3d objects for AR browsers

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 the 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 content 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 minimum, 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.

21

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 for 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 point 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.

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

22

BuildingAnatomy application: Mock-up of 3d model superimposed on building facade

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.

Building a native mapping app with Route-me

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 Ordnance 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

23

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. Fortunatley, 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 optimized for the TMS addressing system would create acceptable quality of rendering.

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. There 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 system 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 establish 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

24

be released to the AppStore as part of the second phase of the “Walking Through Time” project.

Automatic geo tagging of photos

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 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 taken 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 mapping 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 information obtained from unlock service.

25

A Phone Gap for a Map App

Early in 2008 (prior to the project kickoff) 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 interface 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 platform 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 simulator 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 standardization 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 registered 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 development 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 point 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 3rd 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 appears to have escaped similar treatment, the risk remains that Apple may not allow applications to be published unless Apple approved coding libraries are used.

26

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.

HTML5 Cache

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 principle 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 organized 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 the 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 offline 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 attempting 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 OpenLayers), 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 on 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.

Technical Evaluation Key Recommendations

Edina should take a leading role in providing 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.

27

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 development skills internally.

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 their 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 no 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 recommendations 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.

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 view 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 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.

28

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 for 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]. Simialrly the Kingston group have experimented with 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 analysis 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 educational 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 Digimap 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 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 for now is to monitor activity of Kingston and others.

29

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 technologies 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 the 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 recognition 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.

30

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

However, the “Ambient Woods” study [33] where children 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 (location) 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 said, 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 “Ambient 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 gathering 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.

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 visualize 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 download is critical, as most of the time field trip cannot rely on web access, so the data

31

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 particularly 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 download 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 devices.

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 institutions 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 in 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 Cache manifest is created with 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 automatically 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 solution 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 habitats. 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 visited and observations recorded [36]. The augmented “map table”

32

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 this 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-packaged 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 services 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.

Field Study User Engagement Recommendations

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 Calvium to leverage existing user community.

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 mobile teaching resources and continue to reach wider community of mobile developers through geo mobile blog.

Augmented Reality

AR is an emerging technology that has great potential for creating innovative teaching and learning experiences by “enhancing 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 feasible as devices equipped with camera rendering, location and orientation sensors (GPS, compass, accelerometers) are much more affordable and ubiquitous

33

[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 educational 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 for 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.

1. Input data is merged and preprocessed. 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 improving 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 used 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]. Augmenting 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.

34

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

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 are 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 that 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), BGS 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 applications 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

35

Edina could play a role in bridging this gap by providing easy to use authoring and publishing 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 also 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 Mastermap 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 to 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 Mastermap with LiDaR and extruding building footprints to the correct height was seen as the most important contribution 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 “prosthetic” 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 to 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 another, 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 version of augmented reality has great potential for teaching and learning as it greatly facilitates pedagogic objectives such as student initiated learning

36

and peer instruction. A relevant application to maps is a student project supervised by Kray where devices 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 groups 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]

Augmented Reality User Engagement Recommendations

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.

Provide 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 such as Layar and Wikitude.

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 suggest included 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 school 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.

37

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 between 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 digital 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 ground (augmented reality). So working together the participants can share a space in different modes of reality, with each perspective enriching the other.

Wright at al [50] have coined the term “virtual duality” to describe the new form of interaction afforded 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 image 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 Sharples 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 detecting 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 processing 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 world to support teaching and learning activity. We recommend that JISC encourage such collaboration with

38

a view to exploring the potential for Edina to host virtual worlds as cloud based service.

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

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, exploiting the network built up during this study.

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 mobile 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 resource availability ( e.g. workstations, books). Sometimes these applications are adapted to support conference delegates which 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 otherwise open Campus application.

39

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 updates 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 images 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 available 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 in 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 using 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 any 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 development 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 based 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 benefits 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 HTML5 geolocation API [2] has made it much easier to implement location based services using

40

web browser technology. The difficulty is in obtaining the data on lectures, timetables, bus services etc and integrating all the data so that it can be linked and retrieved 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 and 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 sophisticated 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 developing 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 application 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 laptops 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 mobile 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 sophisticated 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 solutions for shibboleth protected services and guidance on geospatial standards and spatial ontology.

Campus Apps Engagement Recommendations

Edina should provide Ordnance Survey Open Data to make it as easy for Campus application developers to use the newly 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.

41

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.

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 some user feedback. The primary issues we addressed were security, deployment and sustainability.

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 should 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 problem 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 lasting 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 to Digimap4Mobile page where they can generate a link

42

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 screen 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 user 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 could 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 typical 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 to 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 mobile 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.

43

Sustainability

The purpose of developing a native iPhone as well as a browser based pilot is to properly understand the sustainability 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 number 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 given 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 for 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 strategy 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.

Deployment

Do we want the same stack of maps on mobile as we do on desktop clients? While 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 users 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.

44

Historic Digimap.is a good example of how mapping needs to be organised differently on mobile. In the desktop 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 highlighted. 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 and 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 greatly 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 mobile client will be required for different user scenarios or even for different locations.

Digimap Piliot 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.

Acknowledgements

Edina would like to thank the following people and groups who gave up some of their time 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 result.

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

45

David 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, University 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

References

[1] Hickson, I. (ed) “HTML5: A vocabulary and associated APIs for HTML and XHTML” available at: http://dev.w3.org/html5/spec/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] Route-me, “Open Source iPhone native slippy map”, http://code.google.com/p/route-me/ [accessed 21st June 2010]

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

46

[6] Layar Reality Browser, available at http://layar.com/ , [accessed 21st June 2010]

[7] Wikitude, Mobilizy Mobile Software, available at http://www.wikitude.org/ , [accessed 21st June 2010]

[8] “HML5 Draft Standard 15th June 2010 – the Canvas element”, available athttp://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 Map 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, available 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 Candidate 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 - S112http://www.informaworld.com/smpp/section?content=a915789282&fulltext=713240928

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

[21] Stimpson, I. Boys Toys, blog enrty available at: http://hypocentral.com/blog/2008/02/21/boys-toys/ [accessed, March 2010]

47

[22] Mscape, available at http://www.mscapers.com/,[accessed 21st June 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) GIS 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 environments with mobile GIS, proceedings of the GIS Reseach UK 18th Annual Conference, University College London, 2010

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

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

[28] MyTracks for Android project home page, available at http://code.google.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 new 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 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

48

[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 25th 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/index2871.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, vol. 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," Transactions 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 RealityAvailable 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 Wright, 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 Virtual 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 Standards, 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 25th May 2010]

[47] Kray C, Rohs M, Hook J, Kratz SGroup Coordination and Negotiation through Spatial Proximity Regions around Mobile Devices on Augmented Tabletops3rd IEEE Workshop on Tabletops and Interactive Surfaces (IEEE Tabletop 2008), Amsterdam, the Netherlands, October 1-3, 2008

[48] Kray C, Galani, A, Rohs MFacilitating Opportunistic Interaction with Ambient DisplaysWorkshop on Designing and Evaluating Mobile Phone-Based Interaction with Public Displays at CHI 2008, Florence, Italy, April 5, 2008.

49

[49] Kray C, Rohs MSwiss 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: Proceedings 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., Vavoula 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] OpenSimulator 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 19th 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_documents/MobileSurvey2010.shtml, [accessed 19th 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 18th June]

[60] Poole, P. Ellery, I. Wheal, A. IBorrow Final Project Reporthttp://www.canterbury.ac.uk/projects/iborrow/documents/iBorrow-Final-Project-Report.pdf, Canterbury Christ Church University, march 2010

50