Development of Customized Tools for GIS Modelling to Incorporate Flexible Decision Making

Geographic Information Systems (GIS) and associated modeling enables rational management of spatially distributed resources. GIS models once assembled with a base data set often require many repeated computations either to seek modifications to the methods or assumptions made during computations. The common GIS software needs customization to cater to such changes with minimum requirement of time. These repeated tasks range from computing an area to reclassification of overlaid layers. This paper presents the development of two simple tools. The tool for computation of area, centroid or length, enables the on-screen operation to save computed values in particular shape file. Tool developed for the classification of spatial information after overlay, demonstrates the tool's capability to easily change the classification criteria to suit a change of values or grouping based on a subsequent decision maker requirement. Both tools are developed using the Microsoft Visual Basic and linked to the GIS software ArcGIS 9.2, incorporating the systematic planning, design and evaluation methodology. A special consideration was paid to 100% accuracy of the outputs, usefulness and user friendliness of the tools. Hence the work follows the standard requirement assessment, systematic software evaluation with appropriate user group selection. The tools demonstrate the capability through applications on actual datasets.


Introduction
Geographic Information Systems are tools that enable rational management of spatially distributed resources. This means that often a GIS enables interaction with either one or many map layers. In the decision making process it is common that the basedata leading to several rational alternatives are prepared [24], at several management positions in an organizational hierarchy. Under these circumstances, a data model developed by a GIS expert following an agreed concept would require repeated computations or repeated decision modifications. Though repeated computations are faster when working with computers, the speed of an activity often depends on number of tools to be used, number of working windows, number of clicks required for a particular operation, menu selection sequence, reaction time of a person etc. Therefore, when working with GIS databases repeated computations with changes to a model concept would consume a considerable time [14]. Significant time consumption for repetitive work tends to affect the quality of outputs since there could be a lethargy to execute repetitive work specially when such works require significant time and effort.
The strength of GIS is to provide or facilitate alternative options with ease. As such it is necessary to identify repetitive works which normally consume a significant time, and then find ways of reducing time delays by optimising the intermittent operations.
One of the common tasks that require continuous computation is the calculation of either the area, perimeter or centroid of a polygon. In most of the off-the-shelf GIS software such as ArcGIS, the area of a polygon, perimeter or centroid can be calculated by incorporating scripts to run on a built-in computation tool. This operation has to be repeated from map layer to map layer or whenever calculations are required. ArcGIS software provides a measurement tool with an interface which enables drawing of a polygon to compute area, perimeter etc. This tool eases the computations to a reasonable extent, but does not facilitate quick and accurate information due to the reason that a user has to carryout mouse positioning and clicking along the entire drawn polygon and then save to an attribute table or to an appropriate software. This also does not often provide accurate results because digitizing over the existing nodes would encounter certain accuracy issues. Therefore, it is often found that a tool capable of carrying out simple computations on an already drawn polygon and then saving of the data would be of significant benefit for GIS users who attempt to carryout these calculations many times on various features and involving multiple layers.
In Literature there are several automated options, such as "Easy Calculator 5", "ET Geo Wizard" [6], "Tools for Graphics and Shapes" [19] for such calculations. However, the fundamental issue with these tools is unavailability of on-screen outputs.
Another common need of GIS users is the speedy reclassification of attribute table datasets after an overlay operation. This work consumes a significant time because a reclassification always requires many conditional table operations necessitating calculations on a selected set of features. Time consumptions for reclassification usually become excessive when decision makers tend to make changes to the model concept or parameters. At most instances GIS experts feel the importance of having a flexible lookup table for reclassification. An easy lookup table modification which can be directly fed into a GIS overlay operation for the generation of a reclassified layer would provide a definite advantage to the GIS modeller. Since the objective is to reduce time taken to effect decision changes with respect to reclassification criteria, development of a tool to carryout such tasks would be very effective if on-screen changes could be directly incorporated to a ArcGIS map layer.
A literature search did not reveal the development of a similar tool except for identifying the possibility of using macros. [9,20,21]. The present work describes the needs assessment, tool development, tool testing and application, with regard to two tools developed for: (i) Simple computations such as area, perimeter and centre of gravity; and (ii) to carryout easy reclassification of a map overlay output.

Objectives
The objective of this work is to develop two GIS tools incorporating user friendliness and saving of user efforts for computations: (ii). Reclassification Tool (Classic))) -A GIS Graphical User Interface to carryout reclassification of data layers resulting from a map overlay operation.

General
Rapid Application Development (RAD) method of software tool development which is a variation of the prototyping models was selected for the work due to advantages of obtaining early user feedbacks and capability to adopt to rapid changes [3,15]. Overall Approach taken to develop the tools is shown in Figure 1.0.

Interface Design
Since the most important aspects of User Interface (UI) development are the ease of learning and ease of use [18], guideline directions were followed to ensure an iterative design process, Visual clarity, consistency, compatibility, informative feedback, explicitness, appropriate functionality, flexibility and control, error prevention and correction, and user guidance and support with respect to both tools. [10,16,17,18] .

Requirement Assessment
A requirement assessment through a simple questionnaire survey of 71 GIS users, who belong to various organisations, identified needs of GIS users. The questionnaire assessed; Only 18% found the present methods on ArcGIS as either very easy or easy while 82% found as either satisfactory, difficult or very difficult. 71% indicated that not only the computed values should have the capability of saving data in attribute file, it should also permit the attachment of values to the clipboard. 64% of the sample preferred the Simple Computation Tool to be incorporated as a button on the standard ArcGIS tool bar. With regards to the Reclassification Tool, 72% opted for a similar button enabling an on-screen Graphic User Interface (GUI) so that adjustments to classification/ reclassification parameters could be made.
In Sri Lanka the most widely used GIS software is ArcGIS [22]. A worldwide survey done in 2000 [1] had indicated that ESRI with 23%, has the greatest market share by a single GIS software vendor. Daratech 2001[2] had indicated that ESRI has increased this share to 35%. Therefore the tool development efforts were carried out for the ArcGIS software because of the greater number of users that would be benefited by the tool. Due to similar reasons and also since ArcGIS facilitates Visual Basic (VB) as the development language, which has also been indicated as user friendly [7]. Interface development was carried out using Visual Basic Language.
GUI was initially developed using Visual Basic for Applications (VBA) and with ArcGIS to use advantages of easy bug fixing. At the final stages of tool development, the tool was migrated from ArcGIS environment to VB. This proved easy for the finalization of tool as a DLL. A DLL was identified as a better option for transferability and flexible installation [25].

Conceptual Design and Process Flow
Conceptual design included a simple process (Figure 2.0) indicating the ability to save computed feature information.
Process flowchart for VB coding is shown in Figure 3.0. The tool permits the selection of either a polygon, polyline or a line and based on selected decision criteria incorporates computational procedures. Tool coding was limited to the development of coding components other than the basic VBA procedures in the ArcGIS help file.

Development and Verification
PolyCal Tool was developed as a button on ArcGIS toolbar that has an input component of identifying the required features on the topmost ArcGIS layer. Coding for this component was written in VB using sample scripts as initial guidelines [4,5,8,11]. In order to save time, coding efforts opted out the use of an explicit  message action to initiate processing of data. A feedback message was incorporated to indicate satisfactory data capture. Coding for computations utilized the VB coding of individual components presented in the ArcGIS help file and adjustments were suitably incorporated to cater to multiple features. Coding was completed using VBA.
Output form design to suit user requirements was based on a consistent label format, standard font and clarity of wording. Simple texture formats were used for visual clarity. Colour selection coding was restricted to MS Windows standard colours enabling user friendliness. Output form was coded in such a way to avoid the modes and to be positioned as the topmost layer to ensuring better user control, while enabling simultaneous ArcGIS layer operations without disturbance. A logical organization of fields in output form facilitated the extraction of output data, selection of save location, and execution of save to be carried out in a sequence  perspectives, a black-box testing methodology was adopted [3] through a beta-version. Testing of the tool was carried out with three evaluations (Figure 1.0). Internal evaluations included tool evaluation for the process and accuracy of computations, and also for the easy operation capability of GUI. Accuracy evaluation was done for the feature selection accuracy, and relevant computation accuracy ensuring values acceptable for standard user applications. As part of result verification process computational accuracies of the tool were compared with manual computation of regular geometric shapes. Manual computations with five types of geometric shapes varying in size revealed 100% accuracy with tool At the second level of evaluation, a self selected sample [12] of GIS users was used. Observations were made on the number of errors, catastrophes and user acceptance [16], while each user was applying the tool for his/her own datasets. Evaluation was considered satisfactory once the catastrophe level reached zero. Summary of testing results after three beta versions is shown in Table 1.0.
Final testing was based on a questionnaire survey to identify user response on various aspects such as GUI status, acceptance, security, speed of work, friendliness etc. As it was difficult and costly to evaluate the product using a geographically dispersed random sample [12,23], the Cluster Sample Method was used with 30 ArcGIS users. The evaluation questionnaire development was based on the framework for system evaluation [13], Usability aspects [16], and common threads of Usability testing [2]. The Likert Scale [23] with a 1-5 qualitative classification representing Strongly Disagree, Disagree, No Opinion, Agree and Strongly Agree, was used for assessment. The responses of users were aggregated using rank reciprocal method (Table 3.0).

Reclassif ication Tool -Classic})
Start Select layer to reclassify

Select attribute fields
Fill the on-screen Re classification Matrix

Conceptual Design and Process Flow
The conceptual design included a process flow as shown in Figure 5.0. Flowchart for VB coding is shown in Figure 6.0. Tool permits the selection of two source columns from a given map layer for the development of reclassification criteria and then the creation or selection of a destination column to save the reclassified value. Further, the tool draws a graphical representation of reclassification matrix utilizing the selected source columns, whilst allowing onscreen filling of particular reclassification values in the matrix. Classic)) ends its task with the updating of attribute table by the values according to decisions indicated on the reclassification matrix. This work involved a significant coding effort other than already available VB/VBA procedures with ArcGIS VB Desktop help files.

Development and Verification
The Reclassification tool Classic]) was also developed as a button on ArcGIS toolbar and the coding procedures were followed similar to the previously described tool. However when coding, special care was taken in the development of GUI, since the tool is intended to facilitate a graphical coordination of a logical process which consists comparing and updating of data fields and field combinations.
Therefore during tool development, the usability principles, desktop integration, Windows, controls, feedbacks, Visual Design and Language were given significant emphasis [10]. A sample of input forms is shown in Figure 7.a and 7.b.
A GUI consisting of two tabs where the Tab 1 prompts a user to select classification layer, output field and layer priority coding. In Tab 2, these details are graphically arranged to depict a two dimensional matrix operation. The graphical matrix operation facilitates the user -"' ' /Sort the Order of Column' / 1&2 \ Tool will automatically identity classes from an  with a visual picture to rationalize the selection ,of reclassification and then to store output data in a designated column through an explicit action button to initiate reclassification.
Testing of the tool was carried out similar to the previous tool and with same user groups. Computational accuracy of the tool compared with a manual operation using ArcGIS menu functions, revealed 100% accuracy of tool computations.
In case of Beta-Version evaluations with self selected sample achieved a zero catastrophe level at the fifth beta version (Table 2.0).
Final testing was based on a questionnaire survey to identify user evaluation of various aspects such as GUI Status, acceptance, security, speed of work, user friendliness etc. Results pertaining to an assessment on a 1-5 class Likert Scale are in Table 4.0. Evaluated products were further assessed for performance with the comparison of time and a click count with common methods. The simple computational tool was named PolyCal due to its capability to calculate parameters pertaining to both polygons and Polylines. The reclassification tool was named Classi, considering the brevity of name and also its function. PolyCal was compared with computations done using Field Calculator tool and Calculate Geometry tool of ArcGIS. Classi was compared with; (i) Straight forward attribute selection and update by field calculator method (Method 1) and (ii) The method of computing with the use of an ArcGIS Macro (Method 2).

Time and Clicks
Both tools showed very satisfactory advantages with respect to time and effort for task execution (Table 5.0, 6.0, 7.0)

Application
PolyCal and Classic)) were both tested on two applications using actual geographic data. Classifj) was used to classify two data layers of Hambantota District to arrive at a layer of combined preference considering performances corresponding to Landuse and Proximity to    2. The tools, systematically developed through a rigorous methodology, ensured that the major concerns such as effective use of standard operations, system functions pertaining to colour selection, copying or mouse clicks have been incorporated to achieve user consistency. Functionalities such as, enabling an ArcGIS user to easily move from computing window of the tool to project layers, were specially targeting user friendliness. GUI of Classic)) enabled a user to identify feature names and attributes automatically extracted from the table thereby eliminating computational errors due to erroneous fields or attribute naming.
3. Tool development evaluations indicated that the use of simple tools could reduce the processing speed significantly while ensuring the user friendliness. Time reduction and click reduction of the PolyCal was approximately 96% and 70% respectively. The Classi(|) showed that a time saving of about 66% would be achieved during a single reclassification operation when compared with the use of a macro. This indicated a clear advantage of having tools developed for general uses such as those carried out by PolyCal and Classi()>.
4. The developed tools indicated a part of their potential through the use of actual case study data thereby enhancing the user confidence. The evaluation of software using standard methods, appropriate user samples and acceptable evaluation indicators have enabled the development of the tool ensuring user requirements. The PolyCal and Classic]) both were finalised at zero catastrophe level. However, Classic)) had a 100% user acceptance while PolyCal had 92%. This reflects that the user sample fully accepts Classic)) for usefulness but does not accept usefulness of PolyCal for their work. Since this can occur due to a bias in the sample, and also that the catastrophe level was 0, the tool development was concluded.

Conclusions
1. The development of two ArcGIS tools was achieved by incorporating systematic planning, design and evaluation methodology.
2. Both tools PolyCal and Classic)) showed excellent results in relation to accuracy, usefulness and user friendliness.
3. In the development of both tools, the requirement assessment, systematic evaluation with appropriate user group selection, followed by a demonstration with actual spatial data, proved as very important factors for successful achievements.
4. PolyCal and Classic)) tools both showed a time saving potential of greater than 66%.