AM/FM/GIS makes a 180-Degree turn
Advances in Relational Support for Geographics
With the introduction of spatial data handling in the latest relational ware, Oracle SDO
for example, geometry can be stored and accessed in well-defined manners in the
relational database. Further, database access languages have been and are being extended
to allow the use of spatial operators in querying the geometry. Yet, as one looks at the
various GIS offerings, one sees that vendors of GIS software are still making proprietary
secondary stores of geometry and geometry-related data a fundamental part of their
architecture. Do they not understand the need to bring geospatial data access to the whole
of the enterprise?
Moving the geographics into the corporate database is more than a matter of just creating
geometry data types and inserting them into the database as records in the corporate
database tables. Certainly this makes the data integrity and data management issues an IT
problem which is a good thing, and it makes the data available for any enterprise database
processor to access. Additionally, bringing the geographic data and its associated
attributes into the corporate database allows the full power of the corporate database
software to be applied, software like stored procedures, triggers, and use of standard
database reporting software.
However, GIS applications did not go to proprietary data storage solutions arbitrarily. A
prime driver for this approach in the past was the need for graphics processing
performance that allowed the user to browse across thousands of Geographic records
quickly, viewing this data as rendered vectors on a graphics screen, with high resolution
of detail, symbolized according to the attribute data associated to the Geographic feature.
In addition, GIS applications needed to do geographically-based locates and queries, and
'feature-based' editing, where the geometry needed to be handled in concert with all
associated data for a geographic feature. Enterprise database technology did not support
this kind of performance or functionality. Even today, relational database retrieval speeds
for geometry are not fast enough to support the random map data access that all
successfuul GIS applications provide. However, the relational vendors continue to make
progress, as is seen in the addition of spatial indices and spatial operators which take advantage of these indices for faster geometry retrieval. Measurements vary, but
relational database are beginning to support retrieval speeds of up to 1000 simple
geometries per second. This has enabled some non-GIS applications to gain access to
enterprise geometric data. Even with this, the performance demands placed on GIS
applications are still not met by today's mainstream corporate databases. Most
mainstream geographic applications need 5 to 10 times this retrieval rate in order to
provide the map display users have come to expect. This retrieval rate needs to include
the time required to compute symbology as well, as most users expect the current display
of the geographics to correctly reflect any attribute changes made that affect the
appearance of the geometry. (E.G., changing symbols as the type of the transformer is
changed, or color as the state of the equipment is moved from 'proposed' to 'in-service'.)
|
