Basic of data handling in Weave

Selections

One important thing to get your head around in Weave is the concept of the separation of searching and reporting.

In way of an example think of how users use search engines like Google where they search for something and get back the results. There's only ever one way to search, type something in the box, and one type of result displayed, a page of top search results.

But with Weave you have a multitude of ways of searching for things and a multitude of ways of displaying the search results. "Searching" could be preformed by drawing a polygon on a map to find all the things that fall within that polygon, or by typing in an address to search a database find the matching properties, or even by having a third party system sending a list of unique identifiers. And "Reporting" could be a simple as displaying a list of the owner names of the found properties, or generating a PDF report describing the history of the property, or sending a list of unique identifiers to another third party system.

Because of this separation and the use of a current selection searching can be combined or split across multiple systems, for example, a user is working in a property management system and has selected a number of properties, they send this selection to Weave (searching by third party system) which updates the current selection for properties, then they perform a spatial intersection operation in Weave to refine the selection of properties to only those that fall within a flood zone (searching via spatial operation), then perform an attribute search to further refine the selected properties to those that are listed in the residents database as being over 65 years old (searching via SQL). Then they display the textual list of owners of the properties (reporting from SQL) to give it a once over before finally generating a flood warning mail merge based on the final list of selected properties (reporting from document) and send those to the residents warning then that evacuating sooner rather than later may be a good idea.

To facilitate this Weave uses the concept of a current selection, where each entity you want to work with in Weave is associated with a list of unique identifiers that represent the entities that the user has searched for and is reporting on. This list of identifiers can come from anywhere and as long as each system Weave connects to uses the same identifiers to represent the same entity then Weave can work with those systems to perform searching and reporting.

So a central principal in Weave is the entity, which is nothing more than an internal id, a user facing label and a list of identifiers that represent the current selection.

Spatial Operation

If you want to be able to work spatially with an entity (select by polygon, zoom to on a map, etc) you need to tell Weave what layer/table in a spatial engine can be used to represent the entity and what column (the key column) in the layer/table can be used to uniquely identify each entity, this is done be creating a spatial mapping item in the configuration file.

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.

Attribute Display

If you want to display textual attributes for an entity you create data definitions and link those to an entity for display with a data tag (really should come up with a better name for that). Data definitions are a tabular representation of textual data that can come from anywhere, but generally will come from a database and be generated by SQL, they can be used for populating drop down lists, generating content for a BIRT report or most often for direct display of attribute data for the user.

To allow a data definition to be used to display attribute data related to a selected entity the data tag is used to link an entity to a data definition and provide a label for displaying to the user. This way there can me more than one set of attribute data that can be displayed to the user for each entity and the user can choose between which attributes to display be selecting the from list of available data's based on the label.

For database/SQL based data definitions which will be used for displaying textual data relating to an entity for the user the data definition must be configured with a key column. In the same way that the key column in the spatial mapping links the currently selected entity to a row in a table in the spatial engine, the key column in a data definition links the currently selected entity to a row in a table in a data source (as data source is a connection to a database). This way when it comes time to display the attributes for a selected entity to the user an SQL statement can be generated that only selects the rows that match the id's from the current selection.

Basing the generation of the attribute data on the unique identifiers related to an entity means that the attribute data to be displayed to the user can come from a number of different databases, including the database underlying the spatial engine (if it has one), and does not require that the data that's displayed to the user is even in the same database as the spatial layers, let alone is directly attached to the spatial records in the spatial database.

Attribute Searches

Data definitions take care of generating textual attribute data for displaying to the user, attribute searches provide the reverse. They allow the user to enter text values which are sent to a database, via an SQL statement, to generate a list of unique id's that match the user entered values, which are then uses to update the current selection for the entity that the search is associated with. This is again done by specifying a key column for the search, and it's this column who's values will be extracted and placed into the current selection for the list when a search is performed.

From the above you can see that by ensuring that spatial mappings, data definition and attribute searches all have the same concept of what value represents a given entity it's possible to combine all three, even if the actual source of the values (i.e. A specific column in a database table) isn't the same in all three cases.