USDA Forest Service
ArcGIS Implementation Guide
August 2003
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 1
Background
Marketing surveys have revealed that 75-85% of the business that government entities conduct is related
to ―where‖ things are on the landscape… land parcels, animal populations, habitat, streams, roads, water
mains, power lines, buildings, etc. The Forest Service (FS) is no exception to this observation.
Geographic Information Systems (GIS) constitute the computerized ―tools‖ that have been developed to
manage information about where things are in relation to one another and their unique attributes
(characteristics). From an ―evolutionary‖ standpoint GIS technologies are at a ―late childhood‖ stage of
maturation and, similar to a young child, continue to undergo rapid and dramatic development.
ArcGIS delivers ―industrial strength‖ functionality the agency needs to fulfill internal as well as
government-wide information management mandates of the 21st century. From a physical standpoint,
larger/faster database servers, faster Local Area Networks (LAN), more powerful desktop machines on
more desktops, and more robust telecommunication connections between FS offices are all needed. In
addition, there is much more to know and understand, new skills and roles to develop among a more
diverse spectrum of FS employees, more data standardization to define and achieve, and new data
models to migrate into.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 2
Executive Summary
This Guide is intended to provide a strategic awareness and outline of the considerations and steps
necessary to successfully implement the capabilities that ArcGIS offers. It is also intended to inform
line officers, staff, and resource managers of the technology migration issues confronting our agency as
we migrate from ArcInfo and ArcView to ArcGIS.
The Geospatial Advisory Committee (GAC) sponsored the development of this Guide for
implementation of ArcGIS in the USDA Forest Service (FS). In March of 2003, a cross-section of GIS
and database management personnel from across the agency began drafting an ―ArcGIS Implementation
Guide‖ to provide strategic guidance and a framework within which the Washington Office (WO),
Regional Offices (ROs), and Forests can begin effectively operating to assure the greatest likelihood of
successful migration to this new technology. Twenty-two persons attended the workshop, representing
Regions/Forests, Washington Office (WO)-IRM, Research, Forest Service Natural Resource
Applications (FSNRA)1, GSTC, and the Remote Sensing Application Center (RSAC). This Guide is
being developed within the larger context of FS Information Technology and Geospatial Planning
activities including the FS Enterprise Architecture and the FS Geospatial Strategy.
ArcInfo and ArcView are commercially-developed GIS software products that the FS and many other
federal, state, local, private and international organizations have been using as their primary tools for
managing geospatial information. Recently ArcInfo and ArcView have been re-engineered and
incorporated into a new, highly integrated family of products called ArcGIS. This represents a major
advance in the development and application of GIS technology. ArcGIS introduces significant changes
that include:
A new data model
A new software interface
Enhanced analytic functionality and architecture
Sophisticated new ―tools‖ and methods for managing large geospatial data assets distributed across
many computers separated by vast distances and joined via inter- and intranet connections.
So what does this mean to line officers and program managers? Many employees will require additional
training; re-alignments of staff many be necessary to fulfill new roles and responsibilities; and it will be
more important to consider the GIS technical skills that new-hire employees bring with them. IRM
staffs will become more crucial in supporting larger more sophisticated systems and become active
participants in information delivery. Resource managers will become more engaged in data
custodianship and definition of protocols and standards. Benefits will include more consistent data that
will be readily available to a broader spectrum of users for use in very robust analytic tools supporting
sound decision-making and effective monitoring. Due to the integrated nature of ArcGIS within the
geospatial community and the value of GIS in resource management, line officers will play a vital role
in facilitating the ArcGIS implementation and will be able to expand on this guide to make it relevant to
the needs of their unit.
1
FSNRA = ALP/NILS, Infra, NRIS, FACTS, Fire Applications
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 3
Introduction
2
The ArcGIS system is an integrated Geographic Information System (GIS) consisting of three key
parts:
ArcGIS Desktop software, an integrated suite of advanced GIS applications
Arc Spatial Data Engine (ArcSDE) gateway, an interface for managing geodatabases in a
database management system.
Arc Internet Map Server (ArcIMS) software, Internet-based GIS for distributing data and
services.
ArcGIS can be extended with additional software such as ArcPad for Windows CE devices.
ArcGIS offers significantly improved and expanded ―large enterprise‖ functionality and supports
implementations of both ―file-based‖ models (e.g., coverages, shapefiles, grids, TIF images, and TINs)
and next generation ―geodatabase‖ models where geographic information is stored in true database
management systems (DBMS). Because the geodatabase manages spatial data in a DBMS, new and
more robust modeling capabilities are available to support 3-dimensional coordinates, complex
networks, true curves, relationships among feature classes, planar topology, and other object-oriented
features. Raster types in the geodatabase provide one common unified means for managing all raster
data formats (such as multiband images, grids, and compressed raster formats). Additionally, more
security and integrity controls can be placed on data stored in geodatabases using DBMS controls,
facilitating ―concurrent‖, ―long‖, and ―detached‖ editing transactions against one master data set.
Many of the information management solutions the FS envisions are dependent on a thorough ArcSDE
implementation serving as a foundation technology supporting many other ESRI technology initiatives.
Nearly all the ―enterprise benefits‖ we expect to reap from ArcGIS will only be realized if ArcSDE is
fully and robustly implemented first.
The attached Appendices contain the detailed information Regions and Stations can reference as they
develop ArcGIS Implementation Plans relevant to their units.
Appendix A is a list of issues categorized by Data, People, and Technology. The organizational
levels within the agency that will be responsible for taking the lead on each issue are identified.
Appendix B is workshop attendance.
Appendix C is a glossary of ArcGIS terms taken from ESRI documentation.
Appendix D is a list of references used in developing this Guide.
2
ESRI. 2001. What is ArcGIS? – GIS by ESRI. Environmental Systems Research Institute, Inc., Redlands, CA.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 4
Goals
Successful implementation of the new geospatial data model that ArcGIS offers will enable the Forest
Service to:
Identify training needs to improve the GIS and database skills of end-users.
Identify the appropriate level of Oracle DBA support.
Identify re-alignment of staffs.
Consider the GIS technical skills that new-hire employees bring.
Assure critical IRM support for larger, more sophisticated systems and information delivery.
Assure resource manager are fully engaged in data custodianship and definition of standards and
protocols.
Cultivate partnerships.
Improve ease of use to the end-user community.
Provide a fully integrated geospatial environment to the end-user community.
Provide sufficient data to a very diverse community of end-users interested in sound
management of public lands.
Keep up with evolving geospatial and information management technologies
Contribute data and information supportive of Homeland Security needs.
Provide a consistent look, feel, and content to data collected in support of resource management
on National Forest lands.
Identify interdependencies between data, software, and hardware requirements.
Identify ways to improve communication within the GIS community.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 5
Work Group Results
Major ArcGIS implementation issues were categorized into three main groups; data, people, and
technology, based on the goals and objectives that guided the working group. Each category is meant to
frame a set of issues that need to be addressed at various levels of the agency and over a variety of
timeframes. Following are general descriptions of the categories. For a detailed summary of identified
issues, by category, see Appendix A.
Data: Data powers the information management engine in the Forest Service. Where data come
from, how they are maintained, and how they will evolve in the future are all interrelated issues to be
addressed. ArcGIS plays a critical role in dealing with FS spatial data; however, the enterprise
nature of ArcGIS unlocks new data management opportunities that did not exist in the recent past.
How best to take advantage of these new opportunities in a coordinated, integrated, and organized
way is the main focus of this category.
People: As we place additional pressures and demands on our workforce it becomes increasingly
important that we become more efficient with the timing of our training, more aggressive with the
development of a higher level of expertise, and more engaged in proper information management
and oversight in order to implement our information management strategy successfully. People are
the driving force that activates the full potential of the data and the technology to which we have
access. We have made substantial investments in our corporate systems and resource users are just
now becoming familiar with the current applications. It will take time to re-tool these applications
and get users comfortable with using them in the new environment, so we need to acknowledge the
time and costs to support dual systems for a certain length of time.
Technology: Efficiency and functionality of the overall technology environment in the FS have
progressed very rapidly in the last few years. Indeed, our technological capabilities are beginning to
outpace our ability to integrate new technologies in an enterprise fashion. Our ability to consistently
take advantage of these advancements has been lacking, or at best, not coordinated. Do we use a
drive-train from a Model-T that we can‘t get parts for, or do we use something being manufactured
today that is fully supported and integrated with the rest of our car? We don‘t necessarily want to be
on the ―cutting edge‖ of technology, but we do need to become more nimble at adopting and
integrating proven information management methods and efficiently applying technology in an
organized way to help the entire organization.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 6
Technology Impacts and Direction
Table 1 provides a timeline that, as of March 2003, categorizes FS software, hardware, data, and by
inference, training into one of five broad ―technology phases‖ relative to technology adoption by an
organization. These five phases are defined as:
1. Point Solutions: Intended as controlled prototype solutions to investigate feasibility for broader,
enterprise, adoption and implementation or for limited operational use to address very specific needs
or unique problems. Significant potentials often exist and synergistic opportunities are often
abundant but un-investigated.
2. Next Releases: Usually after a point solution has proven its utility and integratability to an
organization‘s technological solution it becomes formally adopted and scheduled for general release.
The ―next release‖ status of a solution indicates that rigorous and formal testing and evaluation is on
going, OSTIBs and DOG supplements are being written, and other hardware and/or software
prerequisites being identified. Training needs are identified. If applicable, initial development is
underway.
3. Existing Standard: Used throughout an organization on an operational basis. Mature applications.
Training needs tend to be modest. Investments in existing standard technology are most likely to
provide worthwhile payoffs.
4. Sunset: The technology has other, more capable, economical, functional replacement candidates
emerging and being tested as ―point solutions‖. While still being used operationally, the promise of
various emerging technologies being evaluated as point solutions strongly indicates that a
replacement will soon be at hand. Investments in sun-setting technologies should be very carefully
reviewed because worthwhile payoffs are generally unlikely and could maybe be better spent
preparing for ―next releases‖.
5. Retirement: Not shown in the table. The DG and ―ApplixWare‖ are examples of two ―retired‖
technologies.
The date column following each stage column is a rough estimate made by the workgroup of when the
technology reaches that life period.
NOTICE!!! CAUTION!!! Dates indicated in this table are subject to change. Indeed, many dates are
missing. The dates represent the workgroup’s opinions (not policy) as of March 2003 and are included
here as an example of the “scheduling/sequencing/dependencies” issues that should be considered as
technologies surrounding ArcGIS are implemented.
When populated with agreed upon dates, this table would provide a useful matrix for guiding ArcGIS
implementation and could be applied nationally, regionally, or locally to indicate possible future impacts
(costs/training/organization) to staff. It will also serve to illustrate relationships between the ―current‖
FS geospatial environment (point solutions and existing standard), ―emerging‖ environments (next
releases), and ―declining‖ environments (sunset).
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 7
Table 1. Rough draft matrix indicating relationships among emerging, existing, and declining software, hardware and data technologies.
Basically, as ―new environments‖ come on-line, data and workflows will need to be migrated from the ―old environments‖ so they
can be retired. A data set or workflow should span no more than three environments and ideally only two.
Date4 Date Date5 Date
Sunset3 Existing Standard Next Releases Point Solutions6
yyyy mm yyyy mm yyyy mm yyyy mm
SOFTWARE
Oracle 8i 2004 04 Oracle 2004 04 Oracle 9i 2004 01
Oracle 9iAS 2003 03
ArcGIS 8.1.2 2003 09 ArcGIS 8.1.2 2003 09 ArcGIS 8.3 2003 08
AIX 5.1 2003 08
ArcGIS 9.0 2003 11
Arc Librarian 2003 03
ArcSDE 8.1.2 2003 09 ArcSDE 8.1.2 2003 09 ArcSDE 8.3 2003 06
ArcIMS 4.01
AML ESRI VB 6.0 Geospatial Development Tools 2003 06
Based Date
Avenue 2003 03
ArcView 3.x/Avenue 2005 06 ArcView 3.3
Windows 95 2003 06 Windows 2000 2006 03 Windows XP 2003 09
ArcPress
Spatial Analyst
Geostatistical Analyst
3-D Analyst
ERDAS Basic 8.5 Image Analyst 2003 09
ArcPublisher 2003 06
ERDAS Advanced 8.5 ERDAS Advanced 8.6 2003 06
ArcPad
Windows CE
3
―Sunset‖ means nearing the end of serviceable life. If something is in this category, new development is highly discouraged and viewed as imprudent.
4
Date when software is no longer on FS machines.
5
Date when the OSTIB is released to the field.
6
Need to define how this will be used prior to becoming standard.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 9
Date4 Date Date5 Date
Sunset3 Existing Standard Next Releases Point Solutions6
yyyy mm yyyy mm yyyy mm yyyy mm
APPLICATIONS
Geospatial Interface 1.0 2003 04
GIS Data Dictionary 1.1 2002 02 GIS Data Dictionary 2.0 2003 06
NHD Geodatabase 2003 06
FSNRA FSNRA next generation – Tie to 2004 06
FSNRA support of ArcSDE
NILS SM/MM 2003 10
IMPP & RMET
HARDWARE
Desktops P4
Laptops x.x P4
Handhelds
Servers
Backups
Memory (RAM)
PC Disk Space
Server Disk Drives
DATA
Strategy for populating the FS 2003 06
GDD Std layers
Local coverages to SDE (spatial 2003 06
data into Oracle) start date
FS GDD coverages to SDE 2004 06
(spatial data into Oracle) start date
Development of Object 2005 01
Relationships for building object or sooner
intelligence in ArcGIS
Redesign of the geospatial 2006 06
components of FSNRA into object
model based on object intelligence
Redesign of local data into object
model based on object intelligence
Shapefiles Shapefiles
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 10
Date4 Date Date5 Date
Sunset3 Existing Standard Next Releases Point Solutions6
yyyy mm yyyy mm yyyy mm yyyy mm
Warehouse VS Distributed Data
Maint. Update cycles of FS GDD
Publishing (internal & external) of
data - protocols for accessing
Metadata – initial metadata spatial
requirements
Thin client technologies
Network enhancements
DCE DFS Retirement
Boundary-less enabling of
applications
Site local services (Data close
issue)
Cell Consolidation
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 11
Appendix A – Issues
ArcGIS implementation issues have been divided into three broad categories: Data, People, and
Technology. For each issue identified, there is a description of what level of the organization should
take the lead in resolving the issue and the tasks to move toward the desired future condition.
Data
Migrate FSNRA designs from the “coverage” data model to a “geodatabase” data model that
takes full advantage of the more robust enterprise functionality, concurrent editing, and analytic
environments that ArcGIS offers.
Who: Washington Office (leadership of FSNRA development teams)
Tasks: Implement ArcSDE; migrate to existing geodatabases; all FSNRA modules must have
a spatial component; and time must be allowed to customize the applications to meet
user‘s needs; define and maintain coincident rules while building geodatabases for
applications.
When: See dates proposed in Table 1 (software/hardware/data evolution table)
Redesign FSNRA to true object-relational geodatabase.
Who: Washington Office (leadership of FSNRA development teams) must become aware of
this evolutionary step and be willing to support and endorse the work. FSNRA
development teams in collaboration with other key partners (e.g., NHD
development/migration to geodatabase is led by EPA and USGS).
Tasks: FSNRA team members participate in ESRI geodatabase working groups. Identify
proper level of USFS involvement in these working groups. At a minimum examine
work to date to avoid the cost of duplicating efforts.
When: June – November 2003
Make the FS GIS Data Dictionary (FSGDD) a definitive, authoritative source of database design
criteria and guidance.
Who: Washington Office (FSNRA development teams and Deputy Area GIS Data
Administrators (DAGDAs))
Tasks: Develop methods and strategies of appending and joining locally developed/required
data to data sets defined in the FSGDD.
Define what it means to be ―compliant‖ with the FSGDD.
When: Begin June 2003
Ensure metadata for FSGDD data sets become mandatory and to a large extent should be
populated by the FSNRA (using prototype data sets from application development).
Who: Washington Office (FSNRA development teams and DAGDAs)
Tasks: Many fundamental FGDC metadata elements (e.g., abstract, purpose, limitations)
should be consistent across the entire FS for each data set defined in the FSGDD and
should be crafted by the FSNRA development teams. Forests could then ―import‖ the
―nationally standardized‖ metadata for FSNRA data sets and then append and
complete metadata entries to ―localize‖ the metadata file. But forests shouldn‘t wait
for the templates to begin populating their metadata records.
Determine the role of ArcCatalog.
When: By the time the new tools are implemented in the new object-oriented environment.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 13
Archive analysis products and temporal “snapshots”.
Who: Washington Office and Regional Office (IRM)
Tasks: Use existing tools and methodologies to capture project work; institutionalize large
analysis backup techniques for snapshots of large analysis efforts (e.g. Forest
Planning). Explore methods, costs/benefits, etc. of implementing ―versioned
geodatabases‖.
When: June – November 2003
Acquire new and migrate legacy data into FSNRA.
Who: Regional Office and Forest
Tasks: Create populated databases for natural resource managers to do useful analysis over
larger extents. Since the national application database structures provide a consistent
structure into which data is to be entered, a standard set of protocols should drive data
collection methods as authored by appropriate data stewards.
When: Ongoing, continual to fulfill the promise of the FSNRA, as well as, contribute to
implementation of ArcGIS. As FSNRA fully evolve into true object-relational
geodatabases, data acquisition and migration strategies will probably require
adjustment.
Migrate from ArcView 3x/ArcInfo 7.1.2 to ArcSDE/geodatabase and ArcGIS.
Who: Regional Office and Forest (wherever programming takes place – person responsible
is dependent on the level at which the program resides)
Tasks: Identify standard geodatabase layers for moving to ArcSDE and geodatabase.
Overall GIS data management will need to be updated to encompass this transition
period since forests still need to do project work today. We have the technology to do
this with ArcSDE OSTIB release & ArcGIS 8.1.2.
Identify programs to convert and opportunities for standardization of ―analysis
process‖ to the forest and region levels in lieu of the FSNRA timeline for conversion.
Conversion of Avenue, AML, and other identified programs.
When: As soon as a forest or region is ready to convert data to ArcSDE and geodatabase as
identified in unit‘s ArcGIS Implementation Plan. If possible, shift emphasis in
programming to new platform as soon as possible after data is converted.
Implement intent of Executive Order 12906 National Spatial Data Infrastructure (NSDI)
Who: Washington Office, Regional Office, and Forest
Tasks: Release final guidelines on serving geospatial data over the Internet.
Identify data to be supplied.
Ensure all units have made data available.
When: Now through 2006
Recognize the role of the Geospatial Interface (GI) in supporting standard data and migration of
local tools.
Dual support of both ArcView/coverage and ArcGIS/Geodatabases in FSNRA won’t be provided.
As the FSNRA move to ArcGIS and SDE/Geodatabase, the support for Arcview and coverages
will end (no new development – only legacy support).
Spatial Data Requirements need to be clearly stated by the FSNRA leadership in order to take full
advantage of the power of spatial data.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 14
People
Maintain and update the FS ArcGIS Implementation Guide
Who: Washington Office (IRM)
Tasks: Update the FS ArcGIS Implementation Guide to reflect changing conditions
When: Every six months
Append the FS GDD Change Management process.
Who: Washington Office (IRM)
Tasks: Update FSH 6609.15 to account for FS GIS Data Dictionary changes which affects
the evolution of data translator, data loader, SDE Structure, Geospatial Interface, etc.
When: By October 2003
Fill the Deputy Area Geospatial Database Administrators (DAGDA) positions.
Who: Washington Office (GEB Directors)
Tasks: Identify how GEB, IREMCG, ESCT can facilitate the filling of the DAGDA
positions.
When: May 2003 GAC meeting
ArcGIS deployment and the role of Partnered Interagency National Applications.
Who: Washington Office (FSNRA development teams)
Tasks: Facilitate the process among FSNRA
When: May 2003 GAC meeting
Develop an ArcGIS marketing plan.
Who: Washington Office (GAC facilitate)
Tasks: Develop a cost/benefit analysis that describes migrating data, use of ArcGIS/ArcSDE
(resources, deployment, training), and use of National Applications. There is a need
for a Commitment Plan from R/S/WO that tier to this National Guide (ownership
needs to come from all levels of the organization).
Define role of GEB to support the Guide and how they help influence Chief and Staff.
Define role of Regions/Stations and how they influence Chief and Staff.
Increase partnership with IRM.
When: May 2003 GAC meeting
Provide efficient helpdesk and user support for all ArcGIS components.
Who: Washington Office and Regional Offices (IRM)
Tasks: Need to define appropriate support for technical and application uses.
Use service level agreements for helpdesk and involve the regions to identify the
process for resolving problems associated with implementation and use.
When: June – November 2003
Change development environment from AML/Avenue to Visual Basic (VB).
Who: Washington Office (FSNRA development teams) and Regional Office
Tasks: Develop a transition plan to the VB development environment, which is a more
sophisticated programming environment. Account for the investment required to
develop VB skills.
When: June – November 2003
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 15
Provide for adequate skills and staffing in the organization to implement ArcGIS.
Who: Washington Office, Regional Office, and Forest
Tasks: Units should have geospatial skills as part of KSAs, which are tied to core
competencies.
Provide guidance to Regions/Stations on developing their own ArcGIS training plans
that tier to the National ArcGIS training plan and document support by management.
Develop a transition plan for the development environment.
When: June – November 2003
Ensure that communication networks for GIS are in place and used appropriately.
Who: Washington Office and Regional Office
Tasks: Define appropriate mediums for various types of GIS related communication, e.g.
technical help questions, GIS theory questions, tips, tools, job outreach, conference
announcements, training opportunities.
Implement selected mediums.
Notify GIS community of mediums and appropriate uses.
When: June – November 2003
Need to define if there are any mandatory dates in conjunction with deploying ArcGIS.
Need to define roles and responsibilities for Line Officers, Resource Managers/End Users, IRM
community, and FSNRA in the implementation of ArcGIS.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 16
Technology
Technology (servers, backups, telecommunications, PDRs, GPS, software) involves supporting FS field
business needs in an efficient and effective manner. We‘ve made progress, but we continue to have
large implementation overhead costs with Oracle and ArcGIS technology. Servers for ArcSDE &
Oracle are available on contract, ArcGIS is on the desktop and getting it to the right place at the right
time is the responsibility of each FS unit.
Respond to eGov requirements and user interest in easy access to corporate data.
Who: Washington Office (GEB)
Tasks: Continue to support tools such as the GI to provide common access to diverse
applications, connecting spatial and tabular data, and data warehouses (such as the FS
Clearinghouse Node). ArcIMS will play a broader role in delivering data in the near
future.
Identify impacts to the Region and Forest of eGov requirements.
Identify impacts to the Region and Forest of Geospatial One-Stop.
Identify impacts to the Region and Forest of National Map.
When: June – November 2003
Clarify the terms “Deployment” verses “installation” versus “implementation” of ArcSDE.
Who: Washington Office (IRM)
Tasks: Deployment is installation and making tools available. Implementation is populating
the database and using data in applications and analysis. There are significant
differences that warrant clarification to all levels of the FS.
When: June 30, 2003 is the target data for deploying the ArcSDE OSTIB to a machine at the
forest level (see definition above). Full implementation needs further consideration,
but is implied by the June 2004 target for FSNRA conversion to ArcSDE.
Identify and address other factors that impact accessing data on the local desktop from the server.
Who: Washington Office (IRM)
Tasks: Identify technology issues that exist which have caused or contributed to the issue of
serving data to the desktop.
Identify the role of ArcSDE with this issue – although ArcSDE will solve this issue to
some extent, there are other mitigating circumstances that need to be addressed and
solved. A study is underway on the use of Citrix.
When: June – November 2003
Ensure adequate Oracle server storage capacity to support ArcGIS.
Who: Washington Office (IRM)
Tasks: Reemphasize policy that all corporate data is to be stored on j, k, & l drives.
Provide adequate data storage and data backup facilities that take into account the
―growth‖ of data storage needs.
Ensure proper mechanisms are in place to move ―official‖ data from the desktop to
the servers, and to provide proper back up to the desktop.
Look at DVD burners as an alternative for back up to desktops in addition to the
enterprise solutions.
Look at Tivoli Storage Manger to solve this problem
When: June – November 2003 before regions and forests actually use ArcSDE for data.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 17
Select a Developer platform that addresses the needs of the FS now and in the future as technology
and software advance and change (i.e. VBA, .NET, ArcObjects, MapObjects, etc.)
Who: Washington Office (IRM and FSNRA development teams)
Tasks: Analyze present development software based on current and future needs as we are
moving into a COM-based environment (mitigating tools to support this change).
When: June – November 2003 before each application must go their own way and develop
things differently.
Develop an ArcIMS strategy.
Who: Washington Office (IRM) in coordination with GAC
Tasks: Plan for incorporating ArcIMS into the FS workflow and FSNRA. Some ArcIMS
implementation issues are addressed with proper establishment of sound ArcSDE
geodatabase designs but there are many other issues to address. It probably does not
make sense to install and support ArcIMS at every forest, but we probably need more
than one national location.
When: Begin June 2003 with a December 2003 completion date.
Identify and emphasize development of Field Data Collection tools.
Who: Washington Office (IRM and FSNRA development teams) in coordination with GAC
Tasks: Identify ongoing efforts to develop an implementation plan where one or two
technologies are identified to meet the majority of field data collection needs.
Especially critical if ArcPad is expected to play a role with field data recorders and
―detached transactions‖. Appropriate devices for capturing spatial data in the field
should be carefully considered (‗pocket‘ vs. tablet).
When: June – November 2003
Ensure adequate Oracle server performance to support ArcGIS.
Who: Washington Office (IRM and FSNRA development teams)
Tasks: Clarify that Oracle server performance – 64-bit, multi-CPU, 2GB+ RAM Oracle
servers are needed to support Oracle 9i, not ArcSDE. ArcSDE can be deployed on
most systems in some form. The technology is available but the availability of money
to buy servers is a Forest issue. Loss of WCF funds and accelerated installation of
Oracle 9i have made this a significant issue.
Identify realistic server workload and configuration to support it.
Identify limits to upgrading a system if purchased too small to last over the ―life
expectancy‖.
When: June – November 2003
Evaluate cell-based dependencies with FSNRA and ArcSDE.
Who: Washington Office (IRM and FSNRA development teams)
Tasks: Need to identify the risks and/or benefits of moving beyond the ―forest level‖ and
look at options for removing forest/cell-based dependencies in future releases. Cell
consolidation is pushing the urgency of this change, but the agency needs to assess
when a more centralized approach is appropriate.
When: June – November 2003
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 18
Develop a strategy for data storage.
Who: Washington Office (IRM) in coordination with FSNRA
Tasks: Develop a plan for accessible data storage and look at options for data warehouse
versus distributed data.
When: June – November 2003
Other technical and data aspects of geospatial extensions and applications – geostats, image
analyst, raster & vector, imagery & compression extensions are part of ArcGIS and the FS is
acquiring them.
Inability to edit ArcSDE Geodatabases in Arc is no longer an issue with the June 2003 release date
of ArcGIS 8.3, which solves this problem.
Re-emphasize the need to move the organization along the technology timeline as quickly as
possible (e.g. replacement of Windows 95 machines).
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 19
Appendix B – ArcGIS Implementation Guide Workshop Attendance
March 18-20, 2003
Salt Lake City, UT – GSTC – Aspen Room
John Varner – R2, RO Spatial Applications Developer
Pat Frieberg – R3, RO GIS Analyst
Suzanne Johnson – R4, RO GIS Analyst
Craig Mahaffey – R5, Regional GIS Coordinator
Stephen Bown – R6, RO Geospatial Tools Specialist
Nora Holmquist – R6, RO Data Systems Program Manager
Ebeth McMullen – R8, Deputy Director of Engineering
Mike Martischang – R9, Regional GIS Coordinator
Wanda Hodge – R9, Regional Resource Information Coordinator
Gary Fisher – R10, Regional GIS Coordinator
Grant Dekker – WO IRM, Branch Chief AT&SE
Wally Deschene – WO IRM, AT&SE
Ron Gendreau – WO IRM, AT&SE
Bill Wettengel – WO NRIS Group Leader
Curtis Day – WO NRIS/Infra GIS Developer (also representing Fire GIS)
Cal Gordy – WO NRIS Water Lead Developer (also representing GAC geoteam rep)
Jim McGinnis – WO ALP/NILS Coordinator
Ron Tymcio – RMRS
Duane Fisher – R10, Tongass NF, representing WO FACTS GIS
Tom Bobbe – RSAC Manager
Dan Thompson – GSTC, GIS Group Leader
Tim Clark – ESRI (Wednesday only via conference call)
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 21
Appendix C – Glossary
ESRI‘s ArcGIS introduces a new collection of terminology to describe the new architecture and
functionality the product delivers. Rather than coin new ―Forest Service interpreted terminology‖ of
ESRI‘s new ArcGIS terminology, this Guide‘s authors have consciously chosen to use terminology
consistent with what ESRI presents in its software interface and documentation. All terms and concepts
defined in this glossary have been taken from the ArcGIS Desktop Help, GIS glossary chapter.
Term/Concept ESRI Definition
ArcSDE A gateway to a multi-user commercial RDBMS-for example, Oracle,
Microsoft SQL Server, Informix, and DB2. ArcSDE is an open, high-
performance spatial data server that employs client/server architecture to
perform efficient spatial operations and manage large, shared geographic
data. Was known as SDE before 1999.
ArcSDE for coverages An ArcSDE server that provides read-only access to ArcInfo coverages,
shapefiles, ArcStorm library layers, and Map LIBRARIAN layers. Uses the
same data transfer technology as ArcSDE for RDBMS servers.
Constraints Limits imposed on a model to maintain data integrity. For example, in a
water network model, an 8-inch pipe can't connect to a 4-inch pipe.
Coverage A file-based vector data storage format for storing the location, shape, and
attributes of geographic features. A coverage usually represents a single
theme such as soils, streams, roads, or land use. It is one of the primary
vector data storage formats for ArcInfo. A coverage stores geographic
features as primary features (such as arcs, nodes, polygons, and label points)
and secondary features (such as tics, map extent, links, and annotation).
Associated feature attribute tables describe and store attributes of the
geographic features.
Custom behavior Behavior is the implementation of an object class method. ESRI-provided
objects have a set of methods associated with them. A developer can choose
to override one of these methods or create additional methods. In this
instance, the object is said to have custom behavior.
Custom feature In geodatabases, a feature with specialized behavior instantiated in a class by
a developer.
Data type The attribute of a variable or field (column) that determines the kind of data it
can store. Common data types are character, integer, decimal, single, double,
and string.
Enabled feature In geodatabases, a network feature that allows flow to pass through it.
Extent The coordinate pairs defining the minimum bounding rectangle (xmin, ymin
and xmax, ymax) of a data source. All coordinates for the data source fall
within this boundary.
Feature 1. An object class in a geodatabase that has a field of type geometry.
Features are stored in feature classes.
2. A representation of a real-world object.
3. A point, line, or polygon in a coverage, shapefile, or geodatabase feature
class.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 23
Feature class The conceptual representation of a geographic feature. When referring to
1.
geographic features, feature classes include point, line, area, and
annotation. In a geodatabase, an object class that stores features and has
a field of type geometry.
2. A classification describing the format of geographic features and
supporting data in a coverage. Coverage feature classes for representing
geographic features include point, arc, node, route-system, route,
section, polygon, and region. One or more coverage features are used to
model geographic features; for example, arcs and nodes can be used to
model linear features such as street centerlines. The tic, annotation, link,
and boundary feature classes provide supporting data for coverage data
management and viewing.
3. The collection of all the point, line, or polygon features or annotation in
a CAD dataset.
Geodatabase An object-oriented geographic database that provides services for managing
geographic data. These services include validation rules, relationships, and
topological associations. A geodatabase contains feature datasets and is
hosted inside of a relational database management system (RDBMS).
Geodatabase data model Geographic data model that represents geographic features as objects in an
object-relational database. Features are stored as rows in a table; geometry is
stored in a shape field. Supports sophisticated modeling of real-world
features. Objects may have custom behavior.
Geodatabase, single-user A personal geodatabase. It can handle a single editor and multiple readers.
Georelational data A geographic data model that represents geographic features as an
model interrelated set of spatial and descriptive data. The georelational model is the
fundamental data model used in coverages—for example, it pulls together
geometry and attributes that are stored in different places.
Layer 1. A collection of similar geographic features—such as rivers, lakes,
counties, or cities—in a particular area or place referenced together for
display on a map. A layer references geographic data stored in a data
source, such as a coverage, and defines how to display it. You can create
and manage layers as you would any other type of data in your database.
2. The interface by which an application program accesses an operating
system and other services.
Long transaction An edit session on a feature dataset that may last from a few minutes to
several months. Long transactions are managed by ArcSDE's versioning
mechanism.
Multipart feature A feature that is composed of more than one physical part but only
references one set of attributes in the database. For example, in a layer of
states, the State of Hawaii could be considered a multipart feature. Although
composed of many islands, it would be recorded in the database as one
feature. [Similar in concept to the former ―regions‖ and ―routes‖ features.]
Multipoint feature A feature that consists of more than one point but only references one set of
attributes in the database. For example, a system of oil wells might be
considered a multipoint feature, as there is a single set of attributes for
multiple well holes.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 24
Multiuser database A geodatabase in an RDBMS served to client applications (for example,
ArcMap) by ArcSDE. Multiuser geodatabases can be very large and support
multiple concurrent editors. Supported on a variety of commercial RDBMS
including Oracle, Microsoft SQL Server, IBM DB2, and Informix.
Object 1. In geodatabases, the representation of a real-world entity. An object has
properties and behavior.
2. The interface by which an application program accesses an operating
system and other services.
Object class While spatial objects (features) are stored in feature classes in a geodatabase,
nonspatial objects are stored in object classes. A table is an object class if it
has a column with the data type OID (Object Identifier), where each row in
the table is an object. In a geodatabase, nonspatial objects can have custom
behavior
Planar topology Planar topologies model systems of line and area features as a continuous
coverage of an area. Planar topologies allow features to share common
boundaries, such as counties sharing an outer boundary with a state.
Topological associations are represented with geometric networks and planar
topologies.
Relationship An association or link between two objects in a database. Relationships can
exist between spatial objects (features in feature classes), nonspatial objects
(rows in a table), or between spatial and nonspatial objects.
Relationship class Objects in a real-world system often have particular associations with other
objects in the database. These kinds of associations between objects in the
geodatabase are called relationships. Relationships can exist between spatial
objects (features in feature classes), between nonspatial objects (rows in a
table), or between spatial and nonspatial objects. While spatial objects are
stored in the geodatabase in feature classes, and nonspatial objects are stored
in object classes, relationships are stored in relationship classes.
Relationship, composite Composite relationships describe associations where the lifetime of one
object controls the lifetime of its related objects. An example is the
association between highways and points for placing a highway shield
marker. Shield points can't exist without a highway. See also relationship
and simple relationship.
Relationship, simple Describes associations between data sources that exist independently of each
other. A coverage and table are independent of each other if, when you delete
the primary object, the related object continues to exist. For example, a table
contains measurements taken at different stations. If you stop using a station
and delete that point, you might keep the measurements for historical
purposes.
Shapefile A vector data storage format for storing the location, shape, and attributes of
geographic features. A shapefile is stored in a set of related files and contains
one feature class.
Subtypes In geodatabases, although all objects in a feature class or object class must
have the same behavior and attributes, not all objects have to share the same
default values and validation rules. You can group features and objects into
subtypes. Subtypes differentiate objects based on their rules.
Transaction A logical unit of work as defined by a user. Transactions can be data
definition (create an object), data manipulation (update an object), or data
read (select from an object).
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 25
Performance tuning Adjusting settings and configuration of hardware and the software installed
on it to improve speed and efficiency of data access and analysis by and
delivery to end-users. A contrasting ―performance improvement‖ strategy is
to purchase ―bigger/faster‖ hardware and software, avoiding ―solving‖
problems.
Validation rule Validation rules can be applied to objects in the geodatabase to ensure that
their state is consistent with the system that the database is modeling. The
geodatabase supports attribute, connectivity, relationship, and custom
validation rules.
Version In geodatabases, an alternative representation of the database that has an
owner, a description, a permission (private, protected, or public), and a
parent version. Versions are not affected by changes occurring in other
versions of the database.
Work flow An organization's established processes for design, construction, and
maintenance of facilities.
Workspace A container for file-based geographic data. This can be a folder that contains
shapefiles, an ArcInfo workspace that contains coverages, a personal
geodatabase, or an ArcSDE database connection.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 26
Appendix D – References
ESRI. 2001. ArcGIS Desktop Help (online help files for ArcGIS v8.1.2). Environmental Systems
Research Institute, Inc., Redlands, CA.
ESRI. 2001. What is ArcGIS? – GIS by ESRI. Environmental Systems Research Institute, Inc.,
Redlands, CA.
MacDonald, Andrew. 2001. Building a Geodatabase – GIS by ESRI. Environmental Systems
Research Institute, Inc., Redlands, CA.
Mitchell, Andy. 1999. The ESRI Guide to GIS Analysis – Volume 1: Geographic Patterns and
Relationships. Environmental Systems Research Institute, Inc., Redlands, CA.
US Forest Service – Geospatial Advisory Committee. February 22, 2001. Geospatial Technology
Core Competencies for Resource Management and Research. Posted at intranet site
http://fsweb.gac.fs.fed.us/core_comp/index.html .
US Forest Service – Open Systems Environment Center of Excellence. March 13, 2003. Daily
Operations Guide/ArcSDE v2.09. Posted at intranet site Posted at intranet site
http://fsweb.r1.fs.fed.us/ose/documentation/ArcSDE_DOG.doc .
US Forest Service – Open Systems Environment Center of Excellence. March 11, 2003. Open
Systems Technical Information Bulletin OSTIB-2003-06: Install ArcSDE 8.1.2. Posted at
intranet site http://fsweb.wo.fs.fed.us/im/helpdesk/TIBS/2003_released_tibs/ostib-2003-06.doc .
Zeiler, Michael. 1999. Modeling Our World – The ESRI Guide to Geodatabase Design.
Environmental Systems Research Institute, Inc., Redlands, CA.
c7ef503f-f131-4b77-a5bd-a40d2e2ac1c7.doc 27