I am a GIS consultant working for two years in the telecommunication industry with enterprise telecommunication GIS solutions, but by profession I am a teacher of geography and a student in GI Science and GIS. As a geographer, I have been confused by the fact that the way we represent spatial phenomena is at odds with the way those phenomena really exist. These phenomena are not easy to represent and even harder to understand.

Some examples of this are soil types and petrographic geology units. These types of physical geography features do not start and stop at the borders of a polygon; the polygons are just representative of "real world" spatial phenomena.

With respect to telecommunications infrastructure, I deal with the issue of abstract infrastructure that is symbolized as a physical feature in a GIS. For example, spans have been implemented as a linear feature class, although they cannot be seen in nature. Those abstract infrastructure feature classes are not physical obstacles inside an enterprise solution. However, creating associations between spans as a parent feature class and cables as a child dependant feature class may cause a bottleneck for the system.

A more critical issue when identifying abstract infrastructure features as physical GIS feature classes is in the process of integrating inside plant (ISP) and outside plant (OSP) data. In the telecommunication spatial world, ISP data are mostly connected with the "inside area" of a building, like a central office, an exchange or a cabinet, while OSP data are related most closely to our GIS feature classes (abstract and existing infrastructure in nature).

When we try to integrate ISP with OSP features with geometry types like ST_GEOMETRY or Oracle Spatial without any additional ActiveX components and work purely with the common geometry type, a conceptualization at different levels is needed.

The first conceptual level of spatial objects would be at a GIS level, where spatial phenomena like cables, joints (splices) and equipment are treated as GIS features. On the second level, we are assigning dependencies of GIS features to the abstract infrastructure. This is not as an additional feature class in relationship, but by assigning the dependency as an attribute. For example, we might want to try connecting and searching for cables of a certain span through a query of an attribute field. Also, we might run a query of an abstract phenomenon of the Central Office as a "select all of GIS features that have in their parent dependency attribute a certain Central Office set."

The problem comes on some issues in the third level of conceptualization when we try to describe the construction of a cable. The construction of a cable is understood as a number of pairs, strands, fibers, various bundles and groupings. A solution with attribute assignment of capacity of units that compose a cable would also work, but they are not entities in the database, to which we would like to point relationships.

A solution could be "on demand" creation of entities and relationships with the parent object - the cable. If we consider copper cables with several hundreds of pairs of fibers, this would slow down the performance of an enterprise solution. An appropriate explanation is that a construction of a cable is not visible in nature, hard to acquire in the field with a mobile device, but still essential for acquisition for other operations.

A solution for conceptualizating point features could be in representations from ESRI ArcGIS 9.2, where a feature can be conceptualized as a different feature type of different geometry at a different scale or for a different purpose, such as visualization. For example, a manhole is viewed by geometry network topology verification as a point feature, but for the purpose of new network planning or existing network maintenance on a small scale, it would be viewed as a polygon feature with real dimensions. Those two levels of representations should be treated as the same object in the database and only have differing visual representations. A similar conceptualization solution is appropriate for the central offices and cabinets.

In the telecommunications industry it is also essential to have the freedom of multi-modularity and configurability of the equipment systems. The functionality of equipment modeling should be extended to new technologies with the ability to easily upgrade and migrate to new configurations.

In many telecommunications software programs, there are several, fixed levels of equipment models. The parent object is a GIS feature representing a piece of equipment or a rack (a shelf that contains a variety of pieces of equipment or modules) in reality - depending on the technology. As previously mentioned, the system should be configurable as a commercial off-the-shelf product.

The module levels in telecommunications equipment usually have a shelf, slot, plug-in and port. There are many variations of modules and they should be sustained in the system for all exceptions and not be adapted to the technical solution, because it is not transparent to users how an adaptation of a module has been implemented, if that is not documented. Also, it does not give the user complete information.

Conceptualization should not be done in the field, but rather in the office, but it can be referenced. Conceptualization proposals like this one are only an attempt to broadcast a few guidelines or point to the appropriate solution.