Acquisition of Hardware & Software
- GIS Hardware and Software Acquisition
- Steps in the GIS Acquisition Process
- Evaluation of Proposals
- GIS Delivery and Installation Plan
- Sample Hardware Specifications
- Network and Communications Specifications
- Software Specifications
- GIS Database Structure
This guide begins the description of the first of four steps of the GIS Development process which deals with the actual assembly of the GIS and its subsequent operation.
All of the necessary planning, design and testing should have been completed during the execution of the previous seven steps of the GIS development process. The remaining steps and their main purpose are as follows:
- GIS Hardware and Software Acquisition - includes the final selection of the hardware and software (by competitive bid in response to a Request for Proposals - RFP, as necessary); the delivery and installation of the hardware and software; and all necessary renovation of space, wiring, and environmental remodeling.
- GIS System Integration - bringing the final database and the hardware and software together and testing their combined operation.
- GIS Application Development - preparing applications identified in the Needs Assessment which require additional programming using the GIS macro language or other supporting programming languages.
- GIS Use and Maintenance - starting use of the GIS and institution of database, hardware and software maintenance programs. Further application development and user training are also continuing needs.
This step is the actual purchase of the GIS - hardware and software. The GIS to be acquired is usually subject to competitive bid by the interested vendors. The single most critical part of this process is the preparation of an adequate (and detailed) Request for Proposals (RFP).
Acquiring the components for your GIS is an important step. Use all of the information you have gathered up to this point to produce a document telling prospective bidders what you need. The document should clearly communicate your needs and how bidders should respond to the RFP.
During this phase remain objective. Keep as much of the "politicking" out of the selection process. You should be looking for the best value for your money, not the lowest cost.
The evaluation team should be made up of interested staff from departments involved in implementing GIS within the local government. These individuals need to be objective and not have pre-defined ideas of what system they want. They need to be action oriented and willing to put in the time to do the job right. A successful RFP process involves a great deal of hard work and coordination. You will need to have people on the committee to help accomplish this.
Once a draft RFP has been developed, have an objective 3rd party look at it. You want it as complete and readable as possible. This can be another local government (maybe one of the ones how supplied you a copy of theirs) or a consultant helping you with the RFP process (make sure the consultant is not planning on bidding on the project).
Preparation of Request for Proposal (RFP)
The RFP document is used to communicate your needs to potential bidders. It will also tell bidders how you want them to respond to the RFP.
Be as specific as possible in defining what you need for your GIS. Provide detailed descriptions of the functionality, services and support you are looking for. It is recommended that you do not use specific brand names of software and hardware products in your RFP specifications. This will limit the number of potential bidders you can choose. There will be situations where specific products are needed. An example is when your organization has a policy in place for using a type of operating system or has already standardized and developed data sets for use in a particular software package. Focus more on what you want the system to do. You will not get what you need unless you specify it clearly in the RFP.
In your RFP, tell the bidders how you want them to respond. Provide examples of what you want: define how pricing should be structured, use standardized forms if appropriate, clearly state criteria for evaluating the responses. You will receive responses that are more consistent and easier to evaluate if you define the response guidelines in the RFP.
To get started, contact other local governments who have recently developed similar RFPs. Use these as a guide. It would be a good idea to contact the person responsible for evaluating the responses. Ask them what worked and what didn't work with the RFP. Adjust your RFP accordingly. Also adjust the scope of your RFP to fit your needs. If you are a small village, don't use a RFP developed by a larger city (or visa-verse) you will not get what you need and the potential bidders will be confused or mis-directed.
Distribution of RFP
You will want your RFP to go to qualified bidders. The best source for this is to go to trade shows or GIS user group meetings and ask around. Again, try to stay objective. Don't get mis-lead by flashy demos or excessive hype. Talk to other local governments and get recommendations of companies they think are qualified to respond to your RFP.
Another method might be to post a notice in GIS trade journals (both regional and national). Be prepared for a large amount of companies inquiring about your project. This method is better used for large, expensive projects.
A bidder's meeting should be scheduled within a week or two of the RFP be sent out. Make sure the time and location is in the RFP. This meeting is used to get feedback from the bidders and to clarify anything not clearly stated in the RFP. It is always an interesting experience to have number of competitors gathered together in one room. There will be a reluctance by the bidders to ask any questions that might give away their bidding strategy to their competitors. Do not be surprised if there are not many questions raised at the meeting. To get things going, have a short prepared statement or presentation that outlines the history of the project and the requirements of the RFP.
It is important to ask the bidders to submit written questions to you in a specified period of time. It is also recommended that all written questions and your responses be compiled and sent back to all bidders. This will provide consistency and fairness in the process.
The purpose of this meeting is to communicate to all bidders what you need and how you want them to respond.
In addition to the written responses from the bidder's meeting, you will need to provide some mechanism for answering ad-hoc questions from bidders. The best way to do this is to require that all questions be faxed or e-mailed to a specific person and provide a response within 24 hours. It would be impractical for your organization to provide these ad-hoc questions and answers to all bidders. It would be a good policy to take questions up to the submission date for proposals. After that date no correspondence between a bidder and people involved with the selection process should be allowed.
Deadline for submission
Establish a deadline for submission. All responses must be in by the specified time and the specified location in order to be considered. Set your time to be a few hours before the close of business. Inevitably a bidder will get stuck in traffic or a courier will be delayed. This will give you a little cushion and allow you time to check in responses while still allowing you to go home at a reasonable time.
Evaluating proposals should be done by the RFP committee with all the members using the same criteria as listed in the RFP. This process should be documented in case a protest arises. If you have been specific defining your GIS needs and defining how bidders needed to respond, the evaluation process should be straight forward.
Sample Questions - Has the bidder:
- Proven they can meet all of the functionality needed?
- Provided pricing that can be compared with other responses?
- Described the types of services and support in an understandable way?
- Provided references and related experience for you to check on?
Criteria for Evaluation
It is important that this process be documented in case a protest is submitted or to explain why a proposal was not accepted. Each of the criteria needs to be measurable or quantifiable.
In the Needs Assessment phase GIS functionality was identified and documented. This documentation of functionality should be defined in the RFP and used for this evaluation. Develop a checklist of the various functions and have each committee member fill out the checklist for each proposal.
Without proper support any system is doomed to failure. Part of the evaluation is to understand the type of support being offered. What kind of response time is being offered and what are the standards. Will the vendor provide answers to a problem within 24 hours of a call? Will they provide on-site vs. factory service for hardware problem? Make sure you are comfortable with the level of service being offered.
Cost / Maintenance Fee
There are a lot of ways to state the price of a proposal. It is recommended that you be specific as possible in the RFP and bidder's meeting about how the price should be structured. The more pricing can be itemized in the proposal the easier it will be to compare the responses to each other. A suggestion is to develop a pricing form for each bidder to fill out and include with their proposal. As a minimum have separate pricing for software, hardware, services and support. More detail for each of these sections would be nice, just don't get too carried away.
Interviews / Benchmark Test (see Benchmark Test Guide)
After the RFP committee has evaluated the written proposals, a "short list" of bidders should be agreed upon. Any proposals that are not in compliance with the RFP or do not rank high in the evaluation should be eliminated from consideration the remaining bidders compromise the short list. Some marginally qualified bidders many need to be eliminated as well to keep the short list of bidders a manageable size. These short list bidders will be invited to a interview and/or a benchmark.
During this process you will be evaluating the bidder on:
- Ability to interact with your organization
- Technical ability
- Ability to communicate effectively
Selecting a Proposal
Once the Interview / Benchmark is completed. The RFP committee members should compile all of their evaluations independently then meet as a group. This meeting should review all of the proposals and begin to focus on which proposal to select. At this meeting questions may arise that need to be answered in more detail. Take the time to get these answers from the bidder before a selection is made (generally a phone call will work but sometimes a follow up interview is needed if practical).
Once all of the committee's questions are answered, it should move quickly to making a selection and notifying the bidders. At this point a contract needs to be put in place that defines the scope of work outlined in the RFP. This contract needs to be executed before any further phase of GIS implementation is started.
Once you have selected a vendor(s) for your system you will need to coordinate the delivery and set up of all of the components. there are many resources to call on to do this. The most obvious being the vendor. They should have demonstrated that they have some level of expertise with GIS and can help you get up and running quickly. It is a good investment to buy their services to install and set up the system for you. These services can be contracted for on a time-and-material basis or under a scope-of-service contract.
The most effective means of describing how to prepare the RFP is to do so by example. The remainder of this guideline consists of selected parts from an actual RFP, - presented here to illustrate the scope, content, and level of detail needed. A properly prepared RFP increases the chances that the vendor responses will be most appropriate to the needs of the local government.
Specifications for a system configuration to support Geographical Information System (GIS) development and operational applications follow. The system configuration consists of various devices that will be networked together to support data capture, storage, processing and display in both digital and hard copy forms, including:
- mapping/analysis workstations (2)
- color laser printer (1)
- black and white laser printer (1)
- cartridge tape drive (1)
- color raster plotter (1)
The proposal shall include technical and functional capabilities of the devices offered to meet these specifications. Provision of the following information should be included for each device:
- model number
- capabilities/configuration of each device in comparison to the device specifications
- documentation provided with the device (i.e., manuals)
- warranty included in the purchase price
- the nature and duration of user support services included in the purchase price such as maintenance agreements, user support and service, and the average time period between requests for user support and on-sit technical service if available.
The Mapping/Analysis workstations will support a wide range of GIS activities, including database development, database quality control, user application development, database maintenance and all GIS applications supported by fully functional GIS software such as cartographic production, geographic database queries, and advanced geographic analysis using both spatial and attribute information. One of the GIS workstations must support high capacity data storage, and multi-user GIS processing, and should perform all GIS operations and applications within acceptable user response times.
General Specifications for Workstations:
- Mass storage may be configured within the workstations' cabinetry and/or as external drives
- The workstations should be configured with a single high resolution (1280 x 1024 or greater) color monitor with at least 19" minimum diagonal screen dimension
- All devices shall include a keyboard and a pointing device such as a mouse
- Each GIS workstation should be network-ready, and should be capable of connecting to a local area Ethernet network and supporting a minimum transmission speed of 10 megabits per second (mbps).
- Multi-user, multi-tasking operating system supporting logical security measures such as user name/password validation, and user access privileges.
- The devices should support virtual memory operations, either through a dedicated hardware controllers(s) or through software (operating system) functions.
- Descriptions of options for upgrading speed and performance through the addition or replacement of boards or other components in the existing cabinetry of the workstations should be provided.
Specific Details of Workstations:
Both workstations should support the following hardware specifications:
- The workstation should include a minimum of a 32-bit processor supporting both 64-bit address and data buses. The CPUs should operate at a minimum of 75 MHz clock speed and/or have enough processing speed and capacity to support other intelligent GIS client devices. These will consist of X-Stations or PCs. The workstations may have multiple CPUs on board.
- The devices should include at least 128 MB (megabytes) of main memory and shall support 32 MB memory modules and be expandable to at least 256 MB.
- The devices should be configured with mass storage disk drive(s) for direct access of data and software functions. They will have a minimum of 3 GB of mass storage each
- The workstations will be configured with a quad speed CD-ROM drives that will facilitate the installation of upgrades to the operating system, installation and upgrade of application software, and user access and review of systems and application documentation.
- The devices should also be equipped with one 1.44 or 2.88 MB floppy drive each
- The server must support multi-user/multi-tasking operations and must concurrently support both server and host workstation functions.
- Vendors shall describe options for upgrading the speed and performance of the server and mass storage capacity through the addition or replacement of boards or other components in the existing cabinetry. Also, Vendors shall describe options for increased performance and mass storage that involve connection of devices external to the existing cabinetry.
Small-Format Color Printer
One (1) color printer will be used for the production of color hard copy graphic plots and nongraphic report generation.
The color laser printer should meet the specifications or equivalent described below:
- Minimum of 300 dots per inch (dpi) resolution
- Minimum 100 sheet paper tray
- Minimum of 4 MB memory onboard with capacity for memory upgrades
- Support for letter, legal size, and 11"x17" paper sizes
- Built-in postscript compatibility
- Serial and parallel interface
Sample hard copy outputs from the proposed device(s) shall be included with the proposal.
Cartridge Tape Drive
The system should include one (1) 4mm DAT tape subsystem for the Planning and Zoning Department. The tape should have a capacity of not less than 5 GB. The tape subsystem will provide a mechanism for performing system and data back-ups.
Large-Format Color Raster Plotter
A color raster plotter shall be included for the production of high quality, large format cartographic products. This device must provide a high-volume color plotting capacity. The plotter shall support 36" x 42" plots and produce color plots at a minimum resolution of 300 dots per. The plotter shall be compatible with the proposed LAN hardware and communications protocols and must be accessible by all workstations on the LAN. A sample hard copy output from the proposed plotter(s) shall be included in the proposal.
Additionally, the plotter shall meet the specifications described below:
- Capable of supporting true color plotting
- Minimum of 8 MB memory onboard with capacity for memory upgrades
- Support for all paper sizes, A through E size
- Built-in postscript compatibility
- Serial and parallel interface
Provide four (4) replacement paper rolls with the printer. The paper should be a high quality glossy bond.
There is a requirement to connect new hardware in two departments. Existing software consists of Intergraph's I-Dispatcher, emergency response dispatch system. Requirements for each level of communications are outlined in the section below. Vendors shall state the level of compliance and provide a description and cost quotation for all hardware and software components needed to meet the requirements at each level of data communications. Vendors should include in the cost proposal the cost of any specialized hardware devices that will be required to implement the proposed communication network.
Network Processing Requirements
Network processing requirements are as follows:
- Storage of data which is accessible by users on the network by specifying particular files, collections of features or attributes, and geographic areas
- Access security to allow assignment of different levels of access rights to portions of the GIS database by user name or physical device
- Ability to support query workstations on the network, directly connected to the server, or connected through remote communication lines so that network users can have access to these devices and vice versa
- Ability to allow database queries directly from workstations on the network without the need to download data to workstations
- Ability to allow network-wide access to plotters and printers, all with print/plot queries for generating hard copies
Network Management and Monitoring Capabilities
The proposed physical network should also be able to perform the following network management functions:
- Access to data on remote nodes by reference to the node, disk, directory, and file
- Access to programs on remote nodes by similar reference
- Assignment of logical names or aliases for programs or data locations on remote nodes
- Control of peripheral devices from any node on the network
- Passing of mail messages across nodes
- Program-to-program communications across nodes
- Monitoring of traffic and errors on the network
The proposal shall include all cabling and devices required to implement all data communication connections, utilizing existing facilities.
Network Speed and Capacity
The proposed system must operate at a minimum raw data speed of 10 megabits per second. The Proposer shall provide information about the upper limit in numbers of mapping/analysis/query workstations that can be supported without major degradation in response time or error rates on the proposed network.
Transactions and Data Exchange with Existing Systems
Initially, the GIS network will not support on-line links with the existing IBM mainframe. Access to data residing on the mainframe will be accomplished by downloading data onto 9-track tapes and then re-writing this data onto current industry standard media such as 4mm data tapes or CDs.
Software Component Overview
The GIS software components shall fully support and exploit the capabilities of the proposed hardware platform and shall provide full functionality for entry, editing, maintenance, analysis, display, and hard copy output of both graphics and tabular data on a continuous and interactive basis.
For purposes of this procurement, software component capabilities have been grouped into the functional categories of:
- Database structure
- User interface
- Data entry
- Data editing/maintenance
- Data query and analysis
- Data display/output
- Application development
- Operating system requirements
Data Editing And Maintenance
The proposer shall describe the tools and capabilities of the proposed system to modify and manipulate spatial and attribute data in the GIS for the following categories:
- Interactive Graphic Editing
- Attribute Editing
- File Copying
- Deletion of Features
- Edit Controls
- Rubber Sheeting
- Coordinate Registration and Transformations
- Quality Control/Error Detection
- Merging, Extraction, Edge Matching of Data
- Data Transactions, including the capabilities of the proposed system
to translate data into and out of the following formats:
- GFIS to Proposed System Format (specify how attribute data is addressed
- AutoCad DXF (specify how attribute data is addressed)
- AutoCad CWG (specify how attribute data is addressed)
- Intergraph IGDS (specify how attribute data is addressed)
- USGS DLG and DEM
- TIGER Line Files
- ArcInfo Export Files
- Exchange data with KVS Computer Assisted Mass Appraisal (CAMA) System
Data Query And Analysis
The proposed software shall support the following data query and analysis capabilities:
- Graphic Data Query
- Area/Perimeter/Distance Calculation
- Attribute Data Query
- Spatial Aggregation
- Buffer Analysis
- Address Matching
- Polygon Overlay Analysis
- Linear Network Analysis
- Area Districting and Zoning
The data display and output tool capabilities that the proposed software shall support including the following:
- Graphic Display
- Tabular Display
- Raster Image Display/Production
- Vector Map Overlay
- Hard Copy Map Production
- Hard Copy Report Production
- Map Plot/Display Relationship with Scale
- Graph/Chart Production
- Interactive Map Composition
The Proposer shall propose one of more software components that, in a well integrated manner, provide the following capabilities and features:
- Menu Design and Custom Application Development
- Programming Features
- Supporting High-Level (4 GL) Programming
- Subroutine Libraries
Basic Operating System Requirements
The operating system component of the software shall be the primary operating system of the proposed hardware platform and shall provide all of the traditional features of current operating systems as described below:
- Multi-user Support
- Multi-tasking, Multi-threading Support
- Security Management
- File Management
- Memory Management
- Database Backups
- Error Monitoring/Disaster Recover
- System Diagnostics
- Anti-viral Protection
- Electronic Mail (E-Mail)
Network Management Functions
The proposed system shall provide capabilities for monitoring and managing all data and devices on the GIS network as one unified system and support the following capabilities:
- Multi-user Database Access and Maintenance
- Monitoring of network Activity
- Network Problem Diagnostics
- Print and Plot Management
A GIS database model defines the nature and usage of spatial (geographic)data with a database. The proposed software shall support a spatial data model that is capable of creating, managing, and manipulating data sets, defined on the basis of spatial coordinates and associated attribute data sets.
Feature Types: The data model shall support multiple feature types including point, node, line, polygon, and text features
Data Storage: Features shall be stored as double precision x and y coordinates
Data Types: The data model shall support multiple graphic and nongraphic data types
Database Organization: Vendors shall describe strategies for organizing data into logical groups on the basis of data themes, and shall describe the capabilities of the data model for supporting simple and complex feature types.
Topological Data Structures
The geographic data model shall support the creation and maintenance of topological data. Topology shall be created through execution of a software function to structure graphic data sets. Vendors shall describe the ability of the proposed data model to support logical polygons, networks, and user-defined topological structures.
Software capabilities that support large-scale engineering and design activities should be outlined as well as specific engineering functions and appropriate modules.
Raster Image Data
The Proposer shall describe support for storage of raster map images (e.g., scanned bluelines, orthophotos) and for raster scanned documents.
Continuous Geographic Database
The geographic data model shall support the creation and storage of a continuous geographic database
Relational Database Management System
The Proposer shall recommend a relational database management system (RDBMS) that will be able to maintain a minimum of 30,000 records of parcel ownership information in a single table and shall provide functionality for updating database content, queries, and production of reports. The recommended RDBMS must be either a part of the GIS software or have a direct access capability.
The RFP sections presented above give a good example of the scope of topics and level of detail needed. This particular RFP did not present a conceptual data model for consideration by the vendors, but rather specified general characteristics for the GIS data model required. An actual conceptual data model, rather than its general characteristics, could be more useful to vendors, and thus more productive for the user's organization.