This article is the first in a series written by GIS correspondent, Marco Morais, who will be at the 2000 ESRI User Conference taking place in San Diego, California from June 26 through June 30. This year’s conference is an especially significant event in the history of the GIS industry because of several concurrent developments in technology. One of these, the advent of the N-tiered enterprise GIS, is discussed in the article below. Look for other articles in the days leading up to and during the conference.
If the pre-conference buzz emanating from Redlands is any indication, then the 2000 ESRI User Conference will mark the official introduction of commercial off the shelf (COTS) software that supports a N-tiered systems architecture. What is a N-tiered architecture and why should I care? Assume that you can logically disaggregate all aspects of a GIS into one of three functional bins:
The data management functions refer to the reading and writing of spatial and nonspatial attribute data to some type of permanent storage media, usually a hardisk. The operations and analysis functions refer to the actual logical processing of the data, including things like feature overlay and map projection. Finally, the rendering and user interface functions refer to the software components that the user interacts with, such as the graphical user interface (GUI) and display area.
The architecture of early GIS systems developed during the late 1970s and early 1980s resembled a stovepipe because all three components were tightly coupled and sold as part of a single entity. In other words, the earliest GIS software was responsible for providing functionality related to all three aspects of the GIS. Not surprisingly the weakness of this approach was quickly exposed when the software produced during this era could not adequately perform all three tasks. Even worse, there was little or no interoperability between software packages.
The evolution in systems architecture presented a new paradigm in the early 1990s as a solution, the client-server architecture. The client-server approach disaggregated the data management duties from the rendering and user interface. This approach benefited from the introduction of commercial relational database technology and inexpensive client-side desktop personal computers (PC) or UNIX network terminals. Many of the GIS installations today still use a client-server architecture. For example, an organization which stores spatial data on a central server in an ArcSDE or Oracle Spatial database, but uses ArcView or Arc/Info to manipulate this data, is taking advantage of the classical client-server architecture. The client-server approach provides an amicable distinction between the data management and user interface responsibilities, but suffers because there is no well defined place for the operations and analysis logic. For example, if you have to find all features within a certain distance of a given point, is it the responsibility of the data management or the user interface component of the GIS to do this.
The most recent evolutionary stage in systems architecture is the three tiered approach. The three-tiered systems architecture is more commonly referred to as N-tiered architecture in reference to the unlimited number, N, of intermediary layers between the client and server. In N-tiered architecture the operations and analysis component is explicitly restricted from being coupled to the user interface and data management components. Why is this subtle difference so important? If you are a developer of GIS operations and analysis software, referred to as “middleware” in reference to its position in the three-tiered architecture, then you are always developing your product under the assumption that you must support the most generic form of user interface and database interaction. The emphasis on nonspecialized and nonproprietary interaction results in a product which is more versatile, because it can be extended in the future, as well as more robust, because it must interact with other software which it has no prior knowledge of.
In the same way that the adoption of the client-server approach was assisted by the introduction of relational databases and desktop computers, the N-tiered architecture will require the introduction of industry standards and improvements in component software technology. The industry standards in GIS generally come in one of two forms. Data standards have been developed by industry consortiums, such as the simple features specification of the Open GIS Consortium (OGC), government agencies, such as the federal Spatial Data Transfer Standard (SDTS), or in a de facto manner if a particular proprietary format is popular enough, the ESRI shapefile is a good example. The second suite of standards are processing standards, such as the OGC’s services model and catalog, that relate the operations that must be made available in a piece of GIS “middleware”. In the area of component software, three competing models are available, the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), and Java Beans. Rather than choose a single model, ESRI has chosen to develop the core of their desktop Arc/Info 8 “middleware” using COM component technology and use Java in their ArcIMS Internet “middleware”. Although Arc 8 still bundles the user interface and data operations as software, the COM components which comprise the software are not wedded to the user interface. In fact, the exposed application programming interface (API) of the COM components enables GIS operations to be embedded anywhere there is a Windows operating system. The Java components in ArcIMS extend this capability in similar ways to other platforms and across the Internet. Finally, the era of N-tiered enterprise GIS architecture is here! As a result, your customers can come to expect the same from your GIS products as they do from any other piece of COTS software, making the world an easier place to do business.
Researchers have compiled an enormous global dataset with over four trillion satellite-based measurements of sea surface temperature.
Researchers have developed a high-resolution GIS dataset of river systems using remotely sensed data and OpenStreetMap data.
A Python language spatial package, called EarthPy, has been released for free download for working with GIS data.