Tree inventory system
This doc very much under construction; in fact not even really a doc yet. More of a stream of consciousness.
Brian Wilson 12:48, 23 February 2006 (PST)
What is a tree inventory?
A 100% tree inventory is a tree-by-tree portrait of the urban forest. The inventory is the foundation for planning all work in the urban forest. This information provides a tool for both day-to-day and long term management.
Why do we need an inventory
- Budget tool
- Work planning
- Hazard tree removal
- Trees historical info
- Pruning cycle
- Planting program
- Enforement of vegetation code
What data do we collect?
For each tree,
- Location (address)
- Species
- Diameter / Age
- Condition (dead, poor, fair, good, excellent)
- Structural Defects (topped, included bark, decay cavities.. Etc)
- Planting site (park strip width, tree well size)
- Proximity to utilities (0verhead power lines, sidewalk condition) ETC.
Overview
- Create a complete tree inventory system.
- Trick the City of Corvallis and OSU into beta testing it. :-)
I am evaluating tree inventory systems because (1) Corvallis needs one (2) the project requirements are interesting to me.
It has to have a field data collection component (for example, ArcPad based) with or without GPS. In my mind, with.
It has to have a database backed component to manage the data, and that database contains spatial data so having it integrated with GIS is critical.
It should have an asset management component, interesting to me because it is like the software release tracking system I was writing a few years ago.
In short, this project pulls together just about everything I am interested in these days: GPS, GIS, field work, databases, and spatial databases.
Build or buy
Here are a few notes on tree inventory systems that are available commercially.
Or I should say were available; this doc will be updated soon. It is based on material pulled from web sites and things have changed since it was written. When developing feature requirements though, even documentation on products no longer available can be useful.
My current inclination is to put together a system by combining some commercial and some free software to create a useful data collection system. I would posit that one requirement for any purchased commercial system would be the ability to work with existing data. So by embarking on data collection before installing a complete asset management system, we're not losing anything.
Requirements
I will develop a better sense of what is required by evaluating the software and by some meetings with the staff at City of Corvallis and at Oregon State. Both entities have expressed interest and both are local to me.
Todo: contact other local agencies and see how they manage their tree inventories, if they have software, get feedback; if not, ask if they want to participate at some level. Philomath, Albany, ?
Field requirements
Data collection by interns/contractors. Needs to be fast and simple.
Access to all data in field for work crews and arborist.
Management requirements
Basically this is an asset management system integrated with GIS. It has to be able to do the usual GIS stuff plus tracking plus reporting.
Although this is possibly the most important component I am relegating it to the back burner for now.
Implementation
Field component
Data collection field component based on a customized ArcPad on a PDA.
Advanced version either a portable ArcMap or ArcPad on a laptop.
Optional Bluetooth GPS
Server component
Mapserver (or ArcIMS) based application
We have ArcIMS available, but I lean towartds the opensource mapserver since basing the server component on free stuff brings down the final price by 50% should it ever get used anywhere else.
If I build it on a mapserver base I can test it out on top of shapefiles and then transition to PostGIS system, which should give much better performance for queries.
I want a user to be able to browse to an area of interest on a web-based map interface, and then use the currently viewed map to define the extent for queries, reports, and export to ArcPad.
I've looked at ArcPad project files, and this really seems pretty doable.
This means the checkout of data could be done without a copy of ArcGIS being involved.
Locking... can I lock an extent in PostGIS? That would be very cool. Someone could check out an extent to ArcPad, then upload new data into the system. What about revision control?
At least for the tree database, these operations should be fairly easy as long as the trees are stored as points. Only the tree inventory will be updatable from ArcPad; other layers would be clipped for export but not locked.
Redlining would be nice. Just the ability to write notes on the map and keep that in a separate layer. I suppose storing photos the same way would be nice.
Desktop component
The desktop app is just ArcGIS. Use ArcMap to maintain spatial data.
Links
Information on iTree software: http://urbanforestrysouth.org/Resources/Library/TTResource.2005-01-11.0622/view
International Society of Arborists, who do the "Trees are good" website