Premise

 
Premise
Wanted a simpler way to access the USGS seamless elevation look-up service. Python seemed like a logical start. Note that the response from the USGS webservice is not correctly identified as valid XML by the python XML-parser. Therefore there is a small amount of scrubbing used to coerce the response into valid XML. Comments on why this is, or is not, a good idea are welcome.

STATSGO KML thumbnail

SSURGO KML Thumbnail

A short update to a previous post on the visualization of NCSS/USDA soil survey data in Google Earth. The use of the NetworkLink construct, combined with the spatial indexing present in PostGIS, allows for very rapid lookup and presentation of this massive database. Scale-dependant switching between the detailed (SSURGO) and generalized (STATSGO) databases is done through simple area calculation in PostGIS.

Here is the link to the KMZ file. Here is a link to our conventional viewer application, based on Ka-Map / Mapserver, using the same PostGIS back-end (previous post on this). This PLSS KML file is very useful along-side soil survey information.

 
Feedback is always welcome!

I have been experimenting with googlepages.
See dig.soilman.googlepages.com to see how things are evolving.
I find googlepages less cumbersome than I was expecting.

 
Premise:

Setting the magnetic declination on a compass is a critical step in accurate measurement of bearings that can be translated to map or survey. As the location of the magnetic north pole is constantly moving, the magnetic declination reported on older topographic maps or compass housings are probably out of date. Current declination values for a single point, or for large regions can be found on the NOAA sites:

• single point
• global maps

These resources are helpful, but a current, detailed (state-level) map of magnetic declination would be interesting.

Working with large piles of complex data can be a difficult task, even for seasoned experts. What happens when a non-specialist is tasked with collecting, managing, and ultimately warehousing large amounts of painstakingly collected data? What happens when multiple non-specialists are concurrently working on these data? How can a revision history be maintained when a small set of files are being passed around via email, or appended to a "master" document?

 
Premise:
The standard Latex table environment can be difficult to extend, especially when one wants to use modern constructs such as table foot notes, etc. The ctable package is a convenient approach to solving this problem. A complete worked example of a table typset using the \ctable command is presented below. Note that \ctable is a command, and therefore does not allow blank newline characters. One way to maintain readability is to trick Latex by adding a comment character to all blank lines. Link to PDF manual for ctable.

I recently upgraded to GEOS 3.0.0rc4 in order to take advantage of its more robust handling of invalid geometries (damn shapefiles!). However, there are two mini-bugs in this release which need to be sorted out when compiling against it (or at least for the two application I was interested in: QGIS and StarSpan). Note that the first issue presented here has been resolved in GEOS 3.0.0rc5.

 
Overview
The lattice package for R provides several convenient functions for plotting data which has some kind of internal structure, usually in the form of groups. Lattice plotting functions create common visualizations of data (scatter plots, box-and-whisker plots, etc.), within in grid of panels defined by one or more grouping variables. See the manual page for xyplot for documentation and examples. The author of the lattice package has posted some excellent examples with code snippets from the upcoming definitive book on the topic (Lattice: Multivariate Data Visualization with R, by Deepayan Sarkar).