GAV Flash Tools
The Geovisual Analytics Visualization or GAV component-sharing toolkit and application-building environment is based on the principles behind the Visual Analytics research program including aspects of explorative and collaborative visual data analysis. It contains a collection of visual components, data analysis algorithms, tools that connect the components to each other and data providers that can load data from various sources. The framework is fully integrated with Adobe’s Flex Framework. The GAV toolkit was developed to build statistical geovisual analytics applications such as the eXplorer
GAV Flash uses the Adobe Flash API for graphics and integrates with the Adobe Flex Framework
First developed for interacting with large data using Microsoft’s .Net and DirectX, the GAV Flash was in 2010 adapted for the Internet using Adobes Flash V10 basic graphics and Flex for user interface design. GAV Flash was designed with the intention to significantly shorten the time and effort needed to develop dynamic Web-enabled Geovisual Analytics applications through a layered component architecture based on object-oriented class libraries programmed in Adobe’s ActionScript language. A GAV Flash component incorporates versatile interaction methods drawn from many data visualization research areas.
GAV Flash addresses the following generic Geovisual Analytics tasks:
- Customizable interactive motion visual representations for Web publishing;
- Framework for the creation of user components such as data transformers and also for making changes to existing low-level visualization components so that ideas can be tried out rapidly in a fully functional useful environment;
- Coordinated multiple, time-linked views;
- Component-embedded interactions including brush, pick, highlight, filter, dynamic sliders, focus & context and other special interaction facilities;
- A data cube model for fast access to spatial-temporal and multivariate attribute data required for time animation;
- Uploading data using standard importers such as SDMX or PCAXIS or implement your own database access;
- Using online maps such as Google map, Bing map as background maps and putting glyph layers on top of the online maps;
- Integrated snapshot mechanism for saving and packaging the results of a geovisual analytics reasoning process – the foundation for Storytelling;
- Publishing (HTML code) discoveries and knowledge in blogs or web pages as embedded dynamic visualizations;
Research paper available at:
Layered Component Toolkit Architecture
Figure:GAV Flash layered component architecture
The Framework Design Principle
The core philosophy of GAV Flash is modularity, application developers should be able to pick and choose from a wide range of visualizations, data providers and data transforms and combine them in various ways. This puts a high demand on each component of the framework to be generalized so it can receive and communicate data with others. At the same time, each component should be self-contained so that the advanced functionality is always present, no matter which components are combined. The generalization is achieved through definition of interfaces, which detail only the necessary functions and properties in assets shared by components. An example of this is the dataset, whose interface is limited to functions that supply data and metadata, all other functionality is encapsulated in the implementation. As the components are only aware of the interfaces, we can easily replace the dataset with some other structure, for example a direct database connection, without re-implementing any visualizations or data processors. Apart from the datasets, GAV Flash applications are built using a combination of visualization components and linking modules that control selection, filtering, colour and animation. Other components handle application level events such as menus, and a module for the snapshot mechanism. The abstraction into interfaces also allows others to extend the framework with new functionality, be it new visualizations or data providers. They simply have to follow the framework definitions of how to access data and shared assets and then implement their own ideas.
Atomic and functional component architecture
The generalization of components coupled with advanced features can make it hard to encompass all data scenarios in a component. It could be faced with a large multivariate dataset but also with a highly dense temporal set. These two types of datasets often require different solutions in terms of the data processing, the element drawing, and also the end user experience of the visualization. To facilitate this need for dynamic components we break them down into small blocks called atomic components. These atomics are used together to form a fully functional component but they are not dependent on each other, so they can be combined in any way. This concept can take many forms depending on the parent component, the clearest example being how the map uses different layers to display different levels of data as presented below (Figure). The same type of concept is used in other components as well, while not as obvious as the map example.
The combination of a component base with one or several atomic parts forms a functional component. They are generally encapsulated together with the required GUI elements needed to control the visualization so that only the combined properties of all atomic parts are exposed to the surrounding application. The atomic parts allow the creation of custom functional components that can differ extensively depending on the end users' needs. A number of atomic parts can be reused in several components. For example, a circle glyph layer can be used in both the scatter plot and in the map or a range filter can be used in both the PCP and the colour legend. The functional components can in turn be used by application developers and linked to each other through the use of linking components such as a selection manager, a visibility manager, and an animation controller to create quick prototypes and get a first look at their data. That first prototype can then determine which way the visualization needs to go, and if some kind of special atomic and/or functional components needs to be developed.
Last updated: 2016-04-06