Because web-based applications are generally broken into multiple components, the way these components communicate becomes extremely important. It's quite likely that your web application will use off-the-shelf components or rely on existing components running on a remote server. In these cases, the protocols used to communicate between the various components is crucial to allowing these various components to work together.
In terms of geo-spatial web applications, a number of standard protocols have been developed to allow different components to communicate. For example, the Web Map Service (WMS) protocol provides a standard way for a web service to receive a map-generation request and return the map image back to the caller.
In this section, we will examine the major protocols relating to geo-spatial web applications. Many of the standard tools and building blocks will make use of these protocols, so it is worthwhile becoming at least passingly familiar with them.
The WMS protocol defines the interface to a web service that creates map images upon request:
At a minimum, the Web Map Service needs to implement the following two HTTP requests:
GetCapabilitiesThis request returns information about the Web Map Service itself. This request returns an XML document that describes the web service, including:
- Which operations are supported by the web service
- The maximum width and height of the generated map, in pixels
- The maximum number of layers that can be included in the map
- A list of the available map layers
- A list of the various visual styles that can be applied to the map's features
- A latitude/longitude bounding box defining the area of the Earth the Web Map Service can generate maps for
- Which Coordinate Reference System is used by the map's data.
- The range of scale factors at which the map can be generated
- A URL linking to the underlying map data
GetMapThis request generates and returns an actual map image based on the supplied parameters. The supplied parameters include:
- A comma-separated list of the layers to include in the map
- A comma-separated list of styles to apply to the map
- A CRS code indicating which Coordinate Reference System is used by the supplied bounding box parameters. For example, the code
CRS:84indicates that the coordinates are longitude and latitude values using the WGS 84 datum - The bounding box defining the area of the Earth to be covered by the map
- The width and height of the generated map image, in pixels
- The image format to use for the generated map
The
GetMaprequest will return the generated map as an image file of the requested format. For example, if the request parameters includedFORMAT=JPEG, the returned data would be a JPEG-format image.
The Web Map Service may also optionally implement the following request:
GetFeatureInfoReturns more detailed information about the feature or features at a given coordinate within a rendered map image. The parameters used by this request include:
- The map-generation parameters used to create a map image
- The pixel coordinate of a desired point in the rendered map image
Upon completion, this request returns information about the features at or near the given position in the rendered map image. The results are usually in XML format. Note that the exact information returned by a
GetFeatureInforequest is not specified by the WMS Specification.
For more information about the WMS protocol, you can find the complete specification for this protocol on the Open Geospatial Consortium's website:
Because the WMS protocol is a generic protocol for generating map images, it is not ideally suited to producing map tiles that can be easily cached. To get around this limitation, a set of recommendations were made to limit the way in which WMS operates, to make it more suitable for serving tiled images. This recommendation, known as WMS-C or the WMS Tiling Client Recommendation, ensures that the generated map images consist of fixed-size tiles. It also suggests extensions to the WMS protocol to make it clear that the rendered map images are map tiles.
More details about the WMS-C protocol can be found at:
The WFS protocol defines a web service that allows other parts of a web application to query and manipulate geo-spatial features independently of how those features are stored:
A Web Feature Service represents geo-spatial features using Geography Markup Language (GML), which is an XML schema for storing and representing geographical information. GML is an international standard, allowing features to be represented and stored in a platform-agnostic way.
At a minimum, a Web Feature Service needs to support the following requests, which allow client systems to query the WFS and retrieve features:
GetCapabilitiesThis request returns information about the Web Feature Service itself. This request returns an XML document that describes the web service, including:
DescribeFeatureTypeThis request returns an XML document describing the structure of one or more types of features. This provides information about the attributes stored for each feature, as well as the way in which the feature itself is represented in the datastore.
GetFeatureThis request queries the WFS, returning features that match certain criteria. The caller can request which properties to retrieve and a maximum number of matching features to return, as well as both spatial and non-spatial query parameters.
The Web Feature Service may also allow client systems to add, update and delete features. This can be done in one of two ways: by allowing the client to lock one or more features before making a series of changes and then unlocking the features again, or simply by making the updates one at a time. The locking approach ensures that two processes don't both update the same feature at the same time, though not all Web Feature Services support locking.
The following requests support locking and non-locking changes to the datastore:
LockFeatureLock one or more features so that other processes cannot make any changes to those features.
GetFeatureWithLockRetrieve one or more features, and immediately lock the retrieved features.
TransactionThis request is used to add, update, and delete features. It also allows previously-locked features to be unlocked, allowing other processes to make changes to those features.
Finally, the Web Feature Service can optionally support external linking, where features (possibly stored in different Web Feature Services) can be linked together. This is done through supporting the retrieval of nested features within the GetFeature request, and the separate GetGmlObject request that returns a given feature referred to by an XLink ID.
Web Feature Services are intended to abstract the storage and retrieval away from other parts of a web application, allowing different datastores to be used, and to allow information stored in separate places (possibly on separate servers) to be seamlessly combined. Unfortunately, the WFS protocol is quite complicated, relying heavily on complex XML schemas, which makes accessing and using a Web Feature Service somewhat challenging. Despite this, the open and scalable nature of the WFS protocol does make it worthwhile. Depending on your requirements, you may wish to make use of this protocol in your applications—especially if you are trying to access or manipulate data stored externally.
More information about Web Feature Services, including a complete specification for the WFS protocol, can be found at:
The TMS protocol defines the interface to a web service that returns map tile images upon request. The TMS protocol is similar to WMS, except that it is simpler and more oriented towards the storage and retrieval of map tiles rather than arbitrarily-specified complete maps.
The TMS protocol uses RESTful (REpresentational State Transfer) principles, which means that the URL used to access the web service includes all of the information needed to complete a request. Unlike WMS, there is no need to create and submit complex XML documents to retrieve a map tile—all of the information is contained within the URL itself.
Within the TMS protocol, a Tile Map Service is a mechanism for providing access to rendered map images at a given set of scale factors and using a predetermined set of spatial reference systems.
A single TMS Server can host multiple Tile Map Services:
This is typically used to have different versions of a Tile Map Service available so that new versions of the Tile map Service can be implemented without breaking clients that depend on features in an older version.
Each Tile Map Service within a TMS Server is identified by a URL that is used to access that particular service. For example, if a TMS Server is running at http://tms.myserver.com, version 1.2 of the Tile Map Service running on that server would generally reside at the sub-URL http://tms.myserver.com/1.2/. Accessing the top-level URL (that is, http://tms.myserver.com) returns a list of all the Tile Map Services available on that server:
<?xml version="1.0" encoding="UTF-8"/> <Services> <TileMapService title="MyServer TMS" version="1.0" href="http://tms.myserver.com/1.0/"/> <TileMapService title="MyServer TMS" version="1.1" href="http://tms.myserver.com/1.1/"/> <TileMapService title="MyServer TMS" version="1.2" href="http://tms.myserver.com/1.2/"/> </Services>
Each Tile Map Service provides access to one or more Tile Maps:
A Tile Map is a complete map of all or part of the Earth, displaying particular sets of features or styled in a particular way. The examples given in the previous image of a worldwide base map, a contour map, and a land-use map show how different Tile Maps might contain different sorts of map data or cover different areas of the Earth's surface. Different Tile Maps may also be used to make maps available in different image formats, or to provide maps in different spatial reference systems.
If a client system accesses the URL for a particular Tile Service, the Tile Service would return more detailed information about that service, including a list of the Tile Maps available within that service:
<?xml version="1.0" encoding="UTF-8"/>
<TileMapService version="1.2" services="http://tms.myserver.com">
<Title>MyServer TMS</Title>
<Abstract>TMS Service for the myserver.com server</Abstract>
<TileMaps>
<TileMap title="World Base Map"
srs="EPSG:4326"
profile="none"
href="http://tms.myserver.com/1.2/baseMap"/>
<TileMap title="USA Contour Map"
srs="EPSG:4326"
profile="none"
href="http://tms.myserver.com/1.2/usaContours"/>
<TileMap title="Australian Land-Use Map"
srs="EPSG:4326"
profile="none"
href="http://tms.myserver.com/1.2/ausLandUse"/>
</TileMap>
</TileMaps>
</TileMapService>
Client systems accessing rendered maps via a TMS Server will generally want to be able to display that map at various resolutions. For example, a world base map might initially be displayed as a complete map of the world, and the user can zoom in to see a more detailed view of a desired area:
This zooming-in process is done through the use of appropriate scale factors. Each Tile Map consists of a number of Tile Sets, where each Tile Set depicts the map at a given scale factor. For example, the first image in the previous illustration was drawn at a scale factor of approximately 1:100,000,000, the second at a scale factor of 1:10,000,000, the third at a scale factor of 1:1,000,000, and the last at a scale factor of 1:100,000. Thus, there would be four Tile Sets within this Tile Map, one for each of the scale factors.
If a client system accesses the URL for a given Tile Map, the server will return information about that map, including a list of the available Tile Sets:
<?xml version="1.0" encoding="UTF-8">
<TileMap version="1.2"
tilemapservice="http://tms.myserver.com/1.2">
<Title>World Base Map</Title>
<Abstract>Base map of the entire world</Abstract>
<SRS>ESPG:4326</SRS>
<BoundingBox minx="-180" miny="-90" maxx="180" maxy="90"/v
<Origin x="-180" y="-90"/>
<TileFormat width="256"
height="256"
mime-type="image/png"
extension="png"/>
<TileSets profile="none">
<TileSet href="http://tms.myserver.com/1.2/basemap/0"
units-per-pixel="0.703125"
order="0"/>
<TileSet href="http://tms.myserver.com/1.2/basemap/1"
units-per-pixel="0.3515625"
order="1"/>
<TileSet href="http://tms.myserver.com/1.2/basemap/2"
units-per-pixel="0.17578125"
order="2"/>
<TileSet href="http://tms.myserver.com/1.2/basemap/3"
units-per-pixel="0.08789063"
order="3"/>
</TileSets>
</TileMap>
Notice how each Tile Set has its own unique URL. This URL will be used to retrieve the individual Tiles within the Tile Set. Each Tile is given an x and y coordinate value indicating its position within the overall map. For example, using the above Tile Map covering the entire world, the third Tile Set would consist of 32 tiles arranged as follows:
This arrangement of tiles is defined by the following information taken from the Tile Map and the selected Tile Set:
- The Tile Map uses the ESPG:4326 spatial reference system, which equates to longitude/latitude coordinates based on the WGS84 datum. This means that the map data is using latitude/longitude coordinate values, with longitude values increasing from left to right, and latitude values increasing from bottom to top.
- The map's bounds range from -180 to +180 in the x (longitude) direction, and from -90 to +90 in the y (latitude) direction.
- The map's origin is at (-180,-90)—that is, the bottom-left corner of the map.
- Each Tile in the Tile Map is 256 pixels wide and 256 pixels high.
- The third Tile Set has a
units-per-pixelvalue of 0.17578125.
Multiplying the units-per-pixel value by the tile's size, we can see that each tile covers 0.17578125 * 256 = 45 degrees of latitude and longitude. Since the map covers the entire Earth, this yields eight tiles across and four tiles high, with the origin in the bottom-left corner.
Once the client software has decided on a particular Tile Set to use, and has calculated the x and y coordinates for the desired tile, retrieving that tile's image is a simple matter of concatenating the Tile Set's URL, the x and y coordinates, and the image file suffix:
url = tileSetURL + "/" + x + "/" + y + "." + imgFormat
For example, to retrieve the tile at coordinate (3, 2) from the above Tile Set, you would use the following URL:
http://tms.myserver.com/1.2/basemap/2/3/2.png
Notice how this URL (and indeed, every URL used by the TMS protocol) looks as if it is simply retrieving a file from the server. Behind the scenes, the TMS Server may indeed be running a complex set of map-generation and map-caching code to generate these tiles on demand—but the entire TMS Server could just as easily be defined by a series of hardwired XML files and a number of directories containing pre-generated image files.
This notion of a Static Tile Map Server is a deliberate design feature of the TMS protocol. If you don't need to generate too many map tiles, or if you have a particularly large hard disk, you could easily pre-generate all the tile images and create a static TMS server by creating a few XML files and serving the whole thing behind a standard web server such as Apache.
While you might not implement your own dynamic TMS Server from scratch, you may well wish to make use of TMS servers in your own web applications, either by creating a Static Tile Map Server, or by using an existing software library that implements the TMS protocol such as the open-source TileCache server. TileCache will be discussed in the next section of this chapter.
The full specification for the TMS protocol can be found at: