The metamorphosis of GIS – Is AM/FM dead?

The metamorphosis of GIS – Is AM/FM dead?

Bud Porter
AM/FM Industry Solutions Manager, ESRI, Inc.
5216 Old Mountain Lane, Powder Springs, GA 30127
bporter@esri.com

Historical Perspective

When Hardware Was King
It was January 1982. The third largest independent Telephone Company in the U.S had just hired me as their corporate manager of outside plant. One of my first assignments was to cochair a project to automate our department’s engineering and plant records. Only later did we learn that the industry called this an Automated Mapping/Facilities Management (AM/FM) System.

Even though this effort was relatively early in the evolution of AM/FM systems, we knew that other telephone and utility companies had had similar systems in place for several years. The difference was that we wanted our system to not only automate the drafting and records-keeping processes, but also eliminate the separate drafting step by allowing the engineers to design directly on the system, yielding a work order as a result. So, as far as we knew, this was the first time that direct engineering design and work order generation was a functional requirement of an AM/FM system. Aside from design, our system would also have to perform productivity functions such as rippling of cable count changes and providing loop-make-up reports. Obviously these requirements dictated that the system use a connected-network topology.

As we investigated the systems available, we discovered that there was a separate class of computer graphics system that also operated using a geographic base map. These provided various analytical functions relating to land areas or the coverage of environmental resources. These systems were built using a polygon-based topological data structure rather than the connected-network model of AM/FM systems. They were called Geographic Information Systems (GIS) or when used for parcel mapping by local governments, Land Information Systems (LIS).

A common thread between these two types of systems was that the hardware component was a major consideration of system design. Systems were implemented using a mainframe or minicomputer that were directly connected to dedicated graphic display terminals, either manufactured by a third party or manufactured by the AM/FM vendor. In those early days, it was not untypical to spend the better part of a $Million on the CPU and supporting hardware such as external hard and tape drives, memory and specialized boards that communicated with the graphics display terminals.

Color – At A Price
The very first demos that our evaluation team saw were based on vector-based, storage tube graphic display terminals. These were typically monochrome (usually amber or green) and displayed the image by a stream of electrons that would “trace” the vectors (including text fonts) of the map on the screen. The problem with this type of display was that as the complexity of the map increased, the resulting image would dim. Thus there was a practical limit to the density of the data being displayed. Fonts had to be extremely simple or they would significantly degrade the image.

At this same time, a couple of the major AM/FM vendors had relatively new or just announced raster display terminals. This type of display used a CRT (cathode ray tube – as is used in today’s monitors) instead of a storage tube and was not susceptible to dimming because of data density. It presented its own problems, though. The vectors contained on the map had to be “rasterized”. Thus an additional processor was required in the display terminal. A high-speed communications link was also required to connect to the main computer or CPU (central processing unit). Typically the connection hardware and protocol used in this connection was proprietary to the vendor, as there were no standards for such at this time. As these displays replaced storage tubes, a typical configuration used two 19” displays on top of an integrated digitizing table. The manufacturers called them graphics workstations. We affectionately called them two-headed monsters.

As we planned our hardware expenditures, we determined that a maximum of eight of these workstations could be connected to the CPU. Even then, response could be slowed significantly in this configuration. A dual monochrome 19” graphics workstation went for around $60K. If you wanted color, you had to add at least $10K for each color CRT used instead of the standard monochrome.

Proprietary Graphics and Flat File Databases
As far as the software was concerned, both GIS and AM/FM systems linked non-graphical information or attributes to graphical entities. The graphical engine employed in these early systems was unique to the particular vendor and the graphics were stored in proprietary formats, separate from the non-graphic or attribute data. The non-graphical information typically was stored in either flat files or hierarchical databases.

Geographic Information Systems differed from AM/FM systems in that they dealt with the underlying geography directly, rather than as simply a means to display facilities. That is, they dealt with polygons as well as line and point features, and could easily handle more complex spatial relationships of those features. They used a topological data model whose graphic primitives included points, arcs and polygons. Therefore these systems modeled the relationship of geographic features to one another well thus being able to, for example, display point symbols within an area, or determine the closest distance between features.

Later, telephone companies and utilities that had implemented AM/FM systems found that their use was limited to analysis and management of facilities and they could not easily perform spatial analysis. Many found that they had to implement both systems – AM/FM in their planning or engineering department and GIS in their marketing or customer service department. A system that could perform both facilities and spatial analysis was needed.

(Geo-) Relational and Standard Hardware
By the 1990’s, AM/FM software vendors began striving to add GIS functions comprising basic polygon processing to their systems. Conversely, in this same time frame GIS software vendors began adding network tracing and analysis capabilities. Part of this move came from the ability to relate entries in the non-graphic database to their position (XY coordinates). This was handled in either an external way, which was called a geo-relational database, or internally where XY coordinates were stored directly in a relational database.

The Blurring of AM/FM and GIS
It was the increased use of commercial relational databases in both GIS and AM/FM systems, which allowed similar functions to placed into both types of systems. This overlap of functionality led to the blurring of the differences between AM/FM and GIS. In fact, the industry began to call all systems that handled facility management and spatial analysis AM/FM/GIS (or even just GIS), regardless of their underlying data model.

Today, each of the top-selling AM/FM/GIS software systems still has one of the two underlying data models at its core. The AM/FM-based system, which, because of its network model, tends to be implemented only on a departmental basis. The GIS-based system, which, because of its topological data model, tends to be more interdepartmental or usable throughout the enterprise. The capabilities (or limitations) of these two models will become more prevalent as utilities demand more efficient access to spatial corporate data from all departments.

Modern AM/FM/GIS

The Role of Standards Today’s most efficient enterprise-wide GIS is one that is built on a client/server architecture using standard computer and networking technology. The server piece of this architecture uses commercially available relational data base management systems (RDBMSs) for data storage, which have been extended to accommodate spatial data (geographic content). This spatial extension can come from either the relational data base vendor or the GIS vendor.

The client pieces of this architecture run on standard PCs or workstations and address the traditional AM/FM or GIS functions in addition to new functionality such as map publishing on the Internet. These Internet components also make use of existing and emerging standards such as HTML, XML and WAP.

Open Development and Data Access
A key to acceptance of an AM/FM/GIS into a utility or telephone company’s information technology department is its ability to be easily customized and extended. Therefore, they cannot contain proprietary development environments, but must be able to be programmed with standard development tools, such as Visual Basic, Delphi, Visual C++ and Power Builder. Likewise, the ability to externally access the data within the system is mandatory. With standard relational databases comes the ability to access data via the Structured Query Language (SQL). In addition, the ability to access spatial data with similar, but extended SQL commands can be accomplished provided that the relational database has been spatially enabled through a spatial extension.

Object Orientation – vs Relational
There is no question that object-oriented (OO) programming has revolutionized application development in many computer systems. However, most AM/FM/GIS’ utilize commercial relational database management systems at their core. Early implementations of object-oriented geographic information systems utilized object-oriented databases. While this seemed to be an efficient design methodology, the problem was that no object-oriented database became commercially well accepted. So these systems were left using proprietary or obscure commercial object-oriented data base systems.

King COM
The turning point for AM/FM/GIS was when the relational data base vendors began supporting object-oriented tools and formats in their commercial systems. Microsoft’s COM (Component Object Model) architecture is becoming the standard in GIS use. Rather than a programming language, COM is a protocol or standard. COM specifies an object model and programming requirements that enable COM objects to interact with other objects. Systems that take advantage of this architecture can be easily customized with COM compliant programming languages such as Visual Basic, Visual C++ or Delphi. With these standard tools, there is no need for proprietary languages or data stores.

AM/FM Functionality in a True GIS
Since objects contain behavior (how they are displayed and interact with other objects), a GIS that supports COM can easily provide functions that previously required a specialized data structure. That is, it can provide the ability to trace a connected network and perform a spatial analysis, using polygon processing or buffering.

Today, most utilities or telecom companies that have not considered AM/FM/GIS are now doing so because of the threat of competition. A GIS can arm them with the tools to compete efficiently, identifying where revenue is coming from compared to where they have facilities. With the merging of these two disciplines, utility companies have to look to increased benefits to offset the costs of these systems. Corporate dissemination of mapping applications, or maplets, within existing IT systems will drastically increase the benefits for GIS implementation. The streamlining of job functions through the use of these maplets will allow efficiencies not seen before. Quick access to maps (and AM/FM or GIS functions) from within virtually all computer systems will change the way most users of those systems do their job.

The Future – Embeded GIS

A Place for Wizards and Cyberspace
I have described the way components (COM compliant objects) are being utilized to enhance existing or create new applications. However, the user interface is still of utmost importance. If a user cannot quickly and efficiently use an application, its acceptance will be thwarted. Thus a context sensitive user tutorial, called a wizard is being included in applications that have nonintuitive functions. The use of wizards in existing programs that did not previously have any geographic reference or content will greatly increase user acceptance for embedded GIS. More and more users will be creating maps and performing geographic or network analyses without using or even having a GIS on their computer. In fact, they may not be aware of the terms AM/FM or GIS while they are performing these geographic-based functions in their other programs.

Being able to see a map of the location for a new service, for example, will save great amounts of time in determining the closest facilities when a customer applies for service. Having a map of the customers downstream of a transformer damaged by an automobile will increase customer service by being more responsive, or even proactive, to outages. The efficient routing of vehicles using a GIS application can save significant maintenance dollars for a dispatch office. These are just a few examples of what can be done with fast access to spatial or geographic information within a utility.

Another media for the dissemination of GIS functions is the Internet or an Intranet via a web browser. I am sure that most people have seen an example of this when searching through web sites that support street maps and driving directions. Cyberspace will continue to be a significant media for GIS functions. In future versions of GIS software, a user will be able to obtain and use geographic data from across the Internet to create custom maps just as if the information was on the users own hard drive. The publishing of metadata along with these geographic data will make this process much easier.

Now Ain’t That Spatial
Aside from what I previously called maplets and embedded GIS functions, spatially enabled relational databases will also provide geographic capabilities and analysis to new sets of users. Making spatial queries like “show me all the customers within five miles of the phone store” will be easy with a database equipped with a spatial extension. Such SQL requests will be supported with a corresponding spatial expansion of the query language. The extent of the geographic capabilities will be dependent upon the number of spatial operators contained in the database extension.

You Don’t Have to be a Geographer to Read a Map
In the future, you won’t have to be a GIS operator to perform these embedded GIS functions and spatial queries. This reasoning is just like the fact that you don’t now have to be a geographer to read a map. The question is, though, how will this impact existing AM/FM/GIS systems used for facilities management and spatial analysis? With all this embedding, will AM/FM systems, as we know them disappear? Will the term go away? Will GIS entirely give way to spatially enabled relational database systems?

Conclusions – Is AM/FM dead?

Specialization Will Survive Regardless of how many maplets are created and how many new users of AM/FM/GIS functionality we will make with our embedded applications, these are additional users, not replacement users. What I mean by this is there will always be those intense users of dedicated systems that manage facilities or provide geographic analysis that they will survive and even grow as a group. The growth of high-end, professional GIS software will continue into the future. The requirement for these high-end systems will expand into vertical markets not previously penetrated with applications that we cannot now define. This has been the situation since GIS’ earliest days and this will continue into the foreseeable future.

What is exciting about the prospect of adding all these GIS users in this new occasional-use, non-traditional category (those that use embedded GIS functions), is that it will drive the functionality of core GIS software beyond what we would do alone as GIS professionals.

Expanding GIS software with new functions (and selling them) is what keeps us vendors in business.

As to whether the term AM/FM will die… Who knows? Maybe the folks at GITA can shed some light on that question. After all, they were once called AM/FM International.