Brainstorming in Conceptualizations of Telecommunication Infrastructure in GIS: An Attempt to Integrate ISP and OSP through a Common Geometry Type
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
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
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
Published Friday, June 29th, 2007