Although GIS is just three decades old, the approach of its software has evolved as much as its capabilities and practical expressions. In the 70’s software development primarily occurred on campuses and its products relegated to library shelves of theses. These formative years provided the basic organization (both data and processing structures) we find in the modern GIS. Raging debate centered on “vector vs. raster” formats and efficient algorithms for processing— techy-stuff with minimal resonance outside of the small (but growing) group of innovators.
For a myriad of reasons, this early effort focused on GIS technology itself rather than its applications. First, and foremost, is the necessity of building a viable tool before it can be taken on the road to practical solutions. As with most revolutionary technologies, the “chicken and the egg” parable doesn’t apply—the tool must come before the application.
This point was struck home during a recent visit to Disneyland. The newest ride subjects you to a seemingly endless harangue about the future of travel while you wait in line for over an hour. The curious part is that the departed Walt Disney himself is outlining the future through video clips from the 1950s. The dream of futuristic travel (application) hasn’t changed much and the 1990s practical reality (tool), as embodied in the herky-jerky ride, is a long way from fulfilling the vision.
What impedes the realization of a technological dream is rarely a lack of vision, but the nuts and bolts needed in its construction. In the case of GIS, the hardware and software environments of the 1970s constrained its use outside of academia. Working with 256K memory and less than a megabyte of disk storage made a GIS engine perform at the level of an old skateboard. However, the environments were sufficient to develop “working prototypes” and test their theoretical foundations. The innovators of this era were able to explore the conceptual terrain of representing “maps as numbers,” but their software products were woefully impractical.
With the 1980s came the renaissance of modern computers and with it the hardware and software environments needed by GIS. The research-oriented software gave way to operational systems. Admittedly, the price tags were high and high-end, specialized equipment often required, but the suite of basic features of a modern GIS became available. Software development switched from specialized programs to extensive “toolboxes” and subsequently spawned a new breed of software specialists.
Working within a GIS macro language, such as ARCINFO’s Arc Macro Language (AML), customized applications could be addressed. Emphasis moved from programming the “tool” within generis computer languages (e.g., FORTRAN and Pascal), to programming the “application” within a comprehensive GIS language. Expertise broadened from geography and computers to an understanding of the context, factors and relationships of spatial problems. Programming skills were extended to spatial reasoning skills—the ability to postulate problems, perceive patterns and interpret spatial relationships.
From an application developer’s perspective the floodgates had opened. From an end user’s perspective, however, a key element still was missing—the gigabytes of data demanded by practical applications. Once again GIS applications were frustrated. This time it wasn’t the programming environment as much as it was the lagging investment in the conversion from paper maps to their digital form.
But another less obvious impediment hindered progress. As the comic strip character Pogo might say, “…we have found the enemy and it’s us.” By their very nature, the large GIS shops established to collect, nurture, and process spatial data intimidated their potential customers. The required professional sacrifice at the GIS altar “down the hall and to the right” kept the herds of dormant users away. GIS was more often seen within an organization as an adversary competing for corporate support (a.k.a., a money pit) than as a new and powerful capability one could use to improve workflow and address complex issues in entirely new ways.
The 1990s saw both the data logjam burst and the GIS mystique erode. As Windows-based mapping packages appeared on individuals’ desks, awareness of the importance of spatial data and its potential applications flourished. Direct electronic access enabled users to visualize their data without a GIS expert as a co-pilot. For many the thrill of “visualizing mapped data” rivaled that of their first weekend with the car after the learner’s permit.
So where are we now? Has the role of GIS developers been extinguished, or merely evolved once again? Like a Power Rangers transformer, software development has taken two forms that blend the 1970s and 80s roles. These states are the direct result of changes in software programming approaches in general, and “object-oriented” programming in particular.
MapInfo’s MapX and ESRI’s MapObjects are tangible GIS examples of this new era. These packages are functional libraries that contain individual map processing operations. In many ways they are similar to their GIS toolbox predecessors, except they conform to general programming standards of interoperability, thereby enabling them to be linked easily to the wealth of non-GIS programs.
Like using a Lego set, application developers can apply the “building blocks” to construct specific solutions, such as a real estate application that integrates a multiple listing geo-query with a pinch of spatial analysis, a dab of spreadsheet simulation, a splash of chart plotting and a sprinkle of report generation. In this instance, GIS functionality simply becomes one of the ingredients of a solution, not the entire recipe.
In its early stages, GIS required “bootstrap” programming of each operation and was the domain of the computer specialist. The arrival of the GIS toolbox and macro languages allowed an application specialist to develop software that tracked the spatial context of a problem. Today we have computer specialists generating functional libraries and application specialists assembling the bits of software from a variety of sources to tailor comprehensive solutions.
The distinction between computer and application specialist isn’t so much their roles, as it is characteristics of the combined product. From a user’s perspective the entire character of a GIS dramatically changes. The look-and-feel evolves from a generic “map-centric view “to an “application-centric” one with a few tailored buttons that walk users through analysis steps that are germane to an application. Instead of presenting users with a generalized set of map processing operations as a maze of buttons, toggles and pull-down menus, only the relevant ones are integrated into the software solution. Seamless links to nonspatial programming “objects,” such as pre-processing and post-processing functions, are automatically made.
As the future of GIS unfolds, it will be viewed less as a distinct activity and more as a key element in a thought process. No longer will users “break shrink-wrap” on stand-alone GIS systems. They simply will use GIS capabilities within an application and likely unaware of the underlying functional libraries. GIS technology will finally come into its own by becoming simply part of the fabric of software solutions.
Source:
Berry, J.K. (1998). GIS Software’s Changing Roles. GeoWorld [Online] Available at: http://www.innovativegis.com/basis/mapanalysis/MA_Intro/MA_Intro.htm (Accessed: 27 March 2023).