levelplot example: soil temperature (left) and moisture (right)

Several recent articles appeared on the R-bloggers feed aggregator that demonstrated an interesting visualization of time series data using color. This style of visualization was readily adapted for the time series data I regularly collect (soil moisture and temperature), and quickly implemented with the levelplot() function from the lattice package. I hadn't previously considered using a mixture of factor (categorical) and continuous variables within a call to levelplot(), however the resulting figure was more useful than expected (see above). A single day's observation is represented by a colored strip (redder hues are higher temperature values, and lower soil moisture values), placed along the x-axis according to the date of that observation, and in a row defined by the location where that observation was collected from. Paneling of the data can be used to represent a more complex hierarchy, such as sensor depth or landscape position. At the expense of quantitative data retrieval (which is better supported be scatter plots), qualitative patterns are quickly identified within the new graphic.

iPhone App Screenshot rev 0.2 - icon

iphone App Screenshot rev 0.2 - in Fresno

 
Some Updates:
The application has been updated with a proper icon, and ability to toggle GPS on/off for battery savings. A horizontal accuracy filter was added to prevent erratic behavior while the GPS settles. Preliminary documentaion here.

According to the excellent source code evaluation tool, SLOCCount, our online soil survey (SoilWeb) code is worth about $268,543 and would require about 2 years of development time to re-create from scratch with a single developer working full-time. This is a fairly close estimate, as I have been working (part-time) on this code-base for 3 years now with most of the time spent in the first 2 years. For comparison, the current development version of GRASS 6 is based on about 230 person-years of development time and is worth about 31 million dollars. Neat!

 
SLOCCount Output

Total Physical Source Lines of Code (SLOC)                = 8,910
Development Effort Estimate, Person-Years (Person-Months) = 1.99 (23.86)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 0.70 (8.34)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 2.86
Total Estimated Cost to Develop                           = $ 268,543
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler

Notes on install spgrass6 -- ubuntu 9.10

errors related to package XML

Cannot find xml2-config

you need libxml2 and libxml2-dev too.

 
Premise
I was recently asked to print out a fabric pattern that could be used to cover a sphere, about the size of a ping pong ball, for the purposes of re-creating a favorite cat toy (quite important). Thinking this over, I realized that this was basically a map projection problem-- and could probably be solved by scaling an interrupted sinusoidal projection to match the geometry of a ping pong ball. Below are some R functions, and examples of how this endeavor evolved. Thanks to Greg Snow for this helpful post on the R-mailing list, describing how to preserve linear measurement when composing a figure in R. So far the pattern doesn't quite fit.

 
Update
It looks like it was not the printer's fault-- I had used the wrong radius for a ping pong ball: 16mm instead of 19mm or 20mm (there are 38mm and 40mm diameter ping pong balls). Updated files are attached.

Sinusoidal Projection

Just back from the annual meetings, and it looks like there is a significant interest in collaborative R coding of soils-related algorithms and visualization. A new R-forge site has been created to host Algorithms for Quantitative Pedology. Public release of the 'soil' package should be ready in a couple weeks.

Soil Profile Dendrogram

 
Premise
SSURGO is a digital, high-resolution (1:24,000), soil survey database produced by the USDA-NRCS. It is one of the largest and most complete spatial databases in the world; and is available for nearly the entire USA at no cost. These data are distributed as a combination of geographic and text data, representing soil map units and their associated properties. Unfortunately the text files do not come with column headers, so a template is required to make sense of the data. Alternatively, one can use an MS Access template to attach column names, generate reports, and other such tasks. CSV file can be exported from the MS Access database for further use. A follow-up post with text file headers, and complete PostgreSQL database schema will contain details on implementing a SSURGO database without using MS Access.

If you happen to have some of the SSURGO tabular data that includes column names, the following R code may be of general interest for resolving the 1:many:many hierarchy of relationships required to make a thematic map.

 
This is the format we want the data to be in

    mukey     clay      silt      sand water_storage
   458581 20.93750 20.832237 20.861842     14.460000
   458584 43.11513 30.184868 26.700000     23.490000
   458593 50.00000 27.900000 22.100000     22.800000
   458595 34.04605 14.867763 11.776974     18.900000

 
So we can make a map like this

 
Premise:
The current default database back-end used by the GRASS vector model is DBF (as of GRASS 6.5), however this is probably going to be changed (to SQLite) in GRASS 7. The DBF back-end works OK, however it tends to be very sensitive (i.e. breaks) when reserved words occur in column names or portions of a query. Complex UPDATE statements don't work, and just about anything more complex than a simple SELECT statement usually results in an error. Switching to the SQLite (or Postgresql, etc.) back-end solves most of these problems.

Currently GRASS uses a single SQLite (file-based) database per mapset-- convenient if you are interested in joining attribute tables between vectors; but not set-in-stone as the final approach that will be used by default in GRASS 7. Regardless, converting the back-end is a fairly simple matter. Finally, taking the time to convert to an SQLite or Postgresql back-end will undoubtably save you time and sanity if you ever find yourself working with vector+attribute data on a regular basis. Having access to a complete implementation of SQL can make extracting, summarizing, joining, and re-formatting (column names, types, etc.) tabular data much simpler than what is available in the DBF back-end. Also, there are several convenient graphical SQLite managers available, such as SQLite manager, SQLite data browser, and SQLite Admin.

Optimal Route in 3D

 
Premise:
Several data-loggers in steep terrain; how can we visit all of them in the most efficient manner such that we traverse the least cumulative slope gradient? In a sense this is a traveling salesman style problem, with travel costs defined by slope gradient. The v.net.salesman module in GRASS can be used to compute the optimal route between data-loggers, given: 1) a network of lines connecting all points to be visited and 2) transferal of slope cost information to the network. An example approach is listed below. Note that due to a bug in v.net.salesman, we need to use one extra step-- details below.