In Chapter 8, Working with Spatial Data, we created a simple web application named DISTAL. This web application was built using CGI scripts to provide distance-based identification of towns and other features. DISTAL is a good example of a bare-bones approach to web application development, using nothing more than a web server, a database, and a collection of CGI scripts:

The advantage of this approach is that you don't need special tools or knowledge to write a web application in this way. The disadvantage is that you have to do all the low-level coding by hand. It's a tedious and slow way of building a web application, especially a complex one with lots of features.

To make the job of building web-based applications easier, you generally use existing tools that allow you to write your application at a higher level. For example, you might choose to implement a complex web application in the following way:

This stack of tools works together to implement your application: at the lowest level, you have a Data Tier that deals with the storage of data. In this case, the application uses MySQL for the database and SQLAlchemy as an object-relational mapper to provide an object-oriented interface to this database. The Application Tier contains the application's business logic as well as various libraries to simplify the job of building a stateful and complex web application. Finally, the Presentation Tier deals with the user interface, serving web pages to the users, mapping incoming URLs to the appropriate calls to your business logic, and using a sophisticated JavaScript library to build complex user interfaces within the user's web browser.

Note that the only parts of this application that a developer would create from scratch are the business logic, the URL mappings, and the database schema used by the object-relational mapper. The rest is all just a collection of off-the-shelf components.

Don't be too concerned about the details of this particular application's architecture—the main thing to realize is that there is a stack of tools all working together, where each tool makes use of the tools below it. Also, notice the complexity of this system: this application depends on a lot of different tools and libraries. Developing, deploying, and upgrading an application like this can be challenging because it has so many different parts.

To avoid the complexity of mixing and matching so many different parts, web developers have created various frameworks that combine tools to provide a complete web development system. Instead of having to select, install, and deploy ten different libraries, you can simply choose a complete framework that brings a known good set of libraries together and adds its own logic to provide a complete "batteries included" web-development experience. Most of these toolkits provide you with built-in logic to handle tasks such as:

There is a lot more to these frameworks, but the important thing to remember is that they aim to provide a "full stack" of features in order to allow developers to quickly implement the most common aspects of a web application with minimum fuss. They aim to provide rapid application development (RAD) for web-based systems.

There are a number of Python-based web application frameworks available, including three that support the building of geospatial applications: Django with its built-in GeoDjango extension, Pyramid with the Mapfish extension, and Turbogears with its tgext.geo extension. We will take a closer look at GeoDjango later in this chapter.

While it is easy to build a simple web-based interface in HTML, users are increasingly expecting web applications to compete with desktop applications in terms of their user interface. Selecting objects by clicking on them, drawing images with the mouse, and dragging and dropping are no longer actions restricted to desktop applications.

AJAX (short for asynchronous JavaScript and XML) is the technology typically used to build complex user interfaces in a web application. In particular, running JavaScript code on the user's web browser allows the application to dynamically respond to user actions and make the web page behave in ways that simply can't be achieved with static HTML pages.

While JavaScript is ubiquitous, it can also be tricky to program in. The various web browsers in which JavaScript code can run all have their own quirks and limitations, making it hard to write code that runs the same way on every browser. JavaScript code is also very low level, requiring detailed manipulation of the web page contents to achieve a given effect. For example, implementing a pop-up menu requires creating a <DIV> element that contains the menu, formatting it appropriately (typically using CSS), and making it initially invisible. When the user clicks on the appropriate part of the page, the pop-up menu should be shown by making the associated <div> element visible. You then need to respond to the user mousing over each item in the menu by visually highlighting that item and un-highlighting the previously highlighted item. Then, when the user clicks on an item, you have to hide the menu again before responding to the user's action.

All this detailed low-level coding can take weeks to get right—especially when dealing with multiple types of browsers and different browser versions. Since all you want to do in this case is create a pop-up menu that lets the user choose an action, it just isn't worth doing all this low-level coding yourself. Instead, you would typically make use of one of the available user interface libraries to do all the hard work for you.

These user interface libraries are written in JavaScript, and you typically add them to your web site by making the JavaScript library file(s) available for download and then adding a line like the following to your HTML page to import the JavaScript library:

<script type="text/javascript" src="library.js">

If you are writing your own web application from scratch, you would then make calls to the library to implement the user interface for your application. However, many of the web application frameworks that include a user interface library will write the necessary code for you, making even this step unnecessary.

There are many different user interface libraries that you can choose to include in your web applications. JQuery UI, AngularJS, and Bootstrap are three of the more popular examples. When writing geospatial web applications, it is easy to forget that geospatial web applications are, first and foremost, ordinary web applications that also happen to work with geospatial data. Much of a geospatial web application's functionality is rather mundane: providing a consistent look and feel, implementing menus or toolbars to navigate between pages, user signup, login and logout, entry of ordinary (non-geospatial) data, reporting, and so on. All of this functionality can be handled by one of these general-purpose user interface libraries, and you are free to either choose one or more libraries of your liking or make use of the UI library built into whatever web application framework you have chosen to use.

In addition to these general-purpose UI libraries, there are other libraries specifically designed for implementing geospatial web applications. We will explore one of these libraries, OpenLayers, later in this chapter.

Let's take a look at a simple but useful web service. The following CGI script, called greatCircleDistance.py, calculates and returns the great-circle distance between two coordinates on the earth's surface. Here is the full source code for this web service:

#!/usr/bin/python

import cgi
import pyproj

form = cgi.FieldStorage()

lat1 = float(form['lat1'].value)
long1 = float(form['long1'].value)
lat2 = float(form['lat2'].value)
long2 = float(form['long2'].value)

geod = pyproj.Geod(ellps="WGS84")
angle1,angle2,distance = geod.inv(long1, lat1, long2, lat2)

print('Content-Type: text/plain')
print()
print("{:.4f}".format(distance))

Because this is intended to be used by other systems rather than end users, the two coordinates are passed as query parameters, and the resulting distance (in meters) is returned as the body of the HTTP response. Because the returned value is a single number, there is no need to encode the results using XML or JSON; instead, the distance is returned as plain text.

Let's now look at a simple Python program that calls this web service:

import urllib

URL = "http://127.0.0.1:8000/cgi-bin/greatCircleDistance.py"

params = urllib.urlencode({'lat1'  : 53.478948, # Manchester.
                           'long1' : -2.246017,
                           'lat2'  : 53.411142, # Liverpool.
                           'long2' : -2.977638})

f = urllib.urlopen(URL, params)
response = f.read()
f.close()

print(response)

Running this program tells us the distance in meters between these two coordinates, which happen to be the locations of Manchester and Liverpool in England:

% python callWebService.py 
49194.4632

While this might not seem very exciting, web services are an extremely important part of web-based development. When developing your own web-based geospatial applications, you may well make use of existing web services, and potentially implement your own web services as part of your web application development.

We saw in Chapter 8, Working with Spatial Data, how Mapnik can be used to generate great-looking maps. Within the context of a web application, map rendering is usually performed by a web service that takes a request and returns the rendered map as an image file. For example, your application might include a map renderer at the relative URL /render that accepts the following query-string parameters:

This hypothetical /render web service would return the rendered map back to the caller as an image file. Once this has been set up, the web service would act as a black box providing map images upon request for other parts of your web application.

As an alternative to hosting and configuring your own map renderer, you can choose to use an openly available external renderer. For example, OpenStreetMap provides a freely available map renderer for OpenStreetMap data at http://staticmap.openstreetmap.de.

Because creating an image out of raw map data is a time- and processor-intensive operation, your entire web application can become overloaded if you get too many requests for map images at any one time. As we saw with the DISTAL application in Chapter 7, Using Python and Mapnik to Generate Maps there is a lot you can do to improve the speed of the map-generation process, but there are still limits on how many maps your application can render in a given time period.

Because the map data is generally quite static, you can make a huge improvement to your application's performance by caching the generated images. This is generally done by dividing the world up into tiles, rendering tile images as required, and then stitching the tiles together to produce the entire map:

Tile caches work in exactly the same way as any other cache:

Of course, tile caching will only work if the underlying map data doesn't change. As we saw when building the DISTAL application, you can't use a tile cache where the rendered image varies from one request to the next.

One interesting use of a tile cache is combining it with map overlays to improve performance even when the map data does change. Because the outlines of countries and other physical features on a map don't change, it is possible to use a map generator with a tile cache to generate the "base map", onto which changing features are then drawn as an overlay:

The final map could be produced using Mapnik by drawing the overlay onto the base map, which is accessed using a RasterDataSource and displayed using a RasterSymbolizer. If you have enough disk space, you could even pre-calculate all of the base map tiles and have them available for quick display. Using Mapnik in this manner is a fast and efficient way of combining changing and non-changing map data onto a single view—though there are other ways of overlaying data onto a map, for example, using OpenLayers to display multiple map layers at once.