Web GIS in practice V: 3-D interactive and real-time mapping in Second Life.

This paper describes technologies from Daden Limited for geographically mapping and accessing live news stories/feeds, as well as other real-time, real-world data feeds (e.g., Google Earth KML feeds and GeoRSS feeds) in the 3-D virtual world of Second Life, by plotting and updating the corresponding Earth location points on a globe or some other suitable form (in-world), and further linking those points to relevant information and resources. This approach enables users to visualise, interact with, and even walk or fly through, the plotted data in 3-D. Users can also do the reverse: put pins on a map in the virtual world, and then view the data points on the Web in Google Maps or Google Earth. The technologies presented thus serve as a bridge between mirror worlds like Google Earth and virtual worlds like Second Life. We explore the geo-data display potential of virtual worlds and their likely convergence with mirror worlds in the context of the future 3-D Internet or Metaverse, and reflect on the potential of such technologies and their future possibilities, e.g. their use to develop emergency/public health virtual situation rooms to effectively manage emergencies and disasters in real time. The paper also covers some of the issues associated with these technologies, namely user interface accessibility and individual privacy.

Background

When Google Earth and Google Maps first appeared many people marvelled at the ability to zoom in on almost any part of the planet and see objects at little more than 1 m resolution. However, the imagery is static, and relatively out of date. But what made Google Earth come alive was the ability to create so-called 'network links'–displays of data, often captured in real-time–which could be overlaid on the basic Google Earth mapping [1].

This capability is now (in November 2007) two years old. Whilst so-called 'mirror worlds' [2], such as Google Earth, have developed little further, the major innovation of the last 18 months has been the rise in popularity of 'virtual worlds', such as Second Life [3,4] (the US Department of Defense has been using virtual worlds since the 1990s). Here again it is the interfacing of the virtual space to real world data which can start to open up new possibilities in the ways that we view and analyse geographic data.

This paper describes some of the tools developed by Daden Limited [5] to explore the geo-data display potential of virtual and mirror worlds, and reflects on the potential of such technologies, their future possibilities, and some of the associated issues like user interface accessibility and individual privacy. Before looking at the tools in detail, it is worth putting these new technologies into context.

The MetaVerse Roadmap and Metaverse 1.0 Consortium

A group of US companies and institutions active in this area recently published a Metaverse Roadmap [6]. This proposed that there were four emerging technologies that make up the so-called Metaverse–a digital domain equivalent to the atom based domain of our physical lives. These technologies are:

• Mirror worlds–digital representations of our own atom based world, such as Google Earth, Google Maps, and Microsoft Virtual Earth 3D;

• Virtual worlds–digital representations of any space, imagined or real, such as Second Life;

• Lifelogging–the digital capture of information about people and objects in the real (or digital) worlds; and

• Augmented reality–sensory overlays of digital information on the real (or even virtual) world, e.g., using head-up displays (HUDs).

Whilst there have been prototypes of systems in all four of these areas over the last 20 years or so (remember the Virtuality headsets of the 1980s), it is only in the last couple of years that these technologies have reached a maturity where they can be considered for serious use. Even then their adoption is likely to follow the order above, and useful, widespread deployment of some may yet still be a decade or so away.

The Metaverse 1.0 Consortium is a related group that includes over 40 participants of large and small/medium enterprises, as well as several research institutes and universities from eight participating countries [7]. Among the participants are IBM [8], Philips, Forthnet, Alcatel-Lucent, Telefonica I&D, Siemens IT, Barco, Geosim Systems Ltd., Technical University Eindhoven, Utrecht University, Technical University of Twente, Fraunhofer Rostock, Nazuka and Bertelsmann.

Metaverse 1.0 will provide a standardised global framework enabling the interoperability between various virtual and mirror worlds (virtual-virtual and virtual-mirror worlds interoperability) [9], and between them and the real world (sensors, actuators, vision and rendering, social and welfare systems, banking, insurance, travel, real estate and many others, enabling the realisation of 'mixed (real + virtual/mirror) reality' applications). The framework will be mainly driven by a set of selected application domains, including training, learning and simulation, eInclusion, and support for elderly, disabled and minorities, among other domains.

Within this paper we will primarily focus on mirror worlds and virtual worlds.

Using mirror worlds and virtual worlds to display geographic datasets

RSS and Google Earth

When we first encountered Google Earth in the summer of 2005 our attention was drawn to the network link facility. This lets you create a Keyhole Markup Language–KML [10] file (the eXtensible Markup Language–XML based standard used by Google Earth – Figure 1), place it on the Internet, and then have Google Earth users link their Google Earth browsers to it to display the information on their viewers [1]. At that time the majority of network link layers were static, and probably hand-crafted, KML files. However, there was some early work being done to capture live data (e.g., buses in California [11], or 911 calls in Seattle [12]) and to generate bespoke KML files automatically from them.

Figure 1

A simple KML file for Google Earth.

We were interested in whether one could use more generic data sources than these. The most obvious choice was the RSS feed [13]. RSS is most commonly taken as standing for Really Simple Syndication. It is an XML based standard that can be automatically generated by many modern Content Management Systems (Figure 2) and lets Web sites (or other data owners) generate a list of updates to their Web site (or other data). Users can then subscribe to this feed by entering its URL (Uniform Resource Locator) into their own RSS reader or Web browser, and be alerted to any new content. In fact it is RSS that lies at the heart of podcasting.

Figure 2

An example RSS feed.

The problem with using RSS feeds with Google Earth is that most such feeds do not contain geographically coded information. A case in point would be something like the BBC's World News RSS feed. To successfully plot such a feed onto Google Earth required us to develop a three stage process:

• Capture the feed;

• Parse it for geographic information, and geocode it; and

• Convert the data to KML.

Feed capture

Since RSS feeds are designed for public consumption by Web browsers they can be captured very simply and efficiently by a software programme that can make HTTP (Hypertext Transfer Protocol) requests out over the Internet. We do all our work in Perl [14] (seeing as most of our work is text rather than numbers or objects based), and Perl offers a library called LWP [15] to make this capture easy. The captured feed is just presented to the rest of the programme as a very long text string. Since we are dealing with pure text the capture time is often under a second–significantly less time than it takes a Web page to load.

Parsing and geocoding

This is the real challenge. From the simple text information in the feed we need to try and identify the geographic location of the item. For our work so far we have developed our own geocoder. This is a database of every country in the world, every major city, and every major airport, and the software searches the title (and optionally description) of the item for a place name it recognises. It then assigns the relevant geographic position for the item (cf. Metacarta's GeoParsing [16]). If a location is not found then the item is removed from the stream. We have also developed more detailed gazetteers for specific geographies (e.g., to village level in the UK), and it is possible to develop other bespoke gazetteers for specific clients and feeds. If data are already postcoded, then we can use postcode look-up services (such as Postcode Anywhere [17]) to convert from postcode to lat/long.

There are already some standards for geocoding RSS and similar data, such as ICBM [18] and GeoRSS [19]. Our application, which we call NewsGlobe [20], can identify when these formats are being used, so obviating the need for it to do its own geocoding.

Converting the data to KML

The end result of the geocoding process is a 2-D array containing a record for each item, and fields for each of the required fields from the original data. NewsGlobe steps through this array and builds up the KML file (Figure 3).

Figure 3

Automatically generated KML file from BBC News RSS feed.

NewsGlobe in operation

NewsGlobe, being a web service, is accessed through a REST (Representational State Transfer) model interface (Figure 4). Usually the resulting URL is wrapped within what is called a 'network link' in Google Earth, and this also offers the option to have the feed automatically refreshed on a timed basis (Figure 5).

Figure 4

Accessing the NewsGlobe web service through a REST model interface.

Figure 5

'Network link' file.

When the feed is activated, Google Earth calls the NewsGlobe web service with the URL and parameters. NewsGlobe then makes its own HTTP GET request to the target feed URL, receives the RSS file, parses it as above, builds the KML file, and returns this file to Google Earth, which displays it. Unless otherwise specified, simple Google Earth markers are used. Each marker is assigned a label based on the