Weave is designed to be as flexible as possible. Key to this flexibility is the notion of separating out the various components into their own features. The three concepts that need to be understood before moving on are

Mapping Engine
Spatial Engine
Data Engine

Mapping Engine

The Mapping Engine is used to communicate with the underlying mapping interfaces supported by the organisations Mapping Software. Its job is to ask the Mapping Software to generate a map of a particular size (in pixels), at a particular location (in metres, feet, degrees, etc) and with a given set of map layers turned on (the layer may actually not be visible at the actual scale selected due to Scale Dependant Renderers that have been applied to the map service).

The Mapping Engine will return either a URL to the generated image or a binary stream of data containing the requested image format. The image is then sent to the client directly from the Weave server. This approach allows the Mapping Engine Software to remain within the bounds of the secure network as the Weave client does not need to know how or where to get the map. It (the Weave Client) asks Weave and Weave will do all the communications with the Map Engine.

Selection Layers

We did not mention the concept of user selections or acetate information being rendered on the map. The process of rendering selections is taken care of by Weave when the map is requested. Weave generates a second image with just the selections and acetates on them and combines or fuses the two images together to form one and then passes it to the client. If you are migrating from EView, this is important to note as EView required that if a layer was to be a Selection Layer, it had to be included in the ArcIMS service. With Weave this is not required as Weave handles the selection rendering itself. This an advantage as it enables sites to produce a cartographically correct static image of the area of interest and serve that to a particular set of users for viewing whilst still enabling the user to select any defined Entity.

Spatial Engine

The Spatial Engine is used to communicate with the underlying Spatial Database (this does not have to be a physical RDBMS, it could be a file based Spatial System like shapefiles) to request geometry and undertake spatial operations (e.g. buffer, intersect, etc). The Spatial Engine does not do any rendering of maps. It is a datastore that provides the information needed to execute spatial functions and render selected features. Different types of Spatial Engines suit different requirements. File based systems are good for small organisations where data is only edited infrequently and by no more than one or two people. If however you have multiple people editing the underlying spatial data and it is changed on a regular basis, then a enterprise system that supports concurrent editing, versioning and role based access would be required.

Most of the time, a link between the Spatial and Mapping Engines is setup by the organisation. The Weave Map Engine requires this link in order to render the selected features on the map when requested.

There can be circumstances where there is no link between the Mapping and Spatial Engines. For example, if you were serving static images or have a Mapping Engine that serves static images ( e.g. Image Web Server) then there is no need for such a link to be defined. If the Entities are setup correctly in the Weave configuration, then a user can select features on the map, either spatially or a-spatially and have Weave render them on top of the image that is then sent to the Weave client.

Entity

An entity provides a basic reference to an item that will be searched and reported on within Weave. Its relationships within Weave are shown in the diagram below.

Relationships

All the building blocks of Weave can be brought together and their relationships shown in the diagram below.

Browser not supported