Cartographic Objects for Zope
A Framework for mapping applications and cartographic object management systems
| Version: | 1.0 |
|---|---|
| Author: | Sean Gillies |
| Revision: | 1.1 |
| Date: | 2004-12-11 |
Introduction
Cartographic Objects for Zope, or ZCO, is the first application using the Python Cartographic Library. ZCO compares to ZMapServer as the PCL compares to MapServer's mapscript module; more powerful, more flexible, and better suited to developing production mapping services and cartographic workflows.
Design
The fundamental design principles of ZCO are:
- Take maximum advantage of the features of Zope 2, particularly acquisition and context.
- Keep things so simple that minimal rewrites are needed for Zope 3.
Proxy Nature
ZCO objects are generally proxies for instances of classes from the Python Cartographic Library. The proxy subject is obtained by calling a well defined method. Layer.layer(), for example, returns the subject for a ZCO Layer.
Properties
ZCO makes extensive use of Zope properties. The properties and their values are documented thoroughly in the ZCO module source.
Acquisition
Take advantage of acquisition to create hierarchies of Layers and Symbolizers. Good examples exist in the ZCO demo application.
Interfaces
Well defined interfaces make it easy to combine Zope objects into ensembles that can serve as DataStores and Styles.
Usage
The typical usage is illustrated in the instance diagram below:
Figure 1: ZCO classes and associations. Association by URL traversal are indicated by dashed lines, wide grey lines indicate association by containment.
Association by URL
A Layer is associated with one DataStore by assigning a traversable path from the layer to the datastore to the datastore property of the layer. Styles are associated with Symbolizers, and Symbolizers with Images, in the same fashion.
Containment Association
Styles are associated with Layers through containment, and have meaning only within the context of a parent Layer. A layer may have any number of styles.
Programmed DataStores
The object traversed to across the datastore path from a layer need not be an instance of ZCO.DataStore.DataStore. The ZCO framework only requires that this object implement the ZCO.interfaces.IDataStoreProxy interface. A Folder containing a 'datastore' Python Script will do just as well so long as the script returns an object that implements the cartography.data.IDataStore interface. See the object at
demo/zdata/points_wkt
within the ZCO demo application for an example.
Other possible configurations for programmed datastores include:
- A Folder containing a Z SQL Method and a 'datastore' script which transforms the query result set into a PCL WKTFeatureStore.
- As above but with a 'datastore' script that processes queries against a Zope Catalog.
Programmed Styles
The IStyleProxy interface allows a similiar substitution of Folders containing 'style' Python Scripts for instances of ZCO.Style.Style. Such a script shall use the catography API to create a cartography.mapping.Style and push into it any number of dynamically generated rules. See the object at
demo/layers/polygon/dynamic
within the ZCO demo app for an example.