Recent Data Visualization Work
Wow! I woke up and realized it’s almost Thanksgiving and I have not posted anything all summer and most of the fall.
I’ve been in kind of a development black hole and spending a lot of time on training for something new and interesting. In the May-June time frame, I had the opportunity to design/develop both a business and e-commerce site for a local company. I took this as a chance to re-engage with UX and CSS, skills that have become quite rusty over the years.
I now feel completely comfortable working in the HTML5/JS space along with frameworks such as Angular JS and Bootstrap. This is a necessity for my core business which is helping other developers integrate complex content into their customer sites and RIA’s.
I’ve also continued my focus in data visualization and have completed a couple projects over the last few months. I do not have license to release any information about one project and can talk about the other in a very limited context.
This was an interesting graphing component that involved a new application of some very old algorithm technology. The end application was targeted for the iPad and I worked on the computational internals of a graphing component.
This component graphed time-series data, so it is known in advance that x-coordinates are always increasing. The customer wanted to fit a smooth curve through a number of data points, each drawn with specified width and color. Labels were to be displayed at each of the data points along with an arrow of specified dimensions that pointed in the direction of the curve at its terminal point.
Label text was not allowed to overflow specified boundaries for the label background. The client provided minimum and maximum font sizes. The graphing component attempted to fit the text into a single line. If the text could not be rendered in a single line at the lowest-allowable font size, then the component attempted two or three lines. If none of those options worked, a two-line display with ellipses was rendered.
The actual curve was a natural cubic spline. Drawing the arrow is easy after computing the tangent to the spline at the last data point. It’s a matter of computing a normal to that tangent, which provides a local coordinate space for the arrow. Length and height of the arrow are known, so it’s just like drawing a triangular arrow in screen space.
The arrow, however, was not allowed to intersect with a label background. This involved doing a post-render collision check. If a collision was detected, the minimal space to extend the arrow (with some user-specified spacing) was computed and the arrow was re-drawn.
A final complexity involved overflow of the graph area beyond user-specified bounds. In some instances, re-drawing the arrow caused the graph display to extend beyond user-specified axis limits. In this case, the graphing component performed the equivalent of a 3DS Max zoom-extents operation. The component calculated new graph limits that guaranteed the display would fit inside the axis limits with user-specified buffering. The graph was then redrawn and an accessor allowed the application to query new axis limits.
Here is a highly sanitized screen shot that has all axis lines, graph labels, and any other identifying information removed. Data labels were renamed to remove any hint of the application or client.
This was an interesting application as nothing fundamentally new was required in terms of algorithm technology. I’ve computed and graphed cubic splines in a variety of languages since the 1980’s. Collision detection and computation of local coordinate spaces is common in game applications. The zoom-extents style operation is also very familiar in 3d modeling and animation software.
I enjoyed this project as it provided an opportunity to mix techniques from a number of fields into a single business application.