The actual date-time standard is published as ISO 8601 and talks about what date-time data should look like, but programming languages, databases and other programs implement this standard with sometimes vastly different interfaces and rules.

PostgreSQL’s handling of date-time data takes the form of 6 different field types, all suited to different data needs. For the OpenTreeMap project, we’re using the timestamp data type which allows us to store both dates and times for events down to the microsecond.

Geoserver accepts a single date-time type (also called timestamp) that stores dates and times at the same resolution as PostgreSQL’s data type, so it reads PostgreSQL’s date-time data easily. Adding a date filter to Geoserver’s SLD files is also fairly easy so long as you know how Geoserver wants date-time data to be formatted. The various formats that Geoserver knows how to interpret are located here. So, if we have a field in a database table called “last_updated”, then an example SLD filter might look like this:

<Filter>
  <PropertyIsLessThan>
     <PropertyName>last_updated</PropertyName>
     <Literal>2012-01-01 00:00:00</Literal>
  </PropertyIsLessThan>
</Filter>

This filter would display any updates made before midnight on January 01, 2012. Another example (from the OGC 1.0 encoding specification’s examples) catches updates between certain dates:

<ogc:Filter>
  <ogc:PropertyIsBetween>
    <ogc:PropertyName>last_updated</ogc:PropertyName>
    <ogc:LowerBoundary>
      <ogc:Literal>2011-12-01 00:00:00</ogc:Literal>
    </ogc:LowerBoundary>
    <ogc:UpperBoundary>
      <ogc:Literal>2011-12-31 23:59:59</ogc:Literal>
    </ogc:UpperBoundary>
  </ogc:PropertyIsBetween>
</ogc:Filter>

This filter would display any updates made during the month of December, 2011. Anything that was updated outside the specified date and time parameters would bypass these filters and go on to check any other rules in the SLD file. This works great if we’re only interested in static date comparisons. But what if we want to see updates less than a week old? Or objects that haven’t been updated for more than three months? This kind of dynamic filtering is a little harder to do.

After digging through the Geoserver documentation and a lot of googling, we decided to shift the dynamic part of the filter into a PostgreSQL view. Our test view included an id field, a geometry field and a field that calculates the number of days since the last update to that object. The view sql looks like this:

CREATE OR REPLACE VIEW timestamp_test AS
  SELECT
    treemap_tree.id,
    date_part('days'::text, now() - treemap_tree.last_updated) AS days,
    treemap_tree.geometry
  FROM treemap_tree;

So now we can add this view to Geoserver as a source layer and it will see the new days field as a static number field. We can use any of the property filters on this field and style recently added data in a dynamic fashion.

One of the problems opportunities that I observed was that as coffee was brewed and consumed in the office (about 6 brews a day), there would often be an unlucky staffer who picked up the (opaque) coffee pot to find it empty.  I don’t personally drink coffee, so I was unaware of how much anticipation one would have when approaching the pot.  Not knowing how much coffee was in there, and worrying if the mug you pour may be half empty or half full.

I slowly set to work in my free time to solve this conundrum.  To me, it seemed like an individual would want to know if there was coffee in the coffee pot before approaching the coffee maker (whom some of us address reverently as Zojirushi-san).  This could be 1) a web page, 2) a desktop app, or 3) an IRC (not IIRC) bot.

I drew up some schematics, took some measurements, and retreated to my home lab to build an Arduino based, web-enabled measurement system tailored for the coffee pot. I used an Arduino Diecimila, an Ethernet Shield, a couple piezoelectric sensors, a 3 color LED, a couple buttons, and an awesome hand-crafted wooden base.

A short while later, I had a working prototype ready for testing. This device now sits in Azavea’s kitchen, measuring the weight of the coffee maker, and reporting the measurements to pachube.  After doing some internal evaluation, the name ‘Caféduino’ stuck, and I developed a couple methods of viewing the coffee pot status.

1. Direct web access
   

   The web page generated by the Caféduino

   Using this method, it’s possible to directly address the Caféduino.  This gives one direct access to the measurement values, but is more useful for other applications that are polling the data frequently.

2. Caféduino Notification
   

   The system tray notification app.

   Using this method, the Caféduino is polled continuously, and the tiny coffee mug in the system tray is updated as the coffee level changes.  This is the most aggressive method of monitoring the Caféduino which, mysteriously, is the most comforting for users.

   

   Visualizing the Caféduino history.

   When the coffee mug is clicked, the history of the Caféduino is charted in the window.  What you are seeing is a Google visualization applet that is consuming the historical data, stored on http://www.pachube.com/.

3. IRC bot integration
   

   A sample IRC conversation with the IRC bot.

   Lastly, the most interactive method of polling the Caféduino is through our internal IRC channel. The above screenshot is the conversation that I initiated with the IRC bot, and its response.  It has reassured me that there is indeed, 77.78% of a pot of coffee left.

Now our staff can check in on the coffee pot, to insure that their next visit to the kitchen will be without disappointment.  While this system works well for monitoring the coffee level, the next steps may be more involved – building a machine to automatically brew coffee.

I especially like the hourglass-like effect way of populating the columns. It gives one the feel of really counting things. Like when you switch between East Harlem and the Upper East Side.

I would like to be able to see the distribution over the whole city, or the gradients between neighborhoods, but that’s just me. I think the design is neat and clean, and tells a very compelling story.

Let’s address a few data prerequisites before diving into the actual how-to of template nesting. No matter how your comment data gets to your page, it should be in order. For example: say we have 3 comments :

• Root A – Oct 1
  • Nest 1 – Oct 15
• Root B – Oct 4

We seem to be following a chronological paradigm here and everything is in a logical order. In order to do the least processing in your javascript, your data should come to the page in this same order: Root A, Nest 1 then Root B.

Each comment should have some basic information available to the template. Root comments only need some kind of id along with the actual comment information (text, date, all that kind of thing). Nest comments need a bit more information. They should know the id of their parent (whether a root or another nest) and their nesting level or how deeply they’re nested from the top of the conversation. For our example above, a sample data set should look something like this:

{ [id: 100, text: "Root A", date: "Oct 1", nestLevel: 0, parent: 0],
  [id: 350, text: "Nest 1", date: "Oct 15", nestLevel: 1, parent: 100],
  [id: 288, text: "Root B", date: "Oct 4", nestLevel: 0, parent: 0] }

Notice that our root comments have nestLevel and parent values of 0 (zero). This makes sense: Roots can’t have parents by our definition above, and they will always have a nest level of 0. Take a look at the second entry, our nest comment. The parent value is 100 which is the same as the id value for our first root comment, Root A. In effect, we have an internal relationship key for our data.

Now that we have data in the right order and our nests know their parents and how deep they are, we can set up our Ext.XTemplate object to handle the visual component of our nesting.

var tplComments = new Ext.XTemplate(
 '<tpl for=".">',
    '<div id="comment-{id}" style="margin-left:{[values.nestLevel === 0 ? "5" : "15"]}px;
              background-color:{[values.nestLevel % 2 === 0 ? "#fff" : "#f9f9dd"]};
              border:1px #ccc solid;
              padding:5px;">',
        //comment text, date and other info here
    '</div>',
 '</tpl>',
);

Lets pick apart our template and see how it visually nests our comments for us. On the first line, we’re declaring our object, nothing new here. The next line uses a template looping mechanism (for=”.”) to create the internal tag structure for each data element in our comment set.  Now things get interesting.

The id of our eventual div tags will include the id of the comment being templated. This is done using some token replacement where you see {id}. So the html for our first comment will be in the div with the id “comment-100″.

In the style attribute of our comment div are two blocks of javascript surrounded by {[    ]} that the template will treat as javascript instead of just text. Inside those blocks, the “values” object refers to the particular comment object we’re dealing with inside our loop. The attributes on this object are the same as the property names in our data set: id, text, date, nestLevel and parent. When English-a-fied, the first block reads: If the nestLevel is 0 (meaning a root comment) then write 5 here, for any other value write 15. This will give our roots a left margin of 5px and our nests a left margin of 15. While this doesn’t quite get us to an infinitely-nested set of comments, it gets us close and provides a visual cue to the audience. We’ll get closer to a truly nested solution in the javascript utilizing this template later.

The second block of javascript in the style attribute switches the background from white to cream on alternating comments. Its English sentence might read: If the nestLevel is an even number, use a white background, otherwise use cream.

Now for some javascript to bring it all together and make our nesting work properly. After your comment data is available in the page, you can use the XTemplate‘s append function and some basic Ext DOM querying to stack your comments indefinitely.

if(comment.get("nestLevel") === 0)
{
   tplComments.append(commentLocation, comment.data);
}
else
{
    tplComments.append(Ext.get("comment-" + comment.get("parent")), comment.data);
}

This block of javascript splits our comments set into the two definitions from the beginning: roots and nests. Roots just get appended to the end of the commentLocation element on your page. Nothing fancy there. Nests, however, take a bit more thought. A nest knows the id of it’s parent comment. In our template object, each comment is contained in a div with the same id as the comment. In order to nest a comment under its proper parent, use Ext’s built-in DOM searching capabilities to locate the parent, then append the nest.

Each nest will wind up nested 15px in from the left edge of its parent; alternating comments have subtle color changes and each wrapping div is associated to a comment by id for future tinkering. And we’re done!

In the conference’s opening plenary, Chris Csikentmihalyti presented his work with ExtrAct (video, project), which is building tools for people monitoring gas and oil extraction in their towns.  He showed a google earth video zooming into Western Colorado, and showing all the wells in the state of Colorado.  It was a crowd-gasping moment. (sorry, no linkage)

Chris then talked about community projects, and used OpenStreetMap.org as an example of a global data collection effort. Another spinny globe video showed the additions of street segments to the OpenStreetMap.org database over the 2008 calendar year.  Impressive, to say the least.

The next speaker was Ben Fry, one of the inventors of Processing.  He gave a good introduction to Data Visualization, why it’s relevant, and how a successful visualization communicates a great deal of information in a small amount of space.  Among the demos in Ben’s talk, one of them was one of the earlier processing visualizations, zipdecode. (try clicking on the map and typing ’02138′)  My first thought was “Awesome, more maps!”  He followed it up later with live demo of Cascade on Wheels’ Wall Map (project, video).  Again, my reaction: “Awesome, more maps!”

These two speakers stood out to me, because of their use of spatial data in their presentations.  Neither of them said anything about GIS, geography, spatial data, or anything of that nature, they just threw the interactive maps on the projector in the auditorium, and let the maps tell the story.  It flowed into the rest of the presentation, and made sense.  It was excellent to see another perspective and use of geography and geographic data, even if nobody mentioned it, or called it out.  The data was just naturally spatial, and the visualizations were so easy to understand, there was no need to explain it.

If this is the future of news, I’m tuning in.