Digitizing the Wacom Way

A key component of our land cover mapping is manual quality control.  We accomplish this though the application of "heads-up" digitizing techniques within ArcGIS.  A single project can often require tens of thousands of manual corrections made for a given project.  With so many edits even a minor improvement in per-polygon digitizing speed can yield huge gains.

We were intrigued by the possibility of using a pen-driven interactive display to perform manual corrections because most people have extensive experience drawing with pens, and are familiar and precise with their control.  This allows the end user to draw their edits in a natural fashion directly on a digital map.  We contacted the folks at Wacom who were kind enough to ship us their DTU-2231 to test in our production environment.

The DTU-2231 has 22” screen, which is bright and crisp.  There is a power button that switches the display on and off, and a display menu similar to what you would see on a standard monitor (brightness, contrast, screen position, etc.).  Also included is a stylus pen that can be stored behind the monitor in a recessed holster when not in use. The stylus is the size of a standard pen, and has three buttons: two buttons near the point and one button on the end.  The end button is similar to an eraser on a pencil.  The display ships with software that allows for customization of the buttons, sensitivity of the screen, and different profiles for different software installed on the computer.

In terms of the Wacom Tablet’s application in GIS Editing, several key advantages surfaced:

• The tablet allows for a standard mouse to be connected, allowing the user to switch between the fast pen for editing and more “computer friendly” mouse for doing other things.
• The software allows the user to enter custom “keystrokes” for the buttons. In the “customize mode” window of ArcGIS, the user is able to enter “shortcuts” for the editing tools. In our case, we have assigned “e” to switch to the feature selector tool, “c” to switch to the pan tool, and “{alt} + s” to save edits.  After assigning these shortcuts in ArcGIS, we assigned the stylus buttons to match: The “eraser” button is assigned to “save edits,” the primary button  is assigned to “feature select,” and the secondary button is assigned to “pan.” In assigning these shortcuts to the different buttons on the pen, we can easily create a feature, select a feature (to delete or reshape), pan the map and save our edits without ever having to move the mouse around the screen – all of these functions take place right on the stylus.
• Edits are fast and precise

There are however some drawbacks:

• When editing attribute changes need to be made, the pen can actually slow things down. A mouse is the most effective way to change a feature’s attributes since there is inevitably a lot of clicking that goes on.
• The editing templates in ArcGIS 10 can “confuse” the pen and the custom buttons will no longer work. In ArcGIS 10’s editing templates, the user “preselects” the attributes for the polygon before going to create it. This creates a problem as the user must constantly be predefining the attributes before drawing. This problem can be fixed however by turning off the “create features using templates” in the “ArcMap Advanced Settings Utility.”
• Another potential problem that we ran into occurs when individual users change the customized settings for their own purposes each session. Deciding on customized buttons is something that should be done as a group, as having to redefine the buttons every session can take 15 minutes to complete.   That is of course a human resource problem as opposed to a Wacom problem.

For our needs at the SAL, the Wacom Tablet represents a time effective tool for editing single data type vector datasets (i.e. editing a vector layer solely composed of polygons representing tree canopy). The editing process is fast, precise and natural.  We ended up purchasing the DTU-2231 and will likely purchase another one this summer.

GeoNet - Channel Extraction from LiDAR

This post is a summary of one of our graduate students, Terry Barrett, who did some excellent work getting GeoNet to run on a sizable (billions of points) LiDAR dataset.

---

GeoNet is an open-source Matlab code for stream-channel extraction of high resolution digital elevation data, developed by Passalacqua et al. at the National Center for Earth-Surface Dynamics at the University of Minnesota.  With the release of version 1.0.1 last September, the code has matured enough to be capable of adaptation to production use.  One of our projects had need of stream-channel extraction for its one billion point, one meter resolution LiDAR DEM, and I was assigned the task of scaling up GeoNet and producing the stream-channel network for the study watershed.

GeoNet is designed to extract the channel network for a single watershed of maximum extent of about 2000x2000 elevation points, which it can do in a reasonable time (a few minutes) if the code is compiled.  When I began using GeoNet v.1.0.1, there were no compiled versions offered for Windows operating systems, but I was able to compile it for both 32 and 64-bit using the C++ compiler included in Visual Studio 2010.  

Development of the production code was done using a 3.75x3.75km subset of the watershed DEM, which produced a code that can: tile a geotiff raster into buffered tiles, sized for GeoNet; process those tiles through GeoNet to determine the channel network; trim the resulting channel-network shapefile tiles to the original tile dimensions; and connect the tiled-channel shapefiles with channels that conform to stream-flow logic. 

Here is the output on the subset DEM (runtime on a 32-bit machine was about two hours; the blue dots are the connecting channel locations):

Here are some representative channel connection locations from that run that show the robustness of the connection logic (green lines are trimmed-tile channels, red dots are identified channel ends, and blue lines are the channels added to provide logical connections; tile boundaries are shown as dashed lines):

 The logic correctly connected the nearest independent channel ends for all locations except one, and the code was fast enough for the available time on the production machine, and so it was then used to run the entire watershed DEM.

Here is the output for the entire watershed (run in two halves, in parallel, on a 64-bit machine; runtime  ~ 36 hours):

 

The connector channels:

There are three reasons why the channel network has a few holes and doesn’t go to the edge of the DEM:

1) GeoNet’s curvature calculation fails on tiles with more than about 20% missing data, which affected both the edge of the DEM and some interior areas with missing data.

2) A few tiles crashed the Dinf mexfile (which calculates contributing area); I examined the tiles, and could find no significant differences between them and nearby tiles that did not crash.

3) A few channel shapefile tiles (all lowland areas, possibly covered by water) crashed the connecting code; they were about 3X the size of the next largest files, and so generated overly-large connection matrices.

The project was successful, insofar as it produced an automatically generated shapefile network over most of the watershed, but there are areas for further improvement and development:  

1) Prevent holes in the network – by debugging/improving the areas of code mentioned above; using a watershed DEM with a larger buffer (perhaps 2km instead of the 10m that the watershed DEM currently has); and/or performing the tiling with another program, such as ERDAS IMAGINE (I modified some share-code, geotiffwrite, to write the geotiff tiles; may still have some bugs).

2) Validate and calibrate the channel network through comparison to networks generated by other methods (manual and automatic) and to ortho-photos of the watershed.  Both GeoNet and my production code have a number of input parameters (all kept at default settings in the above analysis), and my preliminary investigations into the sensitivity of the channel network to changes in these parameters suggest that there is a lot of room for optimization.

3) Further improve the connecting-channel logic – the subset DEM used for development still had one location where the logic produced an unnecessary connection channel (this location has overlapping independent channels on the stitching boundary), and there are areas where unnatural stream loops are created.

4) The final step required to create a channel network most useful for further geoprocessing requires that the connection channels and the tile channels be merged into a single network of poly lines that properly conforms to sub-watershed regions.  This may require “smart” tiling, with considerably more overlap (and processing time) than used by the current production method.

ASPRS 2011 Roundup

If there was one theme from this year's ASRPS 2011 conference it was death by PowerPoint.  I'm no Steve Jobs when it comes to presentations, but I know enough to not make it miserable for the audience.  The graduate students in my GIS Practicum class deliver far superior presentations than many of the seasoned faculty at ASPRS 2011.  Slides with endless bullet points, more formulas on a single slide than a person could read in 20 minutes, tiny graphics, the list goes on.  This would be bad enough, but for a geospatial society you would think members would realize the value of a good picture.  Compared to the quality of the presentations at the urban forestry conferences I have been going to, the ASPRS sessions were, for the most part, a massive disappointment.

That being said there were a number of top-notch presentations.  I particularly enjoyed the session I moderated on "using multiple data sources."  Tommy Jordan and his team at CRMS are doing fantastic work training the next generation of geospatial professionals by integrating undergraduate students into the production workflow for a recent LiDAR and imagery collect.  Although the sensors and techniques we used are wildly different, I learned a lot from Ken Stumpf's work on land cover mapping in Alaska.  Ken is with Geographic Resource Solutions.  I am glad I stuck around for the final LiDAR session as two grad students, Colin Gleason from SUNY ESF, and David Kelbe from RIT, gave presentations that were filled with useful information and fantastic graphics.  I attended the AmericaView session, and although I had seen much of the work before it was still inspiring.

Paul Ramsey gave a brilliant opening keynote on open source software.  He did not pull any punches in going after Esri et al.  I think all of us left his presentation questioning why we ever purchased commercial software.  The problem with open source - they don't have the money to sponsor conferences like ASPRS.

Episode 4 of the Geospatial Revolution project premiered on day 1.  Impressive is an understatement.  It left me proud to be part of this profession and yet humbled by the great things others are doing.  The theme of the conference was "Ride of the Geospatial Revolution," but I cannot help if ASPRS might soon find itself drowning in the location-based geospatial tidal wave.  The largest booth in the exhibitor was Microsoft.  That's right, the same people that sell Office were showing off their remote sensing capabilities.  Who would have predicted that five years ago?  I can't help but wonder what will happen to all of these companies whose business model is to sell imagery.  Why, in these difficult economic times would an organization pay vast sums of money when Microsoft or Google will provide them with the data for free or at a much lower cost.  No doubt there will always be the need for mapping companies, but the Bing Maps Global Ortho Project is going to change the remote sensing landscape.

Although the presentations were largely a let down I thoroughly enjoyed the Hot Topics session on the challenges involved in breaking the 85% accuracy barrier.  Joe Knight from UMN was an amazing moderator.  Chuck Olson, a man whose work on the elements of image interpretation serves as the basis for everything we do was in attendance.  He offers a fantastic perspective from decades of experience, but it was disappointing to hear him say that all automated techniques rely solely on spectral information.  WRONG, WRONG, WRONG.  More than a few folks, us included, are using object-based approaches to incorporate spectral and spatial information into an automated process.    Just check out Infoterra's work for proof.

Although Paul Ramsey's talk made me want to check out PostGIS, the proprietary vendors are doing some awesome work.  I got a preview of the enhancements coming in the next release of eCognition.  Amazing!  The transition to Trimble has not slowed things down one bit and eCognition continues to redefine what is possible in terms of image analysis.  Had some great conversations with teams from MDA, Trimble Geospatial, and ERDAS.

Keith Pelletier and I ran an Object-Based Image Analysis workshop on Monday.  Over 30 people attended, and it was a lot of fun.  I learned a lot from their questions and I hope they learned a lot too.  Thanks to all of you who attended.  I hope you will stay in touch.

You can check out all of the Tweets from ASPRS 2011 at #asprs11a.  A lot of the tweets are me complaining about the presentation, sorry, but someone has to speak up.

Will I go next year - maybe.  ASPRS really needs to post some guidelines to the presenters or better yet, make them all watch Death by PowerPoint the night before.  Scientific presentations can be enjoyable.