design for space-time

Current design for "space-time" introduced multi-array variable in each class/object
E.g. in a space-time variable choropleth map, there is a boost::multi_array used to store the values of all time steps. If time changed, different dimension of the multi_array will be used to redraw the map.

This design is not easy to maintain and not easy to extend as well.

For future (also for GeoDaWeb), the design should not use multi_array to store space-time variable in one class/object.
1. The space-time data should be always maintained (get/set) in table or related data object.
2. The choropleth map should be as simple as a basic map and does not need to maintain multi-array data structure.
3. By feeding a simple map different data, the map represents choropleth of different variables or one variable at different time steps.
4. To manage space-time for, e.g. a choroplet map, a wrapper class, e.g. "SpacetimeChoroplethMap" can be added to manage feeding different data to a SimpleChoropleth map.

Space-time choropleth map
|
|
|
\ /
Simple map

The rules also apply to other space-time maps and plots.

Start by locating the space-time choropleth map and its boost::multi_array usage, then trace how data is stored and supplied to the map. Compare the current design with the proposed SimpleChoroplethMap and SpacetimeChoroplethMap split. Done means space-time data is maintained by the table or related data object, while maps receive the selected data rather than maintaining multi-array state.

Written by the indexing model from the issue text.