...
Once a spatial mapping is setup for an entity then when you do a select by polygon, a boundary intersection, a buffer operation, etc, it's the key column values that are written to the current selection for the entity, thereby updating the current selection for that entity. Going the other way, if you want to zoom to the extent of the current selection or highlight the selection on the map, then the list of unique identifiers stored in the current selection for the entity is used as the basis for performing a query in the spatial engine for geometry that matches the list of id's.
| Note |
|---|
You don't actually need to specify a spatial mapping to work with an entity in Weave, but you won't be able to display the entities location on the map or select the entities using spatial operations. It's in fact possible to setup an entire Weave client without a map or any spatial entities and have the user work purely with the textual attributes of the entities. |
The spatial operation on the client are represented with the "select/reselect/unselect by point/line/polygon/circle/rectangle" tools, along with various buffer and spatial intersection tools and setup using the Spatial Mapper configuration item.
...
Attribute searches are represented on the client using the search view and created using the Search configuration items.
Reports
Beyond the basic data display generating a Report can allow the user to produce a more formatted form of output beyond just the tabular display of the data. The reports can contain data generated by Weave data definitions or can pull in data from any data source available to the BIRT reporting engine.
Virtual Entities
While it's possible to perform joins when working with data definitions and attribute searches, for example to allow you to list all of the animals registered at a selected property, sometimes you want to work with individual entities that don't have a spatial components.
Continuing our animals example if you wanted to select all of the German Shepherds in a given neighbourhood a naive approach would be to create an attribute search that started with the animal registration table (perhaps selecting all the rows containing the animal code for German Shepherds) then join that table to the property table (assuming the animals table has a foreign key into the property table) allowing us to get the unique property id for the property that the animal is located at. Weave then uses those property id's to update the current selection for properties and now we have a list of all the properties that have registered German Shepherds. But, when we then try and display the information related to the dogs we've just searched for using a data definition that does the reverse of when the search did (that is we start with the property table, selecting just those rows that match the property id's in out current selection, then join that table to the animal registration table to get a list of the animals for each property) we see that there are dogs other than German Shepherds listed.
This occurs because what we've done is to select all of the properties that have German Shepherds, we haven't selected all of the German Shepherds which is what we actually wanted to do. So when it come time to display the animal information we're displaying information about all of the animals that are registered at each selected property, which will more than likely include more that just the original German Shepherds.
If you want to work with entities that don't have a spatial representation you have two choices, either the user works with the entities using just attribute searches and data definition and has no way of selecting or viewing the entities via the map display, or you create a spatial view for the non-spatial entity and create a new entity to represent the newly "spatialized" entity. For example with our animals search we create a spatial view in the underlying spatial database that joined the animals registration table to the property spatial table, allowing us to represent each animal record by the property boundary of the property it's registered at and then we create a new animals entity and set up a spatial mapping using the spatial view and setting the key to be the animals registration number rather than the property id.
Then when we create an attribute search to find the German Shepherds the list of id's we end up with are the dogs registration numbers, which are unique for each dog, rather than the property id which isn't unique for each dog. We'd also need to switch out attribute search and data definition so that they now use the animal registration number of the key field rather than the property id. Of course we can also keep the animal property attribute search for time when we do want to locate properties based on the animals that are registered there.
Note that we could also add the newly created animals layer to our map engine as a new layer so that we can display just the animals using their property boundaries on the map, but this isn't necessary.