Hack 95. Model Interactive Spaces

Make a Multi User Dungeon out of the real world.

Once upon a time, there was a globe in a "room" in a MUD, now lost in the misty dawn of the Internet. This globe contained a gazetteer, and as you spun the globe and peered into it, you could examine the detail of the real world. MUDs, Multi User Dimensions (or Dungeons), are built out of complexes of linked rooms and spaces, described with text and navigable by compass directions. In some MUDs, players can build their own quarters, extend the common world, and script objects within the game world, which have interesting behaviors.

The map is the key to the MUD, and popular ones have satellite web sites featuring maps created by players. MUD maps are more cartogrammatic than cartographic, conveying some features of space diagramatically, that is, approximately but not "spatially accurate" in a literal sense.

Figure 9-5 shows a classic MUD map, from an online world based on the Discworld novel series. A beautiful collection of these MUD maps has been compiled at http://maps.discworld.nu/.

Figure 9-5. Map of a small portion of the Discworld MUD (http://maps.discworld.nu/maps/aam.gif)

In a MUD, each room or open space is a node, linked by lines that represent the connections between nodes. We can give each node in this space metadata properties that affect how it can be used in the online world: who created the room, who is allowed to alter it, what objects it contains, which rooms or streets or other kinds of space you can reach from it. In theory, the kinds of properties we can give each node are unlimited, so why not also tag each space with GPS coordinates and make models of parallel virtual worlds that mirror our own?

We can use geodata on the Web to build a local "world as a MUD," to build simple interactive models that correspond to real spatial coordinates. With RSS feeds and other web content that can be positioned or geo-annotated, we can bring a lot of the "real" virtual world into the "imaginary" one. While lacking the visual impact of Augmented Reality Quake, text-based MUD-style environments provide an interesting way to traverse and make sense of real-world spatial data.

To build a model of the world, we need a simple framework of common terms of reference, a taxonomy or "ontology" of physical spaces that world-builders can share. Many different spatial ontologies exist, from the heavily complex and descriptive, to the domain-specific. One interesting challenge over the next few years of GIS development will be to provide "translation services" between different ontologiesnot only translating from one language to another and trying to encapsulate the subtly different usage patterns between, say English factory and French usine, but also to align different spatial ontologies where their contents represent similar but quite different things: a French canton, an English borough, a U.S. county.

9.4.1. Naming Spaces

The RDF model, shorthand for the unevocative Resource Description Framework, is an ideal candidate for storing interactive models of space. Like the route-oriented or connection-oriented model of space, it represents a graph of nodes with lines or arcs connecting them. RDF's companion standard, OWLthe Web Ontology Languageallows you to describe a taxonomy and publish it on the Web for others to use.

In the RDF model, as shown in Figure 9-6, each node and arc is labeled with an HTTP URL, just like an ordinary web address, except there doesn't have to be anything on the other end of the address: it just has to be unique and always refer to the same thing.

Figure 9-6. A simple RDF graph describing a physical space

Spacenamespace is an evolving spatial ontology, initially based on the classifications extracted from GEONet data [Hack #84] . It was written as part of a spatial annotation project, mudlondon; the ontology was expanded by some of the MUD users:

 a Building
 


 a Public Building
 


 a kind of Public Building intended for recreational purposes, 
like a cinema or club.
 

This formidable-looking bit of RDF says, "A Building is a kind of Hypsographic Feature." Hypsographic is a top-level classification from GEONet and just means something that's found on land. It goes on: "A Public Building is a kind of Building, and a Recreational Venue is a kind of Public Building." Each unique kind of space in a MUD can be labeled with one or more URLs, helping to indicate to people or bots the kind of things that can happen there. There is a growing selection of spatial ontologies on the Web, a short selection of which is available at http://space.frot.org/ontology.html.

9.4.2. Making Models Without Maps

mudlondon is a London model, built collaboratively by people who used it from different sources of geo-encoded data on the Web. A geocoded model of London's subway system, the Tube, was scraped from a web site. Many sites of interest were imported from the Open Guide to London; see [Hack #97] for details on how to simply export and reuse the geodata in any Open Guide.

mudlondon has an Instant Message interface, using the Jabber protocol (see http://jabber.org) to connect to different IM systems like AOL Instant Messenger. To explore it, a person just talks to it; wandering around it is like exploring a text adventure game: "You are on Charing Cross Road. You see a Tube Station. You can walk to: Shaftesbury Avenue or Trafalgar Square."

The rules for wandering around mudlondon are simple. To build a new space, or connect to an old one, the user types "connect Placename." If a place named Placename is found in the model, it's connected from the user's current location; if not, it is created, and the user is asked "What type of place is this?" (e.g., Building, Park). The bot takes a decent stab at fitting the new type into the spatial ontology and puts new types of places into a pool for later examination by its human friends.

mudlondon was written partly as an answer to the "collaborative mapping" problem; with no free sources of geo-encoded data, how can we build maps for ourselves? How can we share our mental models of the world in a way that is useful and can be built upon by others? Publishing RSS feeds of spatial data is a simple way to promote reuse.

9.4.3. Making Models with Maps

In the U.S., no such problem exists; geodata is available with staggering density from the Geological Survey, the Census Bureau, and other government agencies. By federal law, all data created by the government must be free of copyright and made available for no more than the actual cost of redistribution. Most of the public agencies have interpreted the "cost of redistribution" for web-based data to be "zero," pleasantly ignoring details of server maintenance and bandwidth costs.

To "bootstrap" an interactive RDF model of San Francisco, it was possible to use the TIGER/Line data set to extract a listing of all the streets in San Francisco and calculate the points at which they intersect with other streets. The Geo::TigerLine Perl module available on CPAN provides a detailed, low-level interface to the TIGER database. The code to extract an RDF model from TIGER, along with other spatial RDF goodies, is online at http://space.frot.org/metasf/.

So now we have the basis of a spatially accurate interactive environment. What use is it? mudlondon was written as an evocative prototype, to demonstrate the power of sharing geospatial data in RDF and the simplicity of tying together distributed sources of data into microlocal, spatially referenced content. Mostly, though, it was a game-like environment; build and explore, augment each other's mental maps, slowly create our own free common map.

In our interactive RDF model of San Francisco, metasf, we start out with an "authoritative" mapthat contained within the TIGER/Line model of San Francisco. From TIGER we can get a (mostly) complete list of all the streets in San Francisco (or any other U.S. city) and for each segment of a street, the coordinates where it begins and ends. If two different street segments both have an endpoint at the same latitude and longitude, we can infer that they intersect there.

So the more refined "world as a MUD" model treats each line connecting nodesan exit, an intersectionas if it were a node in itself. From Cortland Street, you can reach the intersection of Cortland and Mission, which is annotated with coordinates, as shown in Figure 9-7.

Figure 9-7. A refined RDF model of spatial connections

With a geo-annotated model of how streets connect, we can build a lot of interesting things. For example, the city's public transport providers publish route information on their web sites that can be scraped; bus stops tend to be identified by intersections, and subway stations come with addresses. The web services described in [Hack #80] make geocoding from addresses or street intersections in the United States trivial. One of the geocoder.us web service interfaces directly outputs RDF that can be imported into a spatial model.

A file containing the physical locations of wireless access points, either published by a community network group or by an organization like Intel's PlaceLab, allows you to do approximate location sensing. An RSS feed containing definite addresses for local eventsfundraisers in bars, yard sales, political meetupscan be geocoded and added to the model.

Route finding and public transport planning is harder. Sadly, TIGER/Line, being a product of the U.S. Census Bureau, which is more concerned with identifying places than finding places, doesn't contain any information about one-way streets, so you can't make route plans with itat least not safe ones.

9.4.4. Interactive Interfaces

Given a set of spatial graphs, either contained in a flat file or available via a web-service interface, a bot or agent can present a "conversational" view of the world model. Source code and advice for RDF bots that will allow you to wander around a spatial graph model are also available from http://space.frot.org/.