A safe harbor for domain expertise
Until recently, most geospatial professionals stored spatial data in files containing each feature's location and description, but not its business rules and relationships to other spatial datasets in the same collection. With this traditional method, the business rules must reside in the software applications that display the data or in the minds of the software's users (the domain experts) or both. The alternative, in theory, is to store locations, descriptions, business rules, and associations in database tables that enforce this business logic for all database users. In the language of databases, then, a spatial data model distills domain expertise into attribute domains, validation rules, and relationships among objects.
All rules aboard. Attribute domains refer to standard feature properties the culvert dimensions in your road-building project might be no smaller than 1 meter and no larger than 3 meters. The data model uses validation rules to guarantee that all data are consistent with the attribute domains. Each time a user adds a culvert to the dataset, for instance, the database compares the new entry against the data model, rejecting culverts sized outside of the 1-3 meter attribute domain. The spatial data model becomes an automated quality-assurance expert, something especially useful for vector-streaming spatial Internet sites. Spatial Web sites used to serve their maps only as snapshots of spatial data in the form of a GIF or JPEG. Today s most popular Internet map servers all support a more sophisticated vector-streaming technology, in which the server sends actual coordinate data to requesting client sites. What users see on their browsers is a mini-GIS displaying data from their computer's cache. This makes online editing of spatial data much easier than it was with map snapshots. Data that are easy to access and edit, though, will quickly become inconsistent data without the validation rules and attribute domains of a spatial data model.
Sharing the bounty. If attribute domains and validation rules seem understandable but dry, relationships among objects are what make spatial data modeling interesting. Relationships exist both within a spatial dataset and between different spatial datasets. For example, a network of sewer pipes must be continuously connected. Subdivided parcels of land should adjoin each other perfectly without overlaps or gaps. These relationships of geometric networks and planar topology illustrate the precise relationship of each feature in a single dataset to other features in that same dataset. Similarly, features in one dataset may have a relationship with features of another. For instance, water meters may only be connected to water mains of a certain size. Or, when moving a water meter, the mains connected to it should move as well. Relationships among data will be increasingly important as the trend to standardize and share spatial data proliferates. Sharing is on the rise, as evidenced by the increasing numbers of spatial portals both public and private (see the November 2000 Net Results column). With sharing, though, comes concern about how data will be used or misused. If rules and relationships ship with the data, unintentional misuse is much less likely. Organizations that share their data across departments or regions will also appreciate that spatial data models stored in databases can be exported and imported as complete bundles. This means that when the Pennsylvania office downloads the Ohio office's natural habitat data, they get Ohio's habitat polygons and domain expertise, straight from one database to another and all in a single, tidy transfer. When the two datasets become components of the same model, the Ohio habitat polygons will automatically buffer all nearby Pennsylvania roads, testing for encroachment issues and, if necessary, citing the appropriate regulations in the resulting report. What's even more interesting is that spatial data models with relationships among objects can predict the future and support decisions. What would happen to the rest of the network if this pipe clogged? How much would it cost to build a road through this watershed? The answers, derived from the relationships, are already part of the data model.
Charting every course. Attribute domains, validation rules, and relationships among objects make spatial data models smart. Versioning makes them historically accurate. Database professionals just discovering the spatial world are horrified to learn that, for instance, altering the curve of a road with typical GIS editing tools completely replaces the old geometry with the new, rather than deactivating and archiving the old road for later reference. The spatial data model captures all versions of a dataset, even when multiple users edit the same feature at the same time. Versioning becomes particularly useful to organizations that design and build things, and need to compare multiple design ideas during the course of a project. Because databases support concurrent access by many editors, and because each editor s changes are immediately visible to all other users, group collaboration and comparison of different designs is possible without file-transfer and synchronization headaches. As temporary competing designs win or lose approval, they are added to or archived in the database. Each project acquires a spatial history. Further fueling the need for versioning, wireless technology is enabling field personnel to take their spatial data with them, make changes in the field, and send the revisions back to the base -- all in real time. In some applications, such as law enforcement, other field workers may need to see those changes as soon as they are posted. The versioning capabilities of a spatial data model allow all users to post their changes for everyone to view, but without fear of altering or destroying existing data. Even though field data comes in all day long, the data administrator can sort through conflicting data entries at his or her leisure because data are only archived, never overwritten.