Street Trees: Determining a Model, Process, and Architecture for Inventory and Maintenance

Peter Godfrey Jr., RLA and AICP


Introduction

Many urban-center residents are unaware that street and park trees impact summer cooling and winter heating bills, remove pollutants from the urban air during in-leaf season (for instance in 1994 NYC trees removed 1,800 metric tons of air pollution with an estimated societal value of $9.5 mil-lion), and have positive mitigation impacts on the stormwater runoff rate. They just want a tree in front of their residence. They just want a little nature within the concrete landscape.

The true cost associated with maintaining the health of street and park trees is little understood and often ignored. Considering that the average life cycle of a street tree is estimated to be 10 years in an urban core and 30 years citywide, the cost can add up. This is especially true during the later stages of street tree growth when the maintenance costs, as well as the overall benefits, increase.

Staff time and material costs associated with monitoring and maintaining the health of street and park trees generally include:

        1. Inspection in response to a request
        2. Site preparation
        3. Planting
        4. Staking, mulching, watering
        5. Feeding
        6. Inspection in response to a request
        7. Pest/disease control
        8. Inspection in response to a request
        9. Pruning (cyclical)
        10. Inspection in response to a request
        11. Removal
        12. Inspection in response to a request
        13. Planting

The time spent on tree care does not take into consideration the numerous fields of data that need to be managed, edited, and reported on per tree in an information system. For instance, many current tree information systems track a minimum of 62 pieces of information per tree.

While the benefits of maintaining healthy street and park trees cannot be measured solely in fiscal terms, the actual costs can and should be, to assure efficient expenditure and accountability.

 

Street Tree Process Overview

Many large cities (such as New York, Philadelphia, and Washington) will process approximately 60,000 requests for tree-related services during the course of a typical year. The general public can initiate these requests, as well as community boards, internal City departments, and non-profit local groups.


A predominant number of these requests must be followed by a site visit for field verification re-garding conditions, an update of the existing information system, the generation of a work order, performance of the work, and the eventual disposition of this work order. With the exception of emergency tree removal, the majority of tree-related work in many cities is completed by outside contractors. There may be multiple contractors for this work. All this work needs to be accounted for and reported on for fiscal tracking and capital planning.


Accounted-for street tree planting within any planting season in most cases will be less than actual planting due to the fact that many trees are planted without alerting the proper oversight agency. In fact, the only time these un-accounted for trees are inventoried are when a complaint is filed.


In a typical year, approximately 7,500 dead street trees can be removed from any one of the three mentioned cities. If the request for removal of a dead tree was initiated through the proper channels, the inspection of this request and the removal of the dead tree is completed within a discrete period that can range from 30-days to three-years. This may not involve the removal of the actual stump, which will be done at a later date.

 

Preliminary Project Vision

A draft vision for any IS project should be created, and an example for an initial IS/GIS street tree management solution may be as follows:


XXXX is implementing a centralized, enterprise-wide information system for street and park tree maintenance management that will provide efficient data management, distributed data access, and robust reporting, while facilitating field data collection and including geographic information system (GIS) capabilities.


The critical word in the draft vision statement above is "enterprise-wide." The implementation of an enterprise-wide information system makes possible the "democratization" of access to information. Well-managed, central data is much more likely to be standardized, accessible, and of reliable quality.


Typically, enterprise-wide data management software packages enable the software to do more than just support an operation; the data management system becomes an integral part of the operation itself. The critical aspect of this type of enterprise-wide information system implementation is to as-sure that the software supports operations to the fullest extent possible. Operations should not have to be radically re-engineered to support the functional constraints of the software used, although some re-engineering may be necessary and desirable to maximize efficiency of operations and to achieve better, more cost-effective data management.


Another aspect of enterprise-wide software development and implementation is the potential need to integrate with other systems. These other "systems" may range from local PC-based databases that have been implemented by staff to work around existing system shortcomings, to citywide per-sonnel databases with wage information. The ability to "link" to data in other systems can be a valu-able benefit.

 

Project Assumptions

Any IS/GIS project must be undertaken with some common assumptions. For a tree information system, some typical assumptions would be would be that the client:

      1. Is committed to implementation of a new information system
      2. Seeks an enterprise-wide solution with a centralized database
      3. Seeks a broad view of implementation tasks that facilitates consideration of a variety of alterna-tive system components
      4. Desires to migrate existing data into the new platform, and to integrate GIS capabilities with the new system, while understanding that all system users will not require GIS capabilities
      5. Seeks to manage both street and park trees through the new system
      6. Seeks to integrate other GIS data
      7. Seeks the capability to collect field data
      8. Will consistently assist the chosen solution provider throughout the project
      9. Understands that implementation of a new system may necessitate some re-engineering of busi-ness processes
      10. Will want to enhance the system once the project is completed
      11. Has staff experienced in IS and GIS functionality

 

Tree-Related Information Systems

Some issues with many existing tree information systems (hardcopy as well as digital) are:

  1. Lack of "centralized" database
  2. Lack of citywide data compilation capabilities
  3. Inconvenient, error-prone user interface
  4. Poor input screen organization
  5. Uncoordinated use of data fields
  6. Lack of "batch" editing capability
  7. Lack of an archival data function (e.g., only the last action is retained in database)
  8. Inflexible reporting capabilities that do not meet user needs
  9. Lack of a method for accurately locating trees within parks.

Most planned tree information systems should be flexible, have an open architecture, and maintain an intuitive manner of data entry, maintenance, and editing.

The primary functional requirements of any new system should include:

      1. Customer call intake
      2. Generation of service requests
      3. Tracking of inspections
      4. Generation and tracking of work orders
      5. Flexible reporting capabilities
      6. Cost tracking (internal and external work)
      7. Inventory
      8. Work history
      9. Maintenance and access through a central relational database management system platform (RDBMS)
      10. Integration with geographic information system (GIS) platforms
      11. Capability for field data collection and download (real time and/or end of day)
      12. Distributed access and maintenance
      13. Intuitive interfaces


Using these requirements as a guide, it is highly recommended that business and data flow model-ing be done to determine both process refinement as well as data needs for a tree information sys-tem.

 

Functional Requirements: Business Process/Data Flow Modeling and Use Case Interviews

The business process model defines the flow of business process activities and the data flow model defines the timing and responsibilities for data input and output. An understanding of the data in-put/output will distinguish static data (such as an addresses) from dynamic data (such as dates), and provide insight into daily, weekly, monthly, and yearly reporting cycles and performance benchmarks. The use case interviews are carried out to model the enterprise and its information needs through real-life process scenarios. The use case interviews will often identify processes that are completed external to the "defined" business process and data flow that will need to be incorpo-rated into the new system.


Meetings should be held that will result in documentation of the business processes associated with all aspects of tree management, identification of the input/output of data associated with tree-related work and management, and use case interviews of staff associated with the following process components:

      1. Customer calls
      2. Service requests
      3. Inspections
      4. Planting
      5. Removing
      6. Pruning
      7. Capital tracking and planning

The proposed documentation should be presented in a graphic manner supplemented by extensive text. By graphically representing the business processes, flow of information, and use cases, the new system will be better modeled. This will allow a client to concretely define its current system and business processes and identify areas for potential reengineering.


Once the system functional requirements have been defined, it will become important to define the data model for the key element of this project: the tree.

This task will result in the definition of a tree data model for use in the GIS environment. This data model will become an integral component of a GIS-centric solution with spatial functionality. It is strongly suggested that any tree data model be developed as an Esri geodatabase. The primary benefit in this approach is the ability to retrieve spatial and attribute data from one table as opposed to multiple tables inherent to the coverage and shapefile model. This design feature accelerates retrieval time as well as server processing. Once agreement is reached in this regard, we will need to "model" that feature to assure that its attributes and future "behaviors" truly are representative and in accordance with defined requirements.

In order to do this, it is necessary to:

      1. Define the characteristics of a tree
      2. Define the characteristics of its "site" or location
      3. Potentially integrate these two characteristics into one feature
      4. Develop a definition for the spatial location of tree inventory (address, block-side sequential, X and Y coordinate)

The first two items are especially important because tree characteristics and its site can be defined in different ways.

For example:

  1. Different trees can be associated with one tree pit (site) over time
  2. One tree pit can have no tree associated with it
  3. Tree pits can be paved over and removed
  4. Tree pits can be created
  5. Park trees (as currently defined) are not contained in a tree pit, but in a park
  6. Trees can be planted in movable containers

It is initially recommended that a data model based upon both the tree "site type" and the tree itself be created. This will facilitate the inventory of tree sites, their status, and the addition/deletion of a tree site, potentially using the actual tree as an attribute.


Agreement will also need to be reached on the spatial definition of trees. While some systems locate trees based on a block side, the common method of spatially locating trees is through an address. In the GIS environment, this can be displayed through geocoding. This method will place numerous tree points atop one another if one street block contains one address and multiple trees. Without the use of GPS equipment, which may be problematic in dense parts of a City, another method of depicting a tree's location should be considered. The method for doing this may need to be "borrowed" from another model used by utilities (such as street lights or parking meters).

 

Software Solution

As one decides upon the software solution for any project, the following general guidelines should be considered in making a final software selection:

    1. Does the package have an ample installation base and positive recommendations from users?
    2. Do the development, licensing, and maintenance costs fit within the available budget?
    3. Will the vendor provide an acceptable level of timely support?
    4. Does the software maker verify its product's compliance with mandatory user functionality?
    5. Does the package provide for efficient customization?
    6. Does the software meet needs and characteristics important to the business model?

 

Conclusion

The management of urban street trees through a GIS is an underutilized concept that could become a reality in the near future for many urban centers. The realization that a street tree is another urban asset that needs to be managed much the same as a street pole and water pipe has opened up this opportunity for growth. In summary, the better we manage our urban trees, the better we will man-age our environment as well as the available quality of life for our city residents.

 


Author Information

Peter Godfrey Jr., RLA and AICP
GIS Project Manager; CDM (Camp Dresser & McKee)
Two Penn Center Plaza, 1500 JFK Boulevard, Suite 624
Tel: 215 636-0600 ext. 254
Fax: 215 636-9811
godfreyp@cdm.com