Tech:Data Transport

From Cyclopath

The Cyclopath client keeps some offscreen data resident for two reasons: in order to provide the illusion of continuity when scrolling, and to keep state (e.g., unsaved edits). This section describes how features are fetched and discarded; such fetch cycles occur on pan, zoom, resize, and other circumstances.

The figure at right illustrates the four regions which govern the fetching and discarding activity. Region A, the region of the map document currently visible by the user, does not actually have any bearing on this behavior, but it is included because the other three regions are derived from it.

Contents 1 Tiled layers 1.1 Calculating Tile Boundaries 2 Non-Tiled Layers 3 Filtering by Version

[edit] Tiled layers

FIXME: this section is obsolete and must be rewritten.

While the Pyserver is able to return data matching any rectangular region, the client fetches well-defined tiles in order to facilitate caching and to prevent the need for redundant re-fetching on scrolling.

Layers which are either (a) raster layers or (b) contain only point features are fetched using tiling. Other layers – i.e., those which contain non-point data – are not tiled. (Deciding whether or not to include features which extend outside a tile’s boundary in the fetch result is inconsistent between and perhaps within clients, so caching is not helpful anyway.) In the future, other layers which are being fetched in a read-only mode may also be tiled by trimming off the parts of features which extend outside the tile.

The client fetches square tiles having boundaries which are consistent across different instances of the client. This is to facilitate caching of tiles from layers which are non-dynamic. The user’s own caching system may do this, but the main benefit is that this enables use of a web proxy cache on the server side. A critical reason for using a proxy server is generation of resized underlay images, which can be expensive. A proxy server eliminates the need to generate these ahead of time.

A tiled fetch cycle is as follows. All tiles wholly within Region D are discarded and requests for all tiles which intersect Region B are initiated. When those requests are asynchronously fulfilled, the tiles are inserted into the document.

[edit] Calculating Tile Boundaries

FIXME

[edit] Non-Tiled Layers

The client keeps a bounding box R which delineates the features which are currently resident: all layer features which intersect R are resident. Non-tiled fetch sequences occur at the same time as their tiled brethren and consist of the following:

1. R is shrunk to exclude the portion of R which now falls within Region D.
2. Let R' be the minimal bbox containing both R and Region B. A (single) request for features which intersect R' (the include rectangle) but which do not intersect R (the exclude rectangle) is initiated.
3. All features which do not intersect R are discarded. (This cannot be deferred to future fetches because the resident rect R must at all times reflect the actual bounds of in-memory features.)
4. R is set to R'.
5. When this request is (asynchronously) fulfilled, the features are integrated into the document. It is possible for this result set to include features which duplicate dirty features (which are still resident); these are discarded.

[edit] Filtering by Version

Each version of a versioned object remembers two revisions: the valid-starting revision is the first revision when that version is valid, and the valid-before revision is the first revision when that version is invalid (i.e., the version is valid until but not including the valid-before revision).

1. The current version meets conditions:
   • valid-before =
2. The version current in revision i meets conditions:
   • validstarting ≤ i
   • validbefore > i

(Be aware that the current or historical version may be deleted.)

Comparing two versions is tricker. Suppose that the user wishes to compare revisions i and j, i < j. This requires three sets of items: new -- those items valid in j but not i, old -- items valid in ibut not j, and static -- items valid in both i and j. Condition 2 above can be used to build these queries.

The pyserver is capable of filtering results as specified above (see wfs_mod_python for argument syntax), and the flashclient is responsible for the actual diffing and visualization.