Controlling tiling

The static layers are represented by a grid of images of a fixed size. These fixed-size images are referred to as tiles. Dynamic layers are represented by a single image with a transparent background overlaying the view.

A static layer is not supposed to change during the application lifecycle and so can be generated once only. Typically, a static layer is the background of the view, such as a background map.

A dynamic layer contains objects, such as symbols, that can move and change their graphic representation.

NOTE 	Dynamic layers must be placed on top of a static layer. Otherwise, they are not displayed.

The advantages of a tiled view are continuous panning and the capability of caching tiles. On the client side this avoids a round-trip to the server and gives a better response time. On the server side it allows the server to receive the request, retrieve the image, and respond with the image without having to generate it. Not having to generate the image for the response is especially advantageous in complex applications.

Tile size

The size of the tile determines the number of tiles needed to cover the view.

The tile size must be carefully chosen because it can have a considerable and potentially critical impact on performance. The larger the number of tiles needed because of their size relative to the size of the view to be covered, the more simultaneous requests to be addressed to the image servlet. There also be more graphic objects to manage on the client side.

If a server-side caching mechanism is implemented, such as pregenerated tiles, the size must be consistent with the configuration of the server-side caching mechanism. See IlvTileManager for more details about server-side caching mechanisms.

Cache mechanisms

Since tiles in static layers are not subject to change, they can be cached on the client side to be reused directly without the need for a server round-trip.

You can consider several possible caching strategies on the server side:

No caching: the server generates the images each time they are requested.

Dynamic caching: the server can cache every generated tile, for example in the file system. This strategy allows you to have a quicker response for popular tiles and to limit the size of the cache.

Pregeneration: a partial or complete set of tiles for specific zoom levels can be pregenerated and returned directly by the server without need of dynamic generation.

To manage the cache efficiently on the client and the server, the zoom levels must be fixed. If there is a free choice of what zoom level to apply, the probability of the client retrieving a cached tile is severely limited.

See Specifying fixed zoom levels on the client side for how to specify the zoom levels.

Developing client-side tiling

The API of the IlvTileView class is very similar to IlvView. To use the tiled view, import IlvTiledView.js instead of IlvView.js.

To instantiate an IlvTiledView object, proceed as with IlvView, but the class takes an additional argument that defines the tile size as shown in the following XML example.

<html>

<head>

</head>

function init() {

view.init()

return false

}

function handleResize() {

if (document.layers)

window.location.reload()

}

</script>

<body onload="init()" onunload="IlvObject.callDispose()"

onresize="handleResize()" bgcolor="#ffffff">

//position of the main view

var y = 40

var x = 40

var h = 270

var w = 440

//tile size

var t = 256

//Main view

var view = new IlvView(x,y,w,h,t)

view.setRequestURL('/xmlgrapher/demo.xmlgrapher.servlet.XmlGrapherServlet')

view.toHTML()

</script>

</body>

</html>

Developing server-side tiling

The tile manager stores and retrieves static and dynamic layers. See In Server-side caching and the tile manager for a description of the tile manager and Tiling for what is meant by static and dynamic layers in the context of tiling.

The list of dynamic layers is computed by the following method of the IlvManagerServletSupport class:

public IlvManagerLayer[] getDynamicLayers(HttpServletRequest request,

IlvManagerView view)

The default implementation of this method classifies the layers according to the value returned by the getTripleBufferedLayerCount method. If the layer index is greater or equal to this value, the layer is dynamic. If not, it is a static layer. You can override this method to determine which are the dynamic layers in a different way.

Client-side caching

HTTP headers are sent with the tile image to control the caching of tiles on the client side.

There are two ways of specifying expiry data for tiles on the client side.

Override the following method of IlvManagerServletSupport:

public long getExpirationDate(HttpServletRequest request)

This method returns the expiry date in milliseconds of tile lifespan in the client-side cache.

Override the protected method:

void setImageResponseCachePolicy(HttpServletRequest request,

HttpServletResponse response);

This method sends the HTTP headers to the client, so that the server instructs the client how to cache the tiles.

See RFC 2616 on HTTP/1.1 for a full description of HTTP headers.

You need to take the following cases into account:

1. The normal image request: you should prevent caching in this case.

2. The tile image request, which is identified by the tile request parameter: this type of request can be cached on the client.

Server-side caching and the tile manager

Use IlvTileManager to manage caching on the server side.

Static or dynamic layers can be used in conjunction with tiled views on the client side.

Static layers can be cached or pregenerated on the server. Cached tiles are part of layers that are not expected to change within the application lifecycle, as, for example, in a background map. Cached tiles can be retrieved through a tile manager.

Dynamic layers are likely to change between requests to the server, such as labeling or network display.

The tile manager, an instance of IlvTileManager, stores and retrieves tiles on the server side. IlvManagerServlet can take advantage of such a tile manager if one is installed on the servlet.

When an image request is received by the servlet, if a tile that matches the current request is managed by the tile manager, it return this cached tile instead of generating a new image from IlvManagerView. If a tile is not yet managed by the tile manager, generate the image from IlvManagerView and ask the tile manager to manage it for future access.

When IlvManagerServletSupport responds to an image request, it uses the tile manager as follows:

if (useTileManager(request)) {

IlvTileManager tm = getTileManager(request);

if (tm != null) {

Object key = getKey(request);

BufferedImage image = tm.getImage(key);

if (image == null) {

image = doGenerateImageImpl( ... );

tm.putImage(key, image);

}

return image;

}

return doGenerateImageImpl( ... );

The tile manager is invoked by default if the request contains a parameter of the form tile=true. If the request contains such a parameter, useTileManager return true. You can override the useTileManager method to call the tile manager in other situations.

If a tile manager is installed, it be retrieved and a key object be constructed from the request to reference the tile. Then, an attempt is made to retrieve a tile from the tile manager. If the attempt is successful, the tile is returned as the response to the request.

If no tile is retrieved, an image be constructed through the normal image generation process. This image is passed to the tile manager for use in future retrievals.

The tile manager is not installed by default in an IlvManagerServletSupport object. You need to subclass it to install a tile manager.

The method to override is getTileManager. By default, this method returns null.

protected IlvTileManager getTileManager(HttpServletRequest request)

throws ServletException {

return null;

}

A default implementation of the tile manager is supplied. This implementation stores tiles on disk. You can use it to develop your own implementation of the getTileManager method.

protected IlvTileManager getTileManager(HttpServletRequest request)

throws ServletException {

ServletContext context = request.getSession().getServletContext();

   IlvTileManager tileManager =          (IlvTileManager)context.getAttribute("tileManagerKey");

if(tileManager == null) {

tileManager = new IlvFileTileManager(getBase(), getMaxCacheSize(),

getMinCacheSize());

context.setAttribute("tileManagerKey", tileManager);

}

return tileManager;

}

In this implementation you need to provide:

The base directory where the tiles are written.

The maximum size allowed for the cache.

The size to which the cache be reduced by removing files when the maximum size is reached.

When the maximum size is reached, the cache is considered to be full and files be removed to reduce the size of the cache to the level indicated.

The tile manager is stored and retrieved from the ServletContext, so that the same tile manager is used for the same application. You can use a different strategy for storing and retrieving the tile manager.

You can also customize the reading and writing of tiles and the name of the file that is generated for each tile. This default implementation of the tile manager constructs a file name of the form x_y_width_height.jpg, where x, y, width, and height are the manager coordinates of the image request passed as the bbox attribute of the request.

This file is stored in and retrieved from the base directory provided when the IlvFileTileManager is constructed. This customization can be performed through the IlvFileTileURLFactory, which is responsible for building a URL from the key that identifies the tile. The default key is a Rectangle2D.Double object, which is created from the bbox parameter of the request.