A common saying among geospatial analysts is, A map is outdated as soon as it's created. This saying reflects the fact that the Earth and everything on it is constantly changing. For most of the history of geospatial analysis and through most of this book, geospatial products are relatively static. Raw datasets are typically updated from a few months to a few years. Data currency has traditionally not been the primary focus because of the time and expense needed to collect data.

Web mapping, wireless cellular modems, and low-cost GPS antennae have changed this focus. It is now logistically feasible and even quite affordable to monitor a rapidly changing object or system and broadcast these changes to millions of people online. This change is revolutionizing geospatial technology and taking it in new directions. The most direct evidence of this revolution is web mapping mash-ups using systems such as Google Maps or OpenLayers and web accessible data formats.

The term real-time data typically means near-real-time. Some tracking devices that capture real-time data may update as often as several times a second. However, the limitations of the infrastructure that broadcasts this data may constrain the output to every 10 seconds or longer. Weather radar is a perfect example. A Doppler weather radar sweeps continuously, but data is typically available online every five minutes. Given the contrast to traditional geospatial data updates, a refresh of a few minutes is real-time enough.

Web mash-ups often use real-time data. Web mash-ups are amazing and have changed the way many different industries operate. However, they are typically limited in that they usually just display preprocessed data on a map and provide developer's access to a JavaScript API. What if you want to process the data in some way? What if you want to filter it, change it, and then send it to another system? To use real-time data for geospatial analysis, you need to be able to access it as point data or a geo-referenced raster.

In this chapter, you'll learn to work with real-time geospatial data. We'll tackle the following high-level goals:

As with the examples in the previous chapters, the scripts are as simple as possible and designed to be read from start to finish without much mental looping. When functions are used, they are listed first, followed by the script variable declarations and finally, the main program execution.

Tracking vehicles

For our first real-time data source, we'll use the excellent NextBus API. Nextbus.com is a commercial service that tracks public transportation for municipalities, including buses, trolleys, and trains. People riding these transit lines can then track the arrival time of the NextBus. What's even better is that with the customer's permission, NextBus publishes tracking data through a Representational State Transfer or REST API. Using URL API calls, developers can request information about a vehicle and receive an XML document about its location. This API is a straightforward way to begin using real-time data.

If you go to Nextbus.com (http://www.nextbus.com/#!/mu-rht/1/portlouis/margstan_o), there is a web interface to the data as well, as shown in the following screenshot, of the city of Los Angeles, California's metro system:

The system lets you select several parameters to learn the current location and time prediction for the next stop. On the right-hand side of the screen is a link to a Google Maps mash-up showing the transit tracking data for the particular route, as shown in the following screenshot:

This is a very useful website but it gives us no control over how the data is displayed and used. Let's access the raw data directly using Python and the NextBus REST API to start working with real-time data.

For the examples in this chapter, we'll use the documented NextBus API that can be found at http://www.nextbus.com/xmlFeedDocs/NextBusXMLFeed.pdf.