Iain McKay, Jillian Clark, and Roy Morgan

Property Management and Mapping with ArcInfo

Synopsis

This paper will briefly the describe the history of ArcInfo in the Department of Estates, Strathclyde Regional Council and detail the development of two major applications.

The first of these will describe the establishment and maintenance of a large corporate mapping database of Ordnance Survey (Great Britain's National Mapping Agency) data at scales from 1:250,000 to 1:1,250. Some of the issues encountered during this will be raised.

The second application is the Property Management System which has been developed to provide an integrated tool to manage the Regional Council's property portfolio. It makes use of both ArcInfo and ORACLE and combines information about location, value, use and maintenance of some 16,000 property interests.

The links between the two applications will be discussed and some thoughts will be given as to the future direction of development taking ArcStorm and ArcView2 into account.


INTRODUCTION
Strathclyde Region covers an area of some 13,000 square

kilometres in the west of Scotland. It has a wide diversity of

topography ranging from densely populated urban areas such as

Glasgow to sparsely populated rural areas including islands such

as Mull, Islay and Tiree. The Regional Council provides a range

of services to the 2.3 million people who live in the region.

The Department of Estates is involved primarily with the management of the Council's property interests. ArcInfo has been used to assist the management of property related information in the department since 1988. The GIS Applications Support Unit has developed several applications and this paper describes the two most significant developments, the Mapping Management and Display System (MMDS) and the Property Management System, and highlights some of the problems encountered during their development.

MAPPING MANAGEMENT AND DISPLAY SYSTEM
Background mapping is of great importance to any GIS application, as often the user's data is relatively meaningless unless there is something to display it against. This became apparent in the first application developed in the department, which involved the collection of Grounds Maintenance (Landscape Maintenance) data for a Country Park with an area of about 11 sq. km. This application required the acquisition of some 44 tiles of 1:1250 scale mapping from the Ordnance Survey, the national mapping agency in Great Britain. The Ordnance Survey (OS) supply a comprehensive range of mapping products in digital format which are suitable for use in GIS applications.

After the successful implementation of the original application the Department was given the task of a similar region-wide data collection exercise which required the acquisition of all the OS large scale mapping available at that time.

As other Regional Council departments became aware that digital mapping was available and the possibilities it provided, more and more requests were made for both digital and conventional mapping products. It quickly became apparent that what was originally acquired to support other datasets had the potential of providing a feasible service which would initially strengthen the case for further GIS development. This service is now a major area of work for the Department as it is now the custodian of the Regional Council's Corporate Mapping Resource. The main OS datasets used by Strathclyde Regional Council in the MMDS can be categorised as base scale mapping and strategic mapping.

BASE SCALE MAPPING
Vector data at scales of 1:1,250, 1:2,500, 1:10,000 depending on density of buildings. As some of the 1:10,000 data for rural areas is not yet available in digital format, complete coverage at 1:10,000 scale is provided in raster format. These are the most frequently used OS mapping types in the Regional Council.

STRATEGIC MAPPING
Data at scales of 1:250,000 and 1:50,000 in vector and raster format respectively.

This mapping has been acquired over a period of several years as the data and funding became available. Various configurations of ArcInfo libraries and image catalogs have been tested, as more data was obtained. The present one has now been established for three years and is outlined below.

The large scale vector 1:1,250 and 1:1,2500 mapping is held in one library. This contains some 2.4Gb of data in over 8,000 tiles, covering a ground area of 5,488 sq. km. The mapping server is a SUN Sparc Station 10/40 with 1 x 8.4Gb and 2 x 4.2Gb disc packs with the tile directory striped across three SCSI controllers to give uniform fast access.

The 1:10,000 scale vector data is held in some 800+ 5km x 5km tiles, as is the 1:10,000 scale raster image catalog. This data takes up some 212Mb and 380Mb of disk space respectively and is also striped across controllers.

The 1:50,000 scale raster data is held as 80, 20km x 20km tiles and occupies 1.25Gb of disk space.

The 1:250,000 scale vector data is held as 50km x 50km tiles and occupies 70Mb of disk space.

The total disk space used for storing mapping data in the MMDS is around 4.4Gb. The functionality of the MMDS includes:

1. Efficient loading and conversion of raw data into ArcInfo libraries and image catalogs. 2. Effective management of revisions 3. Easy to use 'point and click' display and output application interface.

One of the biggest problems in using large scale mapping is the need for a gazetteer to accurately locate the area of interest when the area of display on the screen may only be 100m x 100m or less, depending on the display scale. The MMDS uses a file of Postcode information purchased from the Royal Mail which provides a National Grid coordinate for groups of fifteen addresses, correct to 10m and this is held as an ORACLE table.

The urban areas covered by the 1:1,250 and 1:2,500 scale mapping are those which change rapidly and this means that the question of currency of mapping data becomes significant, as does the ability to track revisions. Considerable effort has been placed into the provision of a system to manage this as an integral part of the application, with an on-line ORACLE table of map header revision information being directly accessible from the display system.

PROPERTY MANAGEMENT SYSTEM
The primary function of the Department of Estates is the management of the Regional Council's property portfolio of some 16,000 identified property interests including schools, administrative offices, police and fire stations and homes for the elderly.

The efficient management of this portfolio relies on information systems capable of providing all the appropriate data about the relevant properties as simply and quickly as possible. Traditionally, this relied on paper files of correspondence and associated plans and drawings. This gradually evolved to textual records being stored in files on a main-frame computer, and from there to a plethora of loosely related PC based 3GL database applications.

The increased use of GIS in the department began to show some of the potential benefits to be gained from the adoption of an integrated Property Management System. Previous GIS successes were used to re-inforce the argument for concentrating resources into this development and the approval of senior management was given to re-engineer the property model to emerging national statndards.

The initial planning stages of the application lasted for around eighteen months and included user requirement studies and an unsuccessful attempt at producing a tight specification for the final system. Accepted IT policy concentrated on the specification of systems and then producing systems to meet the specification. Experience has shown that with a GIS application, this is not a feasible method of working. Problems were encountered as users were unaware of the potential benefits to be gained from GIS, therefore could not be expected to state what they wanted. A long process ensued, with the GIS development unit having to explain each module and its proposed functionality to users, whilst themselves learning about the new tools available in ArcInfo. This was compounded by the requirement for a suitable RDBMS to manage the textual aspect of the application. Until this stage INFO was used as the database management software. A decision was taken to acquire the ORACLE RDBMS and standardise all development on it, primarily using ORACLE's CASE tools.

Against this background, the GIS unit decided to adopt a development strategy which was based on a modular approach. The following steps were followed:

1. A core database model was designed which would be flexible enough to support any future application. This was based around the concept of a property being treated as an object, which could be made up of an infinite number of associated objects.

These property objects could have a variety of object types (or classes) depending on the functionality required. For example, a school would be a object of type "property". It may be comprised of many other objects of different types such as land parcels, valuation objects, maintainable features and running costs. Each object type is pre-defined and as requirements change, the range of types can be expanded.

2. A general list of required functionality was produced to define the major modules of the system. This was matched to the department's business requirements and a delivery order was established. i. A Valuation Module to allow the valuation of the entire Regional Council property portfolio. ii. A Grounds Maintenance (Landscape Maintenance) Module to allow the management of contracted work. iii. A Terrier (Land Parcel) Module to allow the definition of the extent of legal ownership at all Regional Council properties and to maintain a historical record. iv. Modules to deal with the buying and selling of properties and thus keep data associated with the first three modules up to date. v. A Lease Management Module to deal with the rented property portfolio.

3. The GIS unit's resources were allocated so that resources could be directed towards learning the appropriate skills, especially with ORACLE our selected RDBMS, and testing the relevant functionality of the software to ensure that it would be able to provide solutions 'as advertised'. The new functionality provided by ArcStorm and Regions in ArcInfo Release 7 has been included in the design strategy.

The entire application has been developed with the aim of producing a simple but powerful system which brings together all property information in an easy to use 'point and click' menu driven system. As more information is included in the system and the modules have come on-line the value of the GIS aspect of the system is becoming increasingly accepted.

Due to re-organisation of local government in Scotland, Strathclyde Regional Council will cease to exist after the 1st April 1996. This will involve distribution of the property assets amongst twelve smaller authorities, largely on a geographical basis. It is somewhat ironical that the demise of the organisation has finally proven the worth of a GIS based Property Management System and the geographical aspect of the property data has now become crucial.

ISSUES
This section is intended to highlight some of the issues raised during the development of the applications referred to in this paper. It is certain that many of them will be familiar to any organisation involved in developing large applications.

The GIS Applications Support unit began with two surveyors, with some previous exposure to computers, being given PC ARC/INFO to solve a particular problem. As the complexity of applications increased with time, the unit increased in size to six. The skills required to develop successful applications have increased considerably and the unit has had to learn about ORACLE, ArcInfo and UNIX System Administration. The increase in numbers of developers leads to management issues such as allocation of work and avoidance of the duplication of effort.

The production of binding, written specifications for GIS applications is virtually impossible for several reasons. Potential users of applications are unlikely to be aware of the functionality which the GIS package can supply and therefore cannot be expected to be able to specify it. With some of the major new functionality e.g. ArcStorm, there is a period of time required for the developers to test it, to ensure that their understanding of what it is supposed to do, matches what it in fact does. Meanwhile the organisation moves on and priorities change. It can be argued that it is more productive to design applications in ways which are better suited to change, using a more object oriented design philosophy.

In the Department of Estates experience a range of different skills are required to develop applications. It is also true that several suppliers both of software and hardware are relied upon. The department currently uses SUN workstations, Calcomp and Hewlett Packard Plotters, ArcInfo and ORACLE software. The suppliers are all operating in a rapidly changing technological environment and products can change monthly. This leads to problems in trying to keep up with upgrades. These have increased as the systems have grown and it is now estimated that 30% of our development time is devoted to trying to keep everything working whilst trying to upgrade either software or operating systems. It is not unheard of for any one supplier's helpdesk to deny the existence of problems, until proven to be at fault. This is a major issue of concern to us as it makes it very difficult to formulate and implement a development strategy.

The two applications described in the paper are potential users of ArcStorm, as the data is held in ArcInfo mapping libraries. The management capabilities of ArcStorm are a major feature in the design of the graphical database for the both the Grounds Maintenance and Terrier applications. These datasets are dynamic, with many people being responsible for their maintenance and update. Problems have been encountered frequently with two people trying to update the same coverage. The testing of ArcStorm suggests that this will be the solution.

The Ordnance Survey mapping datasets are different as they are supplied in tiles and updates are received quarterly. Currently there are no plans to use ArcStorm for this application.

The disaggregation of Strathclyde Regional Council has been referred to earlier in the paper. It is anticipated that the applications described will continue to be used and developed by at least some of the successor authorities. There is a promotion exercise underway at present aimed at raising the profile of the GIS applications developed by Estates. There is inevitably an element of promising solutions on the strength of what has been said about the functionality of new products. Experience has shown that this can be a dangerous, or at least embarrassing, practise. It would be a comfort if all intended functionality worked as advertised and preferably at the time of release.

CONCLUSIONS
The Department of Estates has been using ArcInfo since 1988. Over this period usage has increased from one PC licence to the existing set-up of sixteen workstation licences and applications have become increasingly sophisticated. At the outset, the problems and difficulties encountered were largely due to lack of knowledge of ArcInfo. As the applications developed and migrated onto a UNIX platform new skills had to be learned to maintain and develop the system required to support the GIS.

Whenever the decision was made to use ORACLE as the database manager, the same learning curve was encountered, as well as the enhancement of existing skills, as ORACLE impacts on both ArcInfo and the operating system. This has led to a threefold increase in the size of the team required to support the applications. As the scope of applications increases, either progress slows or the number of developers increases, requiring a business decision as to which option best suits the circumstances of the organisation.

As applications become more complex, the question of user support and training becomes more critical. The developers have to spend an increasing amount of time in supporting and documenting the applications, as well as in training users. The result of this is an inevitable reduction in development effort. This too requires a business decision concerning additional resources, if development paralysis is to be avoided.

The nature of the entire IT business is such that it is constantly moving forward. Unfortunately this forward motion is not uniform amongst vendors, as new, usually improved, products appear constantly. The difficulty of systems upgrade management for IT users is, in the Department's experience, directly proportional to the number of vendors' products used.

Vendors descriptions of what new or improved products are designed to do are related to this forward progress. When attempting to put the case for increased investment to management, there is a temptation to include improved functions or new products which are not fully tested. This is a practice which can easily become unstuck, especially if delivery dates are rashly promised.


Iain McKay, Jillian Clark, and Roy Morgan
Strathclyde Regional Council
Department of Estates
Dalian House
350 St Vincent St
Glasgow G2 4PF
Scotland
Telephone: 0141 249 4122
Fax: 0141 249 4016