Blog

paths.pngPremise:
Simple comparison between the least-cost path as computed by r.walk vs. r.cost. Default parameters, unity travel friction, and λ = 1 were used with r.walk. Slope percent was used as the accumulated cost for r.cost. Test region similar to that used in a previous navigation example.

Results:

  1. r.walk
    • Shorter total path (6.03 km)
    • Tendency to stay mid-slope, and cross large drainage at the gentlest possible position
  2. r.cost
    • Longer total path (7.12 km)
    • Tendency to follow drainages upstream-- not always possible in steep terrain

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?


Update to a previous post on mapping wireless network information with GRASS, kismet, and a custom python script. This time, some modifications to the python XML-processing script so that we can work directly with the Kistmet-xxx.gps files. Processing the .gps files allows one to produce a shapefile from each trip to the field. The shapefiles can be combined in a GIS (like GRASS) with simple vector processing (i.e. patching). Example steps are presented below, complete with an RST-based interpolation of wifi card signal and noise observations.


Vacation + Sailboat + GPS + GRASS + R

Posted on August 3, 2007

Overview
I recently spent some time near Huntington Lake- one of the more interesting sailing lakes in California. Lashing a GPS to the front of the boat was an enlightening way to look at the spatial and angular trends in the amount of speed I could get out of this boat. With 218 sq. feet of sail, and only 320 lbs of displacement (i.e. the boat's weight) - the Hobie 16 is an exciting 2 person boat for light to medium winds. With my regular crew absent we did not use a trapeze and thus were only able to get the boat to about 11 knots (6 m/s).


Overview:
Simple application of spatial point-process models to spread patterns after some backyard target practice. Note that only a cereal box and 2 sheets of graph paper were injured in this exercise. Data files are attached at the bottom of this page; all distance units are in cm.

A simple experiment was conducted, solely for the purpose of collecting semi-random coordinates on a plane, where a target was hit with 21 shots from a distance of 15 and 30 feet. The ppm() function (spatstat package) in R was used to create point density maps, along with a statistical description of the likelihood of where each target would be hit were the experiment to be conducted again (via point-process modeling). While normally used to model the occurrence of natural phenomena or biological entities, point-process models can be used to analyze one's relative accuracy at set target distances. One more way in which remote sensing or GIS techniques can be applied to smaller, non-georeferenced coordinate systems.


Example of bad Tiger data in Stanislaus County: Red lines are the original road network, green lines are the corrected road network.
Example of bad Tiger data in Stanislaus County: Red lines are the original road network, green lines are the corrected road network.

The Problem
The US Census does a nice job of collecting all sorts of geographic and demographic information every 10 years. This data is available free of charge in the rather complex and soon to be replaced TIGER/LINE format. While this data covers the entire US down to the local road level, there are numerous errors and even extreme cases of coordinate-shift. Here is an example from Stanislaus County, California. The original TIGER data (red lines) are offset several hundred meters from the imagery. While it is not clear what may have caused the problem, it can be fixed without much effort using an affine transformation. We do not have the transformation matrix, however it can be 'fit' to a set of control points by several methods. The general form of the affine transform can be conveniently represented in homogeneous coordinates as:



Exporting GRASS Raster Data to ArcGIS

Posted on November 4, 2006

Premise:
Exporting FCELL or DCELL raster data from GRASS to ArcGIS can be a bit of a pain. Exporting to GeoTIFF with r.out.gdal can result in files which sort of work. In ArcMap these files are initially displayed as having a data range of (1.17549e-038,3.40282e+038). If however, you choose to render the image using a fixed number of classes, the correct data range is displayed. Converting the geotiff to GRID via IMAGEGRID resulting in a bogus file, which appears to be caused by IMAGEGRID interpreting it as integer. Some of theses issues may be associated with this ticket on the OSGEO trac site.


Images from Pinnacles Soil Profile Analysis

Posted on November 1, 2006

Misc. scanned images from work at the Pinnacles National Monument, in collaboration with the NRCS and NPS. These images are the prototypes for many of the new educational materials being developed for the visitor's center and online interface to soils information. Over 300 pit descriptions were collected by NRCS staff and myself, and are currently being digitized with our own pedon management system, PedLogic. Numerous techniques for the automation of soil survey operation, digitial soil mapping, and field assistance are currently in development. Many of the detailed features which will not appear in the final soil survey product will be featured in bulletins written up for the PINN interpretive staff. It is our goal to assist the park staff in communicating the importance of soil resources as the active junction between the biosphere and the lithosphere. GIS tools used include: GRASS, PostGIS, R, GMT, and many others. A digital version of the pedon description form illustrates some of the visualization capabilities of PedLogic.


Some simple examples of how to extend data collected from kismet along with gpsd. The prgram gpsmap, bundled with kismet, can create excellent maps of wifi networks, albeit not in a georeferenced format. With some ideas from Matt Perry, a quick read through some python docs, and a little testing I put together a simple python script (kismet2shp) which will convert Kismet XML logfiles into a shapefile (see attached file at bottom of page for the source). Conversion from kismet logfile to KML was demonstrated in the above article by Matt. Simple usage of kismet2shp is summarized:


UPDATE:

it looks like the mysterious NAD_1927_To_NAD_1983_6 transform is actually a localized transform for the Quebec area. Furthermore, ESRI has informed us that this is not in any way a default transform, rather the first in the list. In summary, regardless of the software that you are using to do this type of work, always know your data and do your homework on the available methods. Thanks to Matt Wilkie for the detective work.

The Experiment
Quick comparison of the results of a vector projection using both OGR (GDAL wich uses the Proj4 library) and ArcGIS 9.0. Ideally both methods should return just about the same coordinates. The GDAL tools use the NADCON grid corection for datum shifts in the US and Canada, while ArcGIS provides several transformation methods (NADCON being one of them). Figure 1 demonstrates the dialog box where datum transformation parameters are set in ArcGIS. The default (first) method in this list NAD_1927_To_NAD_1983_6 is more than slightly confusing. Perhaps the rationale for this approach is explained somewhere, but I have certainly never come across it. In order to better understand any possible differences in the results of a datum shift operation, the three following operations were performed: