Closer Look

Inputs

The input fields are very straight-forward, but there are a couple of things to look a little closer at!

Two text fields..

These text fields are checked for proper data by the following javascript, found in mapFunctions.js

This data checking is very suboptimal, but does work with any integer value a user could supply. It breaks sometimes if non-numerics are entered!

Two drop downs..

Each of the options for either of the two select elements have values associated with them. I test against these values to determine which settings to change and how. In the case of selecting the data set, the value is identical to that which the backend php is listening for (This php script itself is touched on in the 'DL and buffering' section)

Here is an example of how my code uses the option values

This example is of taking note of the selected dataset. 'dataID' is the variable passed to the backend script

At this point I also assign the color scheme to be used. The two arrays colorSchemeColors and colorSchemeValues are parrallel arrays, one knows the ranges to which to apply a color and the other knows the color associated with that range.

Buttons

The buttons are also relatively simple, but I thought this would be a good place to talk about the program generally and illustrate what kinds of paths the user can take.

First I'll go over the global variables mentioned here

IS_PLAYING is to signal that the program is currently in-loop. This is essential to ensure that you cannot resume while already running through data, which creates another instance of the loop, losing the ID for the first one... very bad!

ACTIVE. Since we are talking about how the resume event can go wrong, this variable will signal whether the range (start-end year) has been fulfilled. If Resume does not know about this, it is possible to resume after the program has finished with your range of data - up to the point of exceeding the end of my data sets!

Basically the year will continue to tick up, but no data is available, and none will display

HAS_PLAYED signals whether the play button has been pressed at all. This is important because if the user tries to resume without pressing play first, there will be no request to get data - which means the update function is called without data to update with.

I have been using the word 'loop' a lot now, but this is technically not a loop. Since I am working in a browser, I decided to call this 'loop function' on an interval. This allows for a consistently triggered update function that I needed as well as less processing and more responsiveness for the browser itself.

Finally the Enable Graph button. I did not draw this into the illustration because it is really too simple

The graph is loaded with the page as a hidden element and is updated at all times with the help of the Chart.js library. Whenever the user clicks this button, it shows/hides accordingly

* The play button does not actually start the interval-loop, this happens during the callback of the data request. I will be explaining this further in the 'DL and buffering' section.

Google Maps

Retreiving the google maps api

And setting it on the screen

Beyond positioning, I was also able to set some default rules for the map. For example disallowing zooming manually.

The crucial part to implementing this was supplying a registered key, which can be seen in the html script tag above.

Finally, mostly because I liked how it looked, I decided to place all the html elements onto the map itself. This was accomplished like so

Data Layer & geojson

Once the map was loaded and set in position, I had to create the graphical interface that would actually display the data

The google maps api had multiple ways to display data, and I eventually decided on using Data Layers for 1 main reason. And that is that I found that I could link a geojson file to the Data Layer and without much effort have all the counties drawn for me! Let me show you what this looks like..

Thats it! The geojson file is basically composed of [CountyName, CountyID, list of points to outline, next County...]

To change the colors of each individual county, I can call the following

Download requests and proccessing

The basic flow of the whole data transfer system looks like

Play Button --> dlNext(code: 0) --> nextCur() --> dlNext(code: 1)
dlNext(code: 0) --> dlNext(code: 1)

dlNext()

This function actually submits the http request. The var 'code' supplied refers to the return code, and determines what to do at callback.

These are the rules for that, inside the callback function:

As you can see, the interval-loop is initiated after receiving the callback from requesting with code: 0. This is opposed to starting after the onClick event of my play button. This is vital, as it ensures that nothing will be started until I have at least enough data to start displaying.

Because of my play button event's lifetime, the function has no idea when this data is actually received. Because of this, it is also important during that first request call (code: 0), to also submit a request with code: 1, Effectively readying the buffer -- and better, this is already background proccessing!

Buffering data

So lets look a little bit more into how this buffer system works.

I have already explained that calling my function dlNext(code, id) will submit a request to the server to download the dataset refered to by 'id' and return with request code = to 'code'.

If the request code is 0, then the data received will be placed in Acur -- array of all values of current year.
If the request code is 1, then the data goes to Anext -- the buffer array.

Because of this setup, after the initial download, I only need to request with code: 1 for the remainder of the run.
And I do that in the nextCur() function, after I run out of data to use in Acur -- which just so happens to be at the end of a single year

First, it moves the buffer data into Acur so the program can continually pull from that single array. Then it submits another request to fill the buffer array Anext with new data.

Now why this works so well as a buffer, is because the callback to the request is handled as a seperate thread. For the user, this means the whole interaction passes entirely unnoticed!