Wednesday, March 12, 2008

The ViSit Anywhere Data Model

Before we can really understand the novel features of ViSit Anywhere, it is important to understand its data model. When we were designing ViSit Anywhere, we started with the ViSit site model. From our point of view, the ViSit site model had proved its utility, as it had long provided a flexible, high performance foundation for our Microstation applications. ViSit Anywhere exploits the fundamental ideas that were present in ViSit, but it generalizes them and applies them over the various information layers used in the application.

Before I start with this discussion we should understand the three fundamental layers of the ViSit Anywhere data model, concrete data, schema data and type data. These layers exist in most application, but are rarely treated as explicitly as they are in ViSit Anywhere. At the highest, most concrete level we have the engineering project data. This is a model of an engineering asset, like a water or electricity network. The elements in this layer, the pipes, electric lines, equipment and serviced customers - all have concrete representations in the real world. This is the level of data that makes the system pay. The more closely this layer of data represents real world objects, the more utility you can extract from your system.

At the next layer in the data model we have what we like to call the schema data. This level can be thought of as an organized description of the concrete model. A well developed schema layer will make accessing and updating the (large) concrete data layer much easier. Many GIS applications have weak schema models. Users are allowed to add and removed data layers with ease and without constraint. The problem is that ensuring the integrity of such a model is very difficult. The schema layer is there to provide business rules and logic to ensure that he concrete data layer remains valid. We must also remember that the concrete data layer is there to help users do their work. Superfluous data items, unnecessary details and cumbersome graphic layers can impede users in getting their work done. A well designed data schema can transform unrelated data items into a work-centered application.

We call the lowest layer in the data model the types layer. By types we mean hard computer program objects, in our case .NET assemblies. ViSit Anywhere is designed to be an easily extensible application. We wanted to be able to add extension modules simply by dropping an assembly in the program directory and then allowing the new functionality to be discovered. Since new programs invariably need new schema and concrete data, it became apparent that we would have to close the circle and make the basic executable an element of the data model also.

The ViSit Site Model

The ViSit site model was developed over the past 15 years at Géotech as its primary spatial filter. The model uses parallel hierarchies of themes and sites. Theme are logical objects representing the business rules associated with some geographic asset. Sites are collections of related geographic information. Sites contain the geometric objects displayed in the GIS graphic view, while themes provide logic, as well as an extension point for hanging associated alphanumeric data and editing tools.

The diagram to the left shows how the hierarchies are arranged. Each site is associated with a geometric boundary that contains the site's geographic information as well as all the geographic information contained in the site's children. Thus, spatial filtering is a simply tree pruning operation (in the site hierarchy), because when a parent site's boundary is not contained in the area of interest, the child sites will not be contained either.

Each site is associated with a single theme. The themes are also grouped into a hierarchy. The theme hierarchy is arranged such that information that is applicable to a larger scale appears higher in the hierarchy than those applicable to a lower scale. For example, we might have state and city information. The scale of the state would be larger than that of the city. The state theme would be associated with one or more state sites (containing for example, geographic information of state-level features). The city theme would be associated with city sites. The city sites are children of a state site. The theme provides scale-dependant spatial filtering. For example, when we are at a scale where state data is not to be displayed, all sites associated with the state theme can be ignored.

This simple example shows how parallel hierarchies of theme and site can be used to easily filter very large data sets.

The ViSit Anywhere Data Model

The ViSit site model provides much of the insight that underlies the ViSit Anywhere data model. ViSit Anywhere manages project data in three hierarchies as shown is the project explorer dialog (left) used during project configuration. The top level hierarchy is the project data, which contains a model of the assets that are being managed by the application. The second hierarchy is the schema data that describes the project data.

The ViSit site model is implemented by placing themes in the schema hierarchy and sites in the project data hierarchy. A special site linkage object in the project data hierarchy is used to make the connection between themes and sites.

Finally, there is a types hierarchy that describes the assemblies and classes that are used to implement theme and project data.

Typical ViSit Anywhere users might not notice the structure of the data model, as it is transparent to the user, however, it is important for application administrators to understand the basic principals, so that they can optimize the organization of the project. Developers looking to extend the application should also understand the data model, as the object model is a simple implementation of the data model.

An important thing to understand is that the data model was designed with change management in mind. ViSit Anywhere provides a change managed environment for multiple users performing concurrent editing out-of-the-box, that is, not additional modules or configuration are required. A robust data model means that all data items, types, schema object and asset model objects are all change managed. Thus when any change is applied to the project that change is automatically distributed to all users, simply by synchronizing with the project server. The change might be a change in types (by the addition of a new application), a change in the project structure by the administrator (a schema change), or a change in the actual project data (by an edit from a standard user) - changes at all levels are changed managed using the same basic infrastructure.

In a future post I will explain how the structure of the data model enables the implementation of the change management system and how change management allows ViSit Anywhere users to more easily maintain their important geographic data and to derive more benefit from them.

No comments: