Managing the multi-layered landbase of a GIS application environment, the using enterprise has the requirements to minimize duplicate effort, out-of-synch data and duplicate data storage. The opportunity for these efficiencies is evident in a telecommunications network application environment where street address data must be available to describe the location of many layers of network components but must only be stored a single time to comply with the requirements listed. The challenge can be addressed through the relational capabilities of the geoobject data model.
The scope of this paper has grown significantly since its inception. Upon investigating the landbase addressing issues, it was discovered that there is much more involved in integrating an engineering application with a GIS landbase. Location, addressing, attribute query and analysis, data sharing – all become factors in the successful integration of the GIS landbase with the engineering data held in a secondary application.
In many operations, the network design applications operate in a vacuum. CAD packages are most often used to develop the Telco network design with little or no regard for the locational accuracy or with the identification of the designed facilities’ addresses or spatial assignments. While an organization might have an accurate landbase at a very large scale – say 1:2000 or better – the designers rarely have access to this landbase information during the design phase.
The result is a design that is unintelligent when it comes to location. Many operations are forced to retrofit the address or locational intelligence back into the design after the fact. This can only lead to inaccuracies in the data and often will lead to duplication of locational information in both the landbase and in the design files.
Looking at a typical organizational chart for a telecommunications operation shows the critical need to share not only locational information, but specific attribute, descriptive and topological information as well. The engineering group needs to access inventory availability information in order to plan a proposed facilities addition. Likewise, the physical location of that inventory – the specific address where both existing in-place equipment and available, usable inventory reside must also be obtained. Ideally, this should be accomplished via a shared database that not only understands locational information, but also allows various departments and applications to access and share the required data.
In reality, this type of problem
is inherent in any large organization. In a Telecommunications company, for
example, the flow might go something like this:
1. A new service order is received
via the web
2. The service order is passed to
network planning to see what bandwidth or network is available to provision
3. The planning group determines
that there is a need for new facilities and passes the order off to the
design/engineering group
4. Engineering consults in-place
inventory and spare inventory, determining what, if any, new equipment and
network elements are required to fulfill the service request.
5. Service activation looks at
existing service in the area and at the engineering designs and schedules
service activation.
Without some mechanism that facilitates data flow, the entire service activation can fall apart. Often, each department might have not only uniquely formatted data, but each might be using different vendors to produce that data. If any island of information happens to have a data compatibility issue with another, the entire process grinds to a halt.
Enter the centralized geospatial data warehouse. Data warehousing is not a new concept. It’s been around for years in the CIS arena and has worked well for financial, human resources, facilities, and other departments in large enterprises. Adding the geospatial component is, however a new idea. Spatially enabling the database by adding locational intelligence multiplies the value of the shared data. Existing equipment, facilities, even customer locations can now understand where they are in the real world and where they are in relation to other assets or customers.
By using a warehousing concept, corporate data can be indexed, shared and accessed from anywhere in the enterprise. The entire organization can thus benefit from the spatial enabling of the data. This is not to imply that the data exists in one physical location. The idea of data warehousing is really a philosophical idea and not a physical one. The warehouse can be a large centralized database, or it can be a series of carefully defined procedures for logging, defining, sharing and using the data from each department that is designated as part of the warehouse. There are many factors that enter into this issue, and they are best addressed in another paper. (Reference the GITA Webcast – G303 Building the Geospatial Data Warehouse and Data Sharing. http://gita.org/events/events2.html
For our discussion here, we will look at how key spatial attributes – addressing for example, are defined and shared in the warehouse arrangement.
Several key factors must be looked at when defining shared spatial data. The common information like projection system, scale, accuracy, and the like are obvious. Each user of the data must be able to view and query the shared geographic data with an understanding of its lineage and location.
What might be a surprise is the topological information that is inherent in most GIS data. It is equally important that secondary users and applications of the shared spatial data be able to read and understand the spatial relationships that are described by the geospatial database. A particular building resides on a specific parcel. The parcel has an owner and may have a parcel ID number. The building is assigned an address that falls in a range of addresses that are tied to the street centerline on which the parcel sits. There might be a telephone pole on the northwest corner of the parcel acting as a support for a piece of telephony switching equipment.
Each of these physical features need to understand some bit of geographic information that is tied to a related feature. Proximity, connectivity and physical addresses are example of this type of data. The method by which this information is assigned to each feature is the issue.
Ideally, every feature in the geo-database should be able to have built-in intelligence that can determine behaviors, appearance, logical relationships and spatial or topological relationships. Especially in the engineering world, all assets – equipment, fiber optic cables, splices, even poles – have pre-defined behaviors. Certain equipment can only be used for fiber, copper, or coaxial cable. Various transmedia (cables) require either an equipment interface to interconnect or a splicing mechanism. The equipment on the pole described above may, or may not be able to provide connection service to the building.
Traditionally, either the connectivity rules, symbology, and other behaviors were entered into a rulebase, or they were stored in the head of an experience designer. While this worked most of the time, there was no consistency in applying behaviors and certainly not when applying derived information such as addressing or locational indicators. (Note the number of different ways that most street databases abbreviate the word “Street”.)
The right way to ensure that each shared feature in the geodata warehouse has the necessary spatial intelligence is to enable the database to assign, manage and access the shared spatial data. Not only should the database hold information that describes behaviors of managed objects, it should also be able to assign and manage data sharing among its charges.
This is especially effective if the shared landbase can offer “inheritable” data to individual secondary applications. Specifically, topological relationships, connectivity, address specifications, and other GIS-like data should be able to be passed from the parent landbase to the dependent child applications. Keep in mind that not all the data requiring spatial relationship information is necessarily contained in a centralized easily controlled database. Each department around an enterprise might have data that it offers to the data warehouse. That data may or may not contain the required spatial relationship knowledge required for other ancillary applications. The inventory database might not care about specific addresses assigned to a piece of equipment or its spatial proximity to a power supply. Yet, service activation and engineering groups need this information to perform their functions. Ideally, the shared data needs to understand and incorporate spatial data relationships into its behavior even when those relationships are held in another data store accessible through the warehousing mechanism.
Once again, enter the smart geo-database. Technology today allows the database to be able to closely model feature behavior. This includes the ability to have logical as well as physical relationships among managed data. The database design and its behavior can be leveraged to manage spatial attribute assignment as well as physical locational behaviors. Actions as simple as locating the nearest parcel centroid to a piece of equipment and assigning the same address to each can go a long way towards accomplishing this goal. More sophisticated algorithms can be employed to determine correct assignment of spatial attibutes, based on the requirements of the behavior being modeled. In the landbase example, address information might be contained in the parcel, building, or street centerline layers. Addressing might be described by location centroids or by polygonal features. The algorithms must be smart enough to be trained to look for the correct address information, regardless of where it resides.
These algorithms can be resident in the secondary application or the database itself. Often each department around a large organization might have its own set of specialized requirements for inherited behaviors and thus might provide to the enterprise a set of tools for sharing key spatial data.
Locational information in a spatially enabled data warehouse must be shared around an enterprise to allow the organization to reap the benefits of the GIS-based data. This is best accomplished by way of a powerful, intelligent geodatabase that allows the enterprise to define objects and their behaviors while sharing the data with other members of the organization. Current GIS technology provides the groundwork for this activity. The database design and implementation of this technology along with key specialized secondary applications, network engineering tools, for example, are the keys to successfully managing multiple data sources around an enterprise.