m.k.ge•o•mat•ics |ˌjēəˈmatiks|

I’ve been playing with the motion chart gadget in Google’s AJAX API Playground recently, and have found it to be an extremely interesting tool to use. In order to produce data rich charts, all that is necessary is to import a tabular datasheet into google docs and call on it within a javascript function.

The spreadsheet itself requires:

• The first column be entity data (place names, events, etc.)
• The second column to be formatted as ‘Date’
• The third and following columns to contain your chart-worthy data.

A simple example can be found below depicting historical weather station information for three cities in the Western United States. This information was downloaded from the Western Regional Climate Center and imported manually into a google docs spreadsheet. As we can see, we have a variety of different ways to explore the data, and hopefully, synthesize them into useful information for decision makers in a best case scenario.

Above: Markers indicate the cities in which weather station data was collected.

Above: Google Motion Chart Gadget. NOTE: The data are actually compiled monthly averages from 1971-2000. For the sake of simplicity however, i fed the date column in a format of ‘Jan-1′ which turns out automatically appends the current year. The proper date should read for example, ‘1/1′ rather than ‘1/1/09′.

In any event, in a data rich GIS environment, we can easily succumb to ‘data overload’. This creates a barrier for decision makers in understanding their situations, and as such can lead to poor planning. Through the careful use of data visualization tools such as this, however, decision makers can be empowered to quickly analyze data in a variety of ways, creating useful information on-the-fly and without the use of specialized GIS technical know-how.

At least I think that’s how it works.

The vacation is over. A new job and a new semester are already providing plenty of opportunities to explore those crazy technologies of the geoweb.

A need to incorporate the Yahoo Geocoder into a new OpenLayers app has proved to be a great learning experience in the navigation of the development version of OL. The YahooGeocoder.js addin, created by OL community member, ’sbenthall’, requires two prerequisites to run: A proxy.cgi script as well as a Yahoo Developer API key. Why would this RESTful service require a proxy, you might find yourself asking? Well, because even though you can query it in a RESTful fashion, the data is returned in an XML shell, requiring a proxy to allow complete the XMLHttpRequest. Yahoo has a great article for novice web programmers like myself explaining the role of  Web Proxies, which can be found here.

A quick overview of the primary steps to add the YahooGeocoder.js addin are as follows:

1. Sign up for a Yahoo APP Key to enable access to their geocoding service.
2. Add the proxy.cgi script to your webserver’s ‘cgi-bin’. Note: When navigating to the proxy.cgi’s url, you might encounter, ‘access denied’ errors. If you do, make sure that you have the proper permissions set for your cgi-bin directory. This can be done using the terminal command, ‘chmod 755′ targeting cgi-bin directory.
3. Edit the proxy.cgi script to include ‘local.yahooapis.com’ in the list of ‘allowedHosts’.
   

   Above: Modified 'proxy.cgi'

4. Add the YahooGeocoder.js file to the OpenLayers ‘lib/OpenLayers/Control’ folder.
5. Add “OpenLayers/Control/YahooGeocoder.js” to the variable array, ‘jsfiles’ inside the “lib/OpenLayers.js” library.
   

   Above: Modified 'lib/OpenLayers.js'

6. Test the geocoder’s functionality using the supplied .HTML file. (Hopefully it should work!)
   

   Above: Geocoder Result with Properly Formed XML Response.

Six simple steps, but it can be challenging if you haven’t tried to install any addins to the OL library before.

In the above image, the firebug window can be seen returning a properly formed XML Response, having successfully executed the geocoding function. If you enlarge the image, we can compare this to the raw XML-Response using a properly constructed query. Note in both the response captured from firebug (above) as well as the raw XML (below) the presence of the address: 510 High Street, Bellingham WA, broken down into it’s individual units along with the geocoded result.

Above: Basic XML Return

Further diving into the capabilities of firebug, we can use the DOM inspector to ensure that the various parameters required to properly execute the Yahoo Geocoder are in place. Note in the image below the presence of such necessary information as the APP ID Key, Projection, and Class, for the ygc variable. If any of these parameters happened to be incorrectly set, it would be displayed in this view.

Above: The Firebug DOM Inspector

I’m finally starting to appreciate the power of firebug as a development tool, which just so happens to coincide with my ability to understand it at a basic level. Hopefully as my experience in GIS Web Development grows, so will be ability to use the higher-end functions of this tool.