Tree inventory system: Difference between revisions
Brian Wilson (talk | contribs) |
Brian Wilson (talk | contribs) |
||
| Line 29: | Line 29: | ||
== Implementation == | == Implementation == | ||
=== Field component === | |||
Data collection field component based on a customized ArcPad on a PDA. | Data collection field component based on a customized ArcPad on a PDA. | ||
| Line 53: | Line 53: | ||
This means the checkout of data could be done without a copy of ArcGIS being involved. | 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. | |||
Revision as of 22:47, 24 February 2006
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)
Overview
Ultimate goal: Create a complete tree inventory system for the City of Corvallis.
notes on tree inventory systems
Reality: Break the project down into several manageable and useful subprojects.
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.
