Well, we suppose we'd better jump with a few comments on the article "An Overview of Laser-Scan's Radius Topology 2.5", especially Simon Greener's long posting on "Technical and Design Issues in Radius/ ArcSDE" as Simon's comments relate to our paper (pdf) "Building a Robust Implementation of Topology."
The primary purpose of our paper was to articulate the thinking behind our implementation of Topology for ArcGIS. We also wanted to discuss some points on integrity management with respect to relational database theory. The paper was not intended as a direct comparison with other geospatial vendor solutions (such as Oracle Spatial or Radius Topology). We raised several key points of interest to database developers in the paper.
First, that it is necessary to store (topologically clean) feature geometry with features for good performance. Tests by ESRI on a variety of data sets and databases show that solutions which require dynamic assembly of features from topological primitives at query execution (such as the Oracle SDO_TOPO_GEOMETRY type) do not perform or scale well. Greener agrees with this point and indicates that storing feature geometry with features is an aspect of the Radius software as well as ArcGIS.
Second, that standard RDBMS integrity constraints (primary keys, foreign keys, triggers, etc.) are not sufficient to maintain the integrity of a topological data model. Some external application software is necessary to do the geometric analysis. Again, there is no disagreement here. In our system, this is the responsibility of the geodatabase tier of ArcGIS. In Greener's solution for Tasmanian Forestry, this is accomplished by 3rd party software, Laser-Scan's Radius Topology, running as an add-on to Oracle Spatial.
Finally, we advance the case for maintaining a single representation of the topology (as validated and consistent feature geometry) rather than storing this information twice - as feature geometry and also as an interrelated graph of primitive objects. We raise the question: do we need both representations? What application functions require access to the topological primitives? We determined that, for the primary use of topology in GIS applications - quality control for features (a.k.a. "topological integrity") - the storage and maintenance of topology primitives as explicit database rows and relationships was not necessary. This seems to be the main point of disagreement. It is really a function of how GIS application designers choose to implement functions like polygon overlay, editing of shared polygon boundaries, and the like. We determined that we could support these features without the additional overhead of maintaining topology primitives as database rows.
There seems to be some concern that the ArcGIS implementation of topology is somehow "closed", "non-standard", and precludes sharing of information with other applications. This is not the case. The database schema used by ArcGIS fully conforms to the simple features schema of ISO SQL Multi-Media: Spatial. ArcGIS Topology can be used with a variety of database systems, ranging from files to Microsoft Access to RDBMS engines (DB2, Informix, Oracle, Oracle Spatial, SQL Server). ArcGIS Topology is used every day in workflows which validate and integrate information from different software products (MicroStation, AutoCAD, GeoMedia, etc.). Furthermore, ArcGIS's topology is exposed through industry standard Java and .net APIs. In that sense, ArcGIS is a much more open and adaptive system than the Oracle/Radius Topology system. (See, for example, a demonstration of ArcGIS topology running in a .net application server.)
The key question seems to be: should validation of topology be an aspect of the GIS or an add-on to the RDBMS server? We have determined that it is a necessary aspect of ArcGIS and have made it available to our users within our desktop applications, within our Software Development Kit and within our GIS Server. We need to support a wide variety of database engines and workflows and to provide a simple, high-performance, low-cost solution for our customers. We need a topology engine close to the application to support a good editing/quality control user experience and to support spatial analysis. We feel that the best model for interoperability and information sharing is one of simple features (features with clean geometry) rather than a much more complex model of interrelated topological primitives (and all the associated semantics such as "what does it mean to delete a shared edge?"). These all seem to be pretty reasonable points to us and for our users.
Should topology be implemented in BOTH the application and the database server - both belt and suspenders? There is no reason why Radius Topology could not be combined with ArcGIS, either as separate steps in a workflow or integrated into the database architecture. ArcGIS can be configured with the Oracle Spatial SDO_Geometry type and Radius Topology "just works" with any Oracle Spatial application, right? This might be a relevant approach for some applications. However, it does certainly introduce additional cost and complexity into the system as a whole, not to mention performance implications, with benefits which are not clear to us.
Finally, we find it strange that Oracle Spatial and Radius Topology are somehow considered "open" and "non-proprietary" and ArcGIS is considered "closed" and "proprietary". We think that this has more basis in marketing and product positioning than in the realities of true application interoperability. We can understand why some may wish to implement their system using the "proprietary" Oracle application and database server platform, rather than ESRI's GIS framework. However, that decision should be based on real application requirements, performance benchmarks, etc., rather than a false "closed" vs. "open" characterization of systems.
Scott Morehouse, ESRI
