The Rural Technology Initiative ceased operations in 2011. This site is maintained as an archive of works from RTI collaborators from 2000 to 2011 and is no longer updated.
Luke W. Rogers
University of Washington
Automating Contour-Based Route Projection for
Luke W. Rogers
Chair of the Supervisory Committee:
By evaluating alternative routes in the office using a pegging
routine, days or even weeks can be saved of valuable field time
and ultimately, a better design can emerge. Initial road design
in forested landscapes often includes pegging roads on large-scale
contour maps with dividers and an engineer’s scale. An automated
GIS based road-pegging tool (PEGGER) was developed to assist in
initial road planning by automating the road pegging process. PEGGER
is an extension for the commonly available GIS software ArcView®.
PEGGER imports topography as digital contours. The user identifies
the origin of the new road, clicks in the direction they want to
go and PEGGER automatically pegs in road at a specified grade.
Through the use of PEGGER, many alternatives can be quickly analyzed
for alignment, slope stability, grades and construction cost using
standard GIS functionality. The resulting cuts and fills are then
displayed in ROADVIEW, a road visualization package for ArcView®.
This paper looks at the algorithm used, evaluates it’s usefulness
in an operations planning environment and suggests additional methods
which might be incorporated into PEGGER to further assist the forest
As an undergraduate forest engineering student at the University of Washington I had the opportunity to spend two summers working for Washington’s largest forest products company. At Weyerhaeuser, I was impressed by the scale and depth of their geographic information system, but perplexed as to why the field foresters and engineers had relatively little access to these tools. Any request for information from the GIS specialists came back as hard-copy maps, even though the Company was willing to install desktop GIS software on the engineers’ computers.
In my training as a forest engineer I learned how valuable tools like geographic information systems could be in guiding management decisions. I was exposed to many tools including clinometers, relaskopes, laser range-finders, geographic information systems, optimization programs, and much more. I soon became very interested in how all of these tools could work together to provide more informed decisions about how to better manage the forest and the necessary systems that support forest management.
It was while working for those two summers that I realized there was a large disconnect between university research tools, optimization routines, and the needs of the field forester. This could not have been more apparent than in the manner in which roads were initially designed and subsequently located in the field. Typically, the engineer would look at a 1:4800 scale map (printed from a GIS), briefly glance at a stereo photo set, and then head to the field to locate a route in a trial and error method. While these engineers were very good at doing this, based on their many years of experience, I though there might be a better way. I thought it would be valuable to take advantage of desktop GIS software and provide some simple tools to help the forest engineer with initial route location. With that concept in mind, and a generous funding offer from the newly created UW Rural Technology Initiative, I started a masters program to design a tool that I would call PEGGER
I would like to acknowledge Bruce Lippke and Larry Mason at the Rural Technology Initiative for their support of my work in designing PEGGER. The funding of my masters work through the Rural Technology Initiative encouraged me to design software that could be used by family forest land owners and their consultants. Creating complex tools with intuitive user-interfaces that can be used with little or no training is quite challenging. Far too often, University researchers forget the potential patrons of their research and create monstrous programs that rarely get used after their departure. So, I would like to thank the folks at RTI, and individuals like those at Google, for demonstrating that University research can be transformed into easy-to-use products.
I would also like to acknowledge the dedication and hard working nature of both my masters committee chair Peter Schiess and my GIS mentor, Phil Hurvitz. Both of these gentlemen gave their time and knowledge freely to me over the years. I recall many late nights at Pack Forest and many long hours in the office working though both engineering and GIS challenges. It is the combination of these two guys experience and their willingness to share it that led me to design PEGGER. Thank you both for your interest in my education.
Last, but certainly not least, I must thank my family for their support over the years. The financial support of my parents, Bill and Susie Rogers, and the emotional support of my wife Heather cannot be measured. It is one thing to commit your own time in pursuit of a goal, but to have others around you give their time on your behalf is quite another. Heather, this degree belongs to you as much as it does to me, thanks. I could not have done it without you!
I would like to dedicate this work to all of the wonderful men and women that work in forestry around the world. While there will always be controversy around the management of forests, it has become clear to me that the managers of those lands are the real environmentalists of the 21st century.
It can be assumed that since the dawn of forest management, forest road engineers have sought means to more efficiently analyze alternative road locations. Where survey teams once blanketed the forest landscape to locate prime route locations, are found only solitary forest engineers verifying and flagging their chosen road location. This shift in forest road design methodologies likely began with the first contour maps and continues to be transformed today by remote sensing technologies like Landsat and LiDAR and the proliferation of desktop Geographic Information System (GIS) products. It is now possible for a forester to analyze many different road location alternatives over a large geographic area in a minimal amount of time. Time consuming field work has been reduced to verification of the chosen alternative and marking it in the field.
This research looks at the differences in forest road planning techniques and the existing software products that have been developed to assist in forest road location. A computer program is presented that automates initial forest road location through the use of a Geographic Information System and digital terrain data. Using PEGGER, forest planners can quickly analyze many road location alternatives and, by taking advantage of standard GIS functionality, evaluate environmental and economic opportunities.
A companion program, ROADVIEW, has been developed to assist in communicating forest road design concepts to those outside of the forestry profession. Using ROADVIEW, forest planners can quickly show the topographic modifications of a planned forest road and evaluate visual impacts associated with alternative road locations.
There are three broad categories of planning in forest management, strategic, tactical and operational (Sedjo 1987; Kent, Bare et al. 1991; Schiess and O'Brien 1995; Boyland 2003). Information exchange between these three tiers of forest management planning is critical in developing a management plan. Strategic planning looks at large areas with aggregated data typically over long time horizons. A large forest products company may have one strategic plan for their entire forest land-base with the goal of providing consistent shareholder returns year after year. Calculating sustained yield occurs at the strategic planning level.
Tactical planning encompasses a diverse range of activities and geographic areas but generally is considered to be associated with a specific management block or ownership. Harvest targets are usually handed down from the strategic level to the tactical level without regard for the specifics of where the harvest volume will come from. It is the tactical plan that harbors more specific information on stand volumes, road systems, and management priorities.
Operational plans are derived from information handed down from the tactical level and then composed into the specific details of when, where, and how. The tactical plan may indicate that a stand is ready for harvest and it is the job of the operations planner to develop a specific harvest plan with road systems, harvest techniques, and conservation priorities.
At all three levels of the forest management decision making process forest road planning is required. At the strategic level, planners need to know roughly how much road will be constructed, maintained or abandoned each year for proper cost accounting and depreciation. At the tactical level, planners need to know if specific areas of the forest are reachable by road, which segments of road will need maintenance, where new roads will be constructed and how much it will cost. At the operational level, planners need spatially explicit information to properly build, maintain, or abandon roads and develop detailed plans that can be implemented by construction personnel, loggers, and foresters. Site specific information such as topographic constraints can affect tactical and strategic decisions.
The Importance of Road Design
Recognizing that office-designed preliminary route locations can save forest managers time and money and with the advent of computers, researchers and forest management consultants have produced myriad software packages to assist in the strategic, operational and tactical aspects of forest road planning.
The Importance of Visualization
Given the increased level of public scrutiny associated with timber resource management in recent years, visualization tools are becoming invaluable in communicating forest operations design to the laity. Any road design tool to be developed must include a visualization component to communicate a proposed route location and analyze the aesthetic impact associated with its construction. The availability of free visualization tools like EnVision (McGaughey 2000) and forest management tools like the Landscape Management System (McCarter 2001) that integrate well with each other make it practical to develop a road design tool that can complement those existing products.
Existing Road Design Models
There are very few strategic forest road planning tools. However, the Forest Service developed the linear programming model FORPLAN (1985) to address the multiple use problem on the Nation’s Federal lands. While FORPLAN was useful for analyzing broad National scale issues, it did not address roads directly and a critical evaluation by Kent et al. (1991) recommended that FORPLAN be redesigned or replaced by “smaller, hierarchically-based, easier-to-interpret models.” Anderson and Nelson (2004)have created a vector-based road network model that is “specifically concerned with creating road networks that are suitable for strategic planning.” They state in their work that an operational plan must be devised (from the strategic plan) and validated before any forest road is approved for construction. A model developed in Chile called PLANEX is able to strategically plan landing locations, harvest settings and access routes on areas as large as ten thousand hectares relying on coarse raster data to locate the transportation network (Epstein, Sessions et al. 2001).
At the tactical level, most existing models are focused around optimization of harvest scheduling and road networks including SNAP (Sessions and Sessions 1988; Sessions and Sessions 1992), NETWORK (Sessions 1987), and the University of Washington Timber Harvest Planning System (UWTHPS) (Schiess and O'Brien 1995). These models are complex and typically unused by the majority of forest operations planners. The necessary datasets, lack of site-specific control, and time required to setup these systems has left them without many users.
At the operational level many road design packages have been developed likely starting in the early 1970’s with programs that ran only on mainframe computers and had no user interface (Kobayashi 1973). In 1974 what is thought to be the first forest road design software program for the “modern desk-top calculator” was introduced (Burke 1974). An attached digitizer was used to input topographic information into the program which was then processed by analytical routines. The results were then displayed on a plotter for evaluation and adjustment in an iterative process.
Since 1974 many others have introduced road design software packages for the desktop computer. Of these road design packages (RoadEng, AutoCAD, ROADPAC, F.L.R.D.S., TRACER, ROUTES…) only one has given the user the ability to quickly look at alternative road locations at varying scales, ROUTES (Reutebuch 1988). Traditional road design software relies on survey data collected in the field to generate terrain models and very detailed engineered road location and construction plans. Others have taken a more holistic approach and looked at optimization of road locations for a particular set of topographical, environmental or economical constraints (Thompson 1988; Cha, Nako et al. 1991; Xu 1996). All these programs have relied on a high degree of training on the part of the user and few of the non-commercial packages have matured into an easy to use software package.
ROUTES was developed to automate the road pegging process. Using a large-scale contour map (1in = 400ft) and a digitizer, the user could digitize the contours and create a gridded Digital Terrain Model (DTM). The operator could then use the digitizer puck to locate the road using the registered, printed contour map as a giude. While the user interface was primitive consisting of high and low pitch beeps from the digitizer puck to signal that the user was “on-grade”, the program worked well and kept track of such things as grade, road length and stationing. ROUTES reliance on a digitizer, its HP 9000 code base and its primitive digitizer based graphical user interface (GUI) left the program without many users.
TRACER is a PC-based stand-alone program for locating forest roads. TRACER takes a linear programming and heuristic approach to locate a vertical alignment with the lowest total costs while conforming to environmental constraints (Akay, Karas et al. 2004). While TRACER is an excellent tool for analyzing many alternatives it does have its limitations. TRACER took 15 minutes to complete an analysis on 55 hectares. It did produce a solution with a 25% cost reduction over another chosen feasible route but may bee too “black box” for many forest managers. Reisinger and Davis (1985) suggest in reference to forest planning software that “while these models are often mathematically elegant from a research standpoint, forest industry managers find them operationally unworkable.” Finding the balance between optimal and workable appears to be the challenge facing software authors.
Both TRACER and ROUTES are useful tools, however as clearly identified by Dürrstein (1992) all road design software packages must include several key components to be most efficient for the end user. According to Durrestein: “Summarizing the existing experiences and demands of the user, computer-aided detailed road planning [software] must fulfill the following conditions:
It may be more appropriate to identify opportunities to integrate the forest managers experience into forest road planning software rather than attempt to find optimal solutions with “black box” models. Watson and Hill (1983) define a Decision Support System (DSS) as an “interactive system that provides the user with easy access to decision models and data in order to support semi-structured and unstructured decision-making tasks” and suggest that a DSS is essentially an analytic tool to improve the effectiveness in making decisions where the manager’s judgment is still essential. Reisinger further states that “the key to successful implementation of a DSS lies in creating a user-friendly environment in which a manager/planner can interactively obtain answers to practical questions about the large-scale, complex operations they manage.” Thompson (1988) states in reference to his own road spacing model that “the model should be viewed as a tool used to enhance good judgment.”
Existing Forest Visualization Software
In the early 1970’s, around the same time as the first route projection routines were being programmed into mainframe computers, three-dimensional visualization routines were developed. These early 3D perspective terrain tools were primitive, slow, and ran on mainframe computers (for a more detailed discussion of forest visualization software see McGaughey and Twito 1988). It probably wasn’t until the introduction of the PC-based Preliminary Logging and Analysis System and its VISUAL and SLOPE components in the late 1980’s that visualization became accessible to the forestry community.
Currently, there are a few visualization packages including EnVision, the Stand Visualization System (SVS), the World Construction Set, Visual Nature Studio (VNS), SmartForest, Virtual Forest, and most geographic information systems. Of these packages only EnVision (McGaughey 2000) allows for the landscape wide integration of forest stand data into the visualization, runs on a PC, and is available free of charge.
The primary objective of this work is to create a preliminary road design tool that forest operations professionals will use on a regular basis to supplement their existing toolkit of aerial photography, paper based maps, clinometers, compasses, geographic information systems and global positioning (GPS) units. This tool must integrate into existing desktop software products, incorporate the knowledge of the road engineer, have a simple user interface, take little or no training to operate, and be simple and easy to use. The tool must be interactive and empower the road engineer with transparent software logic rather than over-power them with “black box” optimization technologies. The success of a road design tool should not only be measured by the optimization of a particular set of criteria or the cost savings associated with a particular design solution, but by the number of individuals and organizations using the software.
Automate Manual Processes
Forest engineers increasingly have more access to desktop GIS software. One of the many useful things about GIS and software in general is its ability to automate simple and complex tasks. Identifying opportunities to automate manual processes in the forest road design process, while incorporating the engineers knowledge, may hold the most promise for a useful tool. Many engineers utilize aerial photography and route projection on a paper map (or pegging) to identify initial route locations. This process is largely repetitive and time consuming and can be efficiently automated within a geographic information system.
Route Projection” or “Pegging”
Utilizing contour maps, engineers can quickly evaluate multiple route locations in the office and then focus their field work within those areas. In combination with aerial photography, this trial and error method of initial paper based road location has proven itself as a cost effective method for preliminary design and analysis by avoiding expansive field investigations.
Utilize High-Resolution Topographic Models
Digital elevation models can also be stored as contour lines in the GIS. While there is no cell size associated with line features in a GIS, there is the concept of a reference scale. USGS digital elevation models are generated from the 1:24,000 topographic quad sheets that were photogrammetrically derived. Carson and Reutebuch (1997) have shown the limits of using USGS DEM’s for forest operations planning. The Washington State Department of Natural Resources has developed contour data products from aerial photography at a scale of 1:4800. It has been shown that those maps were a significant improvement over the USGS product, particularly for forest road location and skyline profile analysis (Schiess and Rogers 1999; Schiess and Rogers 2000; Schiess and Arntzen 2001; Krogstad and Schiess 2004).
While USGS 10 meter digital elevation products and 1:24,000 contours are limited in their use for forest operations planning, Light Detection and Ranging or LiDAR is being recognized as a reliable data source for high-resolution elevation models. Referring to a digital elevation model with a RMSE of 29 cm Pereira (1999) stated that “a [digital elevation model] derived from laser measurements with an average density of 4 points per m2 has sufficient quality to represent the terrain relief for the purpose of road planning and design.” Forest cover plays a large role in the accuracy of LiDAR generated elevation models. It has been shown however, even under the densest forest canopies that mean errors are less than 0.5 meters (Reutebuch, McGaughey et al. 2003).
In the forest industry and academic institutions LiDAR has been used to test its applicability for aiding forest road design. Some work done on Capitol State Forest in Washington has validated that LiDAR is appropriate for forest road design and can be used to accurately calculate earthwork (Coulter, Chung et al. 2001). Reutebuch states that in general, the LiDAR DTM was found to be extremely accurate and potentially very useful in forestry (Reutebuch, McGaughey et al. 2003).
LiDAR is one of the fastest growing remote sensing technologies with many different platforms, formats, data products and uses. It is expected that the accuracy of LiDAR generated topographic products will only increase as its use becomes more widespread.
It was recognized early in the design process that integrating a road design product into an existing software package could be beneficial to both the developer and the users. Utilizing standard functions built into all commercial GIS products as the backbone of a road design tool would allow the developer to focus on the functionality of the tool itself and not the creation of the application necessary to support it. For this reason, it was decided that the tool should be designed as an extension to an existing off-the-shelf GIS software package. The existing GIS software should be relatively inexpensive and available across multiple platforms for maximum success.
As suggested by Dürrstein (1992), Schiess (1995), and others, forestry tools should be modular in their design and behave as individual tools in a toolkit so that the experienced forestry professional can select the appropriate device for their particular needs. From a functionality standpoint this means that any tool should be able to communicate well with existing and future tools. Implementing a forest road design tool within a GIS framework ensures that this condition is met as a GIS is designed as a tool for the import, manipulation, display, and export of myriad data formats.
With the importance of visualizations in the communication of forest management plans to the public, it is sensible to enable any new forest road design tool to take advantage of the existing forest visualization tools that are available. The concept then should be to locate a road using the GIS based tool, and then virtually construct that road into the topographic model. The new topographic model can then be visualized in any of the existing forestry visualization software packages or within the GIS itself.
ArcView GIS provides the Avenue programming language to write add-ons and scripts which can be packaged and installed as extensions. An extension written for ArcView using the Avenue programming language can be used on any platform that ArcView runs on. ArcView 3 products run on Microsoft Windows, Sun Solaris, SGI IRIX, Macintosh, IBM AIX, HP-UX and Compaq/Digital Tru64 UNIX. Taking advantage of the write once, run anywhere functionality of ArcView and the Avenue programming language is an attractive feature of writing an ArcView Extension.
With ArcView it is easy to integrate custom content into the help system to make a professional product which seamlessly integrates with ArcView. Seamless integration into the existing help system of ArcView means that if a user knows how to use ArcView they will be able to use an ArcView extension. Another reason to use ArcView and build this as and extension to ArcView rather than as a stand alone product was to take advantage of the data management and display functionality that is designed into any GIS. It also allows for the integration of other tools and datasets inherently. This allowed for more design time to be spent on ease of use and functionality rather than designing a new piece of software from scratch.
PEGGER is an ArcView GIS extension that automates the route projection (“road pegging”) process for use by engineers and forest planners. One of the goals of the PEGGER project was to make the program as usable as possible for as many people as practical. One of the problems with technology is training users to use the software. Forestry professionals responsible for fieldwork have been slow to adopt new technology into their work largely due to the complexity of the software and the time commitment of training. The PEGGER program was designed to avoid these common pitfalls, requiring no training, minimal setup time and a simplified user interface. Included with the software are detailed and seamlessly integrated help files and a complete tutorial with sample datasets.
PEGGER imports topography as digital contours much like using a paper contour map. Standard tools available within ArcView GIS allow the user to import the contours from Shapefiles, ESRI coverages, AutoCAD dwg and dxf, and Microstation dgn files. In addition to importing data as digital contours, users can use the ArcView Spatial Analyst extension or other publicly available tools to convert USGS digital elevation models or LiDAR elevation models to contours. Contours were chosen as the preferred method of storing topographic surface information primarily because in using a vector based dataset, the user was not required to have either the ArcView Spatial Analyst or 3D Analyst Extensions. In addition, every attempt was made to automate the paper-based route projection process and avoid the perception of a black box technology. By simply automating a manual routine, it is possible that forest engineers and planners will have more confidence in their results.
Once digital contours have been imported into ArcView the user must supply a few parameters, the road theme they would like to edit, the contour theme they would like to use as well as confirm the detected contour interval (Figure 3). In addition to the contour and road themes the user can have any number of other layers available in the GIS such as soils, slope classes, streams, wetlands, unstable slopes and property lines. Optionally, the user can maintain attribute information about the grade of the pegged segment and a road name.
The next step is to locate the desired beginning and/or endpoints of the new road given operational parameters. Using standard tools available in the GIS (ruler and identify) the user can estimate the necessary grade for the road. To start a road the user shift-clicks on the location where they wish to begin and enters the desired grade. To “peg” the road the user only has to click in the general direction they wish to go in order to project the route into the GIS. Successive clicks peg in additional segments of road from contour to contour as fast as the user can press the mouse buttons. Grade changes can be accomplished by using the Roads pull-down menu, using the PEGGER toolbar (Figure 4) or by right clicking the mouse and selecting Increase or Decrease Grade.
If the road fails to reach the desired end point, the previously pegged segments can be quickly deleted and a new grade can be tried. This method of trial and error that used to mean changing the divider spacing and erasing undesirable segments from the map can now be accomplished in the GIS in a fraction of the time.
d = ci / (g / 100)
where d = the distance,
NOTE: For pegging on paper maps, the distance would need to be multiplied by the map scale (ie: 1/4800) to get the appropriate divider width.
If a point is found, a new route segment is created in the GIS (Figure 6). If a point is not found, the user is notified that the desired grade is not feasible and potential solutions are proposed. Unlike ROUTES, which allowed for a grade tolerance (+/- some tol), PEGGER gives an exact solution in the GIS.
After a desirable route location has been found the user can merge the segments into one long road, dissolve adjacent segments based on a common attribute or spline to smooth sharp corners (much like a finalized design). An attempt was made to produce tangents and curves from the initial design but ArcView’s lack of a true curve feature type made the possibility impractical.
PEGGER is designed as a tool to quickly evaluate many alternative routes. PEGGER was not designed to optimize or even suggest optimal route locations. However, it has been shown that once a route location has been chosen RoadEng can be used to produce an optimal design (Heralt 2002). RoadEng can produce a final road design that considers earth work, horizontal alignment, vertical alignment, super-elevation, and materials. By quickly pegging multiple routes and analyzing them in RoadEng (Figure 9), a preferred alternative can be selected based on environmental, economic, or visual concerns.
Currently, ROADVIEW does not adjust the road location or vertical alignment to balance cuts and fills or construct a full-bench segment. ROADVIEW simply visualizes the road as if it were built exactly as represented in the GIS. While the method is fairly crude, it quickly gives the user an idea of how a particular road will look when constructed. Any future work on ROADVIEW should attempt to visualize roads based on templates for balanced cut/fill and full-bench sections in different side-slope conditions.
Ease of Use
Applications to Management
Another application of PEGGER is the ability to create field maps once a route has been chosen. PEGGER keeps track of grade information as a road is pegged. Using the dissolve feature of PEGGER along with the grade information, adjacent segments of pegged road can be dissolved together to create lengths of road that have the same grade. Pegged roads can then be printed on a contour map with grade and length information as shown in Figure 12.
The advantage of using maps like the one above are that the only tool needed to locate the PEGGER designed road is a clinometer. Reading the grade and distances off of the map, roads can be flagged in by simply starting at a known point and pacing the required distance at the indicated grade. Placing flagging along the way, a single person can locate many miles of road in a single day. This method has been used by the University of Washington Forest Engineering Capstone students very successfully over the past few years and is considered to be their preferred method for forest road grade-line location.
High-resolution LIDAR datasets can also be problematic. Contours generated from high-density LIDAR can be very “rough” or “noisy”. While this may accurately represent the ground surface, it can be too detailed and confuse PEGGER. Small rocks, bushes and stumps can appear in the contour data and provide misleading information to the PEGGER algorithm. To mitigate this effect, very high resolution LIDAR contours should be smoothed in the GIS or elsewhere before use with PEGGER.
The PEGGER program is a tool for quickly identifying possible route location alternatives given grades specified by the user. The tool does not evaluate additional environmental and economic constraints that must be considered by the forest professional such as soil types, hydrology, property lines and slope classes. The GIS provides a framework where these analyses can be implemented but it is outside the scope of the PEGGER program.
The algorithm that PEGGER uses to identify a segment is dependant on the contour interval of the dataset, and the desired grade of the road. At steeper grades, this works very well as pegged segments are short. However, as the grade of interest decreases, as shown in Figure 13, PEGGER must make the pegged segments longer and longer. At a 1% grade on a 20 foot contour interval dataset, the segment length becomes 2000 feet. At such long segment lengths, the topography is not being accurately represented. Therefore, at shallow grades, it is necessary for the engineer to use standard GIS functionality to locate roads manually and only rely on pegged segments as a guide for freehand placement of a preliminary route location.
Users must also be careful crossing incised stream valleys (or draws) when using PEGGER. Figure 15 demonstrates the problems than can be encountered when using PEGGER in steep mountainous terrain where incised stream valleys are common. The straight red segments were placed using PEGGER with a -5% grade. These segments, because of the long segment length, skip over the topography of the incised stream. At the highest point, the road is over 100 feet above the stream! In reality, this road would be built more like the curvy green segments that more closely follow the topography of the stream valleys. The road that was initially pegged at -5% grade when built would come out to something more like -3.7%. This difference in grade can be considerable depending on site specific conditions. The effect of having a more relaxed grade in complex topographic situations can be appropriate however. Pearce (1960) suggests relaxing grade the grade in the field when locating grade lines across draws. While it may be appropriate in this situation for a more relaxed grade through the turns, if the grade were critical it would be important to look out for these circumstances.
To mitigate these effects, a 5 or even 2 foot contour interval should be used. These smaller contour intervals help to alleviate the problems with valleys and ridges and provide a much more realistic road alignment of the pegged road. While the traditional 20 foot contours can still be displayed in the GIS, the smaller contour interval data can be used for pegging.
While computerized route location has been used by forest professionals for many years, it has never become a widely used technology to evaluate initial road locations. With PEGGER, the forest planner can quickly evaluate route locations within a GIS framework, giving the planner access to additional GIS functionality. PEGGER was designed with simplicity and minimal investment cost as primary objectives. Through the use of a carefully designed user interface and extensive tutorial, a typical user can be locating roads in a few minutes on their own PC taking full advantage of forest technology. The automation, rather than optimization, of route location gives the forest planner more confidence in their designs since it incorporates their knowledge in the process.
In the past few years, this tool has been downloaded (and hopefully well used) by hundreds of forestry professionals from all over the world. As shown by the number of downloads of the product, and the responses received from users, PEGGER is another valuable tool that forest planners can add to their toolbox.