Reconfigure Visualizations

Thus far, we have added code to the application to handle interactivity which is initiated on the bars or the vector layer. Now we need to add code to handle user interaction that starts trough the pie chart. As discussed in the introduction of section 6, this call for different response. this time we are not going to display more data on the same type that is already presented. No, we will use different data and as such potentially different visualizations. So if the interaction starts in the pie chart, the bars of population will be removed and landuse bars for all districts on the selected landuse class will be drawn. Simultaneously the same landuse values will be shown in the vector layer in the form of a choropleth.

Choropleths

The first step is to catch the events in the pie chart and then associate functions to execute the actions expected as a response to those events. Include the new functions and the event listeners in the CityApp/app/view/statistics/StatisticsController.js file as depicted in Listing 7-1.

Now, let us add some code to the first function, mouseOverPie. we will start by emphasising in the legend the landuse class that the users in interacting with. Then, we will create an array to hold the landuse data for that landuse class in every district (sliceData). For example, the area covered by agriculture in each district, or the area covered by buildings. The necessary code for these actions is shown in Listing 7-2. Update the CityApp/app/view/statistics/StatisticsController.js file accordingly.

The legend manipulation takes place in lines 7–11, and the generation of the landuse array takes place in lines 13–20. We can refresh the application and check the values in the landuse class array as temporary output in the console 21. Check your console as you move the mouse over the pie chart. Figure 7-1 shows the result for the Natural Area class.

We can now use the content of the sliceData array to create the choropleth of the corresponding landuse class. As always, we will create a function for this, which makes it easier when it comes to code reuse. We can place the function call right after the sliceData array has been populated. Insert the new code from Listing 7-3 in the CityApp/app/view/statistics/StatisticsController.js file.

To draw the choropleth, we need to determine how many value levels we want to have. In this case we do not have many districts so four levels will suffice. We also need to create a style that uses the values of the four intensity levels to render vector polygons for each district. For this to work we need to specify the intensity values for each landuse class based on its specific color.

We already have an application object to handle color data. Let us update the Colors store to include intensity values for each class. Use the code in Listing 7-4 to update the CityApp/app/store/Colors.js file.

We have added four color values to each landuse class, which we can use in the styling of the choropleths. Include the code of the showChoropleth function in the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-5.

In lines 9–11, we determine the minimum and maximum area value for the landuse class and determine the ranges for the four levels of the choropleth. In lines 15–44, we create a style function which includes the selection of the color of each polygon based on the group id 22–23. Reload the application and move your mouse over the various slices of the pie. Every time you move over a slice, a choropleth for that class should be shown. Figure 7-2 shows the image of one of the resulting choropleths.

We also need to roll the legend and the vector layer back to their normal state once the mouse leaves the pie chart. Make the necessary changes to the CityApp/app/view/statistics/StatisticsController.js as shown in Listing 7-6.

Check if the application behaves as expected. If so the default visualization of the vector layer should be in place when the mouse moves out of the pie chart.

Landuse Bars

The next action that we are going to take is to replace the population data with landuse areas in the bar chart. We will also use a function for this task. Similarly, to what we did with the function to show the choropleths, the call to the redrawBars function will be placed in the code that reponds to the mouseover event on the pie chart. Let us add the new function and its corresponding call to the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-7.

For the generation of the bars, we will use the same data as for the choropleths, which is stored in the sliceData array. The redrawBars function requires various parameters. The data for the bars, the bars line color and fill color, and, the title for the y axis. The y axis will depict areas in square kilometers, while the x axis remains unchanged. Include the code for the redrawBars function in the CityApp/app/view/statistics/StatisticsController.js file (see Listing 7-8).

Go ahead and reload the application to test the new function. The bar chart should also now respond to the user's interaction with the pie slices. Check if the label of the y axis also responds correctly.

Just as before we are only half way through here. We certainly want to return the bars to their original state when the mouse goes out of the pie chart, so that we keep the interface consistent. This time the rollback operation is a little bit more challenging because the datasets are different. Let us start by triggering redrawBars function when the mouse leaves the pie. The necessary code for this is shown in Listing 7-9. Include the new code in the CityApp/app/view/statistics/StatisticsController.js file.

If you reload the application at this point, you will notice that there are no bars shown as the mouse leaves the pie chart. This is because the function to redraw the bars does not know what attribute from the new dataset (districts) to use for the bars. Right now, the function tries to draw bars using the m2 attribute, which is not avsilable in the root of the districts dataset. Let us repair that. We will use a boolean variable to keep track of whether the bars should be drawn from population data or from landuse data. Update the CityApp/app/view/statistics/StatisticsController.js file according to Listing 7-10.

Now, we will say that when the value of the popBars is true then the population data should be used to draw the bars. On the contrary when the vale is false the bars should be drawn using landuse data. With this level of control available, we can include the corresponding conditionals in the redrawBars function to generate the correct bars every time. The code for the conditionals is shown in Listing 7-11. Use it to update the CityApp/app/view/statistics/StatisticsController.js file.

We have included a conditional in teh generation of the domains and the size of the bars 12, 19, 22. We also need to make sure that the value of the popBars variable is assigned properly before the redrawBars function is called. Otherwise we will still have the wrong behaviour. Set the values for the popBars in the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-12.

These changes complete the task of redrawing the bar chart. Reload the application and check that indeed the bars return to their default state as the interaction with the pie chart finishes.

Figure 7-3 depicts the look and feel of the application after the code to redraw tha bars has been included.

Floating Legends

When the choropleths are displayed, the user needs a reference as to the meaning of the colors. Yes, there are only four classes but still, we need to tell the user the ranges of the classes. This means we need a legend for the choropleth. The key question now is where to place it. The first thing is, it should not be permanent like the landuse classes legend, because it only makes sense to see it when the corresponding data is visible. Second, the content of the legend also changes as the users move between the various slices. And, last we do not have a container where to render it. Since the content of the legend is dynamic and non-permanent, we can choose for a popup, or better a window for the legend. Let us go for a window. Create theCityApp/app/view/statistics/LegendWindow.js file using the code in Listing 7-13.

The code for the window definition is self-explanatory. Note that we have omitted any size or position attributes. We will specify that dynamically depending on what do we use this window for. Now, attach the window to the application by updating the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-14.

Inside our initialization function of the view, we have created a ne window object 17–28 using the window type specified earlier 18. We have specified the window size 20–21. And, we have added a listener to the window to catch the show event 23–27, which is fired when the window becomes visible. We use the event to position the legend window relative (bottom-left) to the coordinates of the map panel 24–25.

The next step is to generate the content of the choropleth legend. The legend will be different for every landuse class therefore we have to generate new content for the legend every time the choropleth changes. The corresponding code should be included in the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-15.

Here, we start by making the legend window visible 16–17. Then, we determine the minimum and maximum values (limits) for each class in hectares 20–21. Next, we add to the window a title for the legend and the values of the limits that we just computed 22–28. After that we create an SVG object for the legend 30–32. And finally, we draw rectangles for the four intensity levels of each landuse class 34–40. Reload the application once more to check the legends of the choropleths. The legend should dynamically adjust to the values of every landuse class in the pie.

Now the legend shows up nicely when the mouse goes over the pie chart, but it does not disappear when the mouse goes out. Hmm, have we not seen this before? Yes we have. Let us add code to hide the window as part of the mouseout event on the pie. Add the new code shown in Listing 7-16 to the CityApp/app/view/statistics/StatisticsController.js file.

Are we done? Perhaps we are. Let us ask ourselves a question. Can we tell which district has the largest area covered by buildings. If you place your mouse over the slice for 'Buildings' in the pie, you will come with an answer. You will say district 06. Then I will say, OK, but which district is district 06. Then you will certainly be able to find out, but not while interacting with the pie chart. So, I would say we are not done yet. We also need to display the names of the districts as part of this interaction path. But where to put them? Well, we have various choices, but since we already created a window object, we can certainly reuse it again and pally the same trick as with the choropleth legend. Let us get at it. Create a new legend window by adding the code in Listing 7-17 to the CityApp/app/view/statistics/StatisticsController.js file.

Similar approach as before, but this time we are placing the window on the bottom-right of the map panel 16–17. Let us now create the content. This is content is not dynamic the names will always be the same, so we can create this content when we receive the response to the districtstats service. Update the CityApp/app/view/statistics/StatisticsController.js as shown in Listing 7-18.

Now we only need to show or hide this window at the appropriate moments. Check Listing 7-19 and add the new code to the CityApp/app/view/statistics/StatisticsController.js file.

External Events

Throughout this exercise, we have created application objects, identified relevant events on these objects, and create the expected response to the occurrence of the events. There are however other events that might interfere with the correct behaviour of the application but that are not triggered of our application objects. Try resizing the browser for example. If you do so you will notice that not all the objects of our application respond accordingly. The map gets distorted and the bar chart does not react at all. We need to make sure that these external event does not impact the application negatively.

Fixing the behaviour of the map is easy because OpenLayers provides a function to handle this situation. We only need to call the function when ever the resize event occurs. So, what we need to do is registered the resize of the map panel with the controller and then assign an application function to take the necessary actions. Update the CityApp/app/view/statistics/StatisticsController.js file as shown in Listing 7-20.

Reload and try again, this time the map should respond correctly to any resize action on the browser window.

In the case of the bar chart what we need to do is to recompute the size of the bars and axes based on the new size of the panel that contains the chart. We will create a function for that and will associate it to the resize event of the container of the bar chart. Check Listing 7-21 for the corresponding code, which should be included in the CityApp/app/view/statistics/StatisticsController.js file.