CAD to GIS: A Successful Migration from Start to Finish
Worth Sparks and Paul Finley
Learning Objectives:
1. Define the requirements for a successful switch from CAD to
GIS.
2. Discuss the solutions and why they were chosen.
3. Discuss lessons learned in implementing the GIS solution.
Two years ago, we at Rock Hill
Telephone Company determined our existing CAD system was outdated and we
started a search for a new system. Both
CAD and GIS systems were analyzed. We
chose an Arc/Info based GIS solution for managing our Telecommunications
Network and connectivity model. We
analyzed and solved many potential roadblocks commonly seen in CAD to GIS
switches such as legacy data migration for connectivity, symbolization, and
attribution.
CAD programs have various
limitations. Some have more than
others. Typical limitations include the
following:
1. Map size
2. Connectivity with attribution
3. Custom map generation
4. Statistical data analysis
5. Reporting
These limitations are virtually
eliminated by choosing a GIS solution.
In choosing a GIS solution,
several criteria should be considered.
All the data should be stored in a central location such as a database
server. The attribute data should be readily
accessible using off-the-shelf tools such as office suites and report
generators. The spatial data should be
stored in a format such that any one of several programs can be used to
generate maps.
The data model should be well
thought out. In a wireline engineering
environment, the relational database should be designed to handle connectivity
appropriate to the application.
In Rock Hill, we model our twisted
pair outside plant facilities. We need
to be able to trace an individual pair from the host to the customer’s
home. The database design needs to be
able to handle this level of connectivity detail. Many designs available today do not live up to this expectation.
Knowledge of the existing data
format is paramount to understanding how to move to the new system. A list of current data types should be
made. Each data type should be detailed
with information for each graphical element and each field. Also, list existing uses for the data type
and for each of the fields. For an
example, see attachment. This will help
determine what you want to trash, what you want to keep, and what you want to
enhance during the conversion.
Before learning the new data
formats, time should be spent learning the capabilities of a GIS. This will help in understanding why the data
is structured the way it is. It will
also help in understanding the GIS way of storing data you are accustomed to
storing in a CAD environment.
For example, we maintained TAX_DISTRICT for all of our outside plant data. In a GIS, we can keep the tax district
attribute attached to the tax district polygon. When we need a report of poles within a tax district, we’ll apply
the polygon in the query. When the tax
boundary changes, we will simply edit the tax district polygon.
Once you are satisfied you have a
basic understanding of the GIS paradigm, knowledge of the new application’s
data format is achievable. Similar to
the CAD data type list, a GIS data type list should be made. The list should have the same level of
detail as the CAD data type list. That
is, information on each graphical element and attribute field should be
included.
These lists, although tedious, are
important. They will help you make
sense of what data to move and where to move it. They will also help you finalize your customization list. Read on.
All of your legacy data is not keeper
data. Years of additions,
deletions, modifications, etc. leave your data in desperate need of an overhaul. As the conversion effort is usually the most
costly part of the migration process, it is crucial that you verify the data
you will be moving is beneficial. That
is, you must decide if the data will help you manage your business better or is
it just old data. Old data
should not be converted. Instead, it
should be either pitched or archived.
Some of the current data can be
replaced by other existing data. For
example, we track the distance between pedestals. We call this buried span.
The buried span line is placed on the map along with the distance
annotation. Then, we place the buried
cable by placing the line and its distance annotation. The distance of the buried span and the
buried cable is the same. This is
redundant data. Doing away with our
buried span data is being considered.
We should have considered it when we were finalizing our keeper
data during conversion.
Instead of converting, some data
could simply be reentered in the GIS.
We have six meter panels and five air dryers. For us, it was simpler to freshly place our meter panels and air
dryers in the new system than to spend time converting the 11 records.
The rest of the data types are to
be converted. Some, however, need to
loose some fields. Recall the TAX_DISTRICT example cited previously.
You will find fields like TAX_DISTRICT that should be
dropped. Still other fields might just
carry redundant data. Consider dropping
those as well.
The amount of customization is
determined by your needs. Using the
data format lists described above as an aid, make a list of functions provided
by your current system that is not available in an acceptable form in the new
system. To do this, cross-reference the
two data format lists for commonality.
Then, begin the new list with the data types that aren’t provided in the
new system. Finish the list with data
types that are provided in the new system but can’t provide the expected
functionality.
Objectivity is the key in making
this list. It would probably be wise to
keep customization to a minimum so future upgrades will be easier.
One of our problems was
color. Our users were accustomed to a
black background, which is common with CAD environments. The new system has a white background. In CAD, our outside plant devices, such as
terminals, were yellow. Rather than
require the new system to have the yellow terminals and black background, we
diplomatically switched to purple devices and kept the new white background.
Make sure any new equipment is
procured and installed before attempting any migration. This can be difficult if you don’t know what
is needed. Generally, the database
server should be powerful enough to run the total number of users on the chosen
database software. Also, it would be
wise to have a dedicated computer to run the conversion programs.
Because the client computers were
running CAD they are probably already powerful enough for the new
software. They should be reviewed,
however. Consider the operating system. Some of the newer GIS software requires
Windows NT. If Windows 95/98 is being
used, hardware upgrades may be needed before Windows NT is loaded.
Using your customization list as a
guide, develop any new options that aren’t provided by the new system. Hopefully, the software vendor will provide
a template for adding general pieces of equipment to the menus. If not, copy one of the existing options and
change it to meet the specifications of the new piece of equipment.
Our vendor provided us with a
template to add options to the menu.
The template consists of step-by-step instructions, which includes
building the symbol, designing the attributes, and writing the code used to
place the equipment in the map. Just
recently, we used the template to add a foreign anchor to our
menus. It went smoothly.
Add any attribute fields that are
needed for existing equipment options.
Three things will be needed for
conversion.
1.
Data conversion
software. A good spatial data converter
will help get the data from the old to the new.
2.
Programming language. A software development tool will be used in
writing programs that can help manipulate the data at any step of the
process. This will help make up for any
shortcomings of the first tool.
3.
A technician. The technician will use the first two tools
to complete the conversion. The
technician must have sufficient knowledge of the tools. He or she should also have the knowledge
mentioned earlier with respect to the old and new systems. The technician will probably need to have
the skills of a computer programmer.
If you’re lucky, the first tool
will do all that is needed in your conversion.
This way, the second tool is not needed. We weren’t so lucky. As
you will see below, we had to rely on the C programming language for the first
part of the conversion process.
We chose Safe Software’s FME
(Feature Manipulation Engine) for our data conversion software. The FME converts to and from almost any
imaginable spatial data format. It
doesn’t, however, support our CAD data.
To remedy this problem we used the CAD program’s macro language coupled
with C language routines to export our data to a middleware data format. The FME satisfied the remainder of the
conversion needs. That is, the FME
supports the formats of the middleware and the GIS database.
Make sure your technician gets
training on any of the software mentioned above as needed. It is sometimes tempting to forgo the training
when the technician is confident he or she can be self-taught. Don’t fall into this trap.
No matter how good the
documentation is, there is no replacement for the classroom setting. Questions arise and are then answered. Topics are covered that may not be needed
but later are.
We have fallen into this trap more
than once in the past. Lucky for this
project, however, we chose to get the training needed for success.
Use the lists you built above to map
the data for migration from the CAD system to the GIS. The spatial data converter will probably
require some programming to get the data to migrate right. That is, the data will not copy over, field
for field, graphic for graphic as we would like. The converter software will have to perform some logic along the
way.
For example, in our CAD system, we
place arrowheads at the beginning and ending of our cables. The cable might be broken in several places between
the beginning and the ending for terminals.
In CAD, we actually place an arrowhead symbol when needed and it becomes
part of the graphics collection for that record, along with the line and the
annotation. In ArcInfo, we can’t have
multiple graphics go with one record.
Instead, we have to use a line style that begins and/or ends with an
arrowhead. The FME (our spatial data
converter) performs logic on the input data and manufactures the data to tell
ArcInfo to use a certain line style. We
had to program the FME to do this.
The day will come when you
actually start to perform your conversion and you will see data in the
GIS. This will be an exciting time
because you will see your legacy data come to life in the new environment. It can also be a frustrating time as it
won’t be right the first time you turn the crank. You can see the finish line but you are not
there yet. Be prepared for this, and be
ready to start the tweaking process.
This trial-and-error process is inevitable so expect it. Eventually, you will have your data
completely converted and you will be ready to pass the point of no return
by digitizing in the GIS.
Changing
systems is not a “cheap” process.
System software, data conversion, installation, training, and
customization are all costs that must be factored in making a decision. Once the decision is made to switch (having
done the cost-payback analysis and determined the payback is acceptable),
up-front costs come into play. Every
organization then works to minimize the up-front costs, eliminating all they
can to make this number more manageable.
Some things are pushed to later dates and determined as some-days
not musts. Our team at Rock Hill
has learned that one of the areas we needed to build up on the front end, which
in turn saves a great deal on the back end, was building our data
foundation. Rock Hill contracted Mesa
Solutions Inc. of Huntsville Alabama, one of the co-developers of the GIS
application, to help define the data foundation requirements. Spending this additional money has proved to
be very beneficial and cost-effective, allowing Rock Hill to define the foundation
and get it right the first time.
One of
Rock Hill’s strengths and most valuable assets is their data. Facility
locations, equipment records, facility attributes, tax records, etc. are all
pieces of data that help us manage our business in an effective way. Thus, when looking to move to a GIS our
first thought was to make sure all the data that we have accumulated makes it
into the new system. While most of this
data is useful, not all of it is required. In addition, some of the data that is recorded may not be easily
converted into the new system format.
Thus, we chose to pick our data battles, which sometimes meant
manual data entry instead of data conversion.
Recall
the TAX_DISTRICT example again. GIS
introduced new capabilities to which we weren’t accustomed. A major new capability is the use of regions
(polygons) and their relation to the feature data inside them. We were able to trash the TAX_DISTRICT field
during conversion. Also, future
maintenance of every feature’s tax district has been eliminated.
As
simple as this sounds this is a primary step in accomplishing a successful
conversion. As we all know, people
resist change. Even though our users
had commented for years on our old systems deficiencies, it was still something
that they were accustomed to. Once we
made the decision to change, we detailed many of the differences in the new
system. We also detailed the improved
functionality that was included with the new system and the improvements it
would bring to the users. Detailing
this information on the front end and presenting it to the users made a big
difference in their attitude towards the new system. For instance, they were willing to accept a white background
screen (versus the black screen they had used for years) once they understood
they would save 13 steps in a typical map generating process with the new
system.
===============================================================
CAD data type: Buried cable
-------------------------------------------------------------
Uses
1. design work for engineering
2. CPR
3. Cable locating
4. budgeting
5. loop make ups
6. cable splicing and
troubleshooting
7. tax reports
8. archives (link to hard copy files and microfilm)
-------------------------------------------------------------
Record description
COL FEATU WEI LEVEL SIZE
STY
3 CPR_TEL_CABLE_BUR
LINE STRING NEW 2
3 3 2020 1.00 5
EXI
4 3 1 2020 1.00
5
SYMBOL NEW 2
3 1 2020 1.00 1
EXI 4 3
1 2020 1.00 1
TEXT NEW 2
0 1 2021 8.00 1
EXI
4 0 1 2021 8.00
1
CLASS ALPHANUMB
: 3
(1,2,3,4,5) r
SIZE WHOLE_NUMB: 4 (1,2,4)
GAUGE ALPHANUMB
: 5
(1,2,5,6)
TYPE ALPHANUMB :
15 (1,2,6)
COUNT REP_ALPHAN:
79 (1,4,5,6)
DISTANCE
WHOLE_NUMB: 4 (1,2,3,5)
DESIGN_OR_ASBUILT ALPHANUMB
: 2
(1,2) r
FROM_ADDRESS ALPHANUMB :
35 (1,3,5,6)
TO_ADDRESS ALPHANUMB :
35 (1,3,5,6)
ACCOUNT_CODE ALPHANUMB
: 5
(2)
TAX_DISTRICT ALPHANUMB
: 5
(7) r
FIRE_DISTRICT ALPHANUMB
: 3
(7) r
OWNERSHIP ALPHANUMB
: 5
(2,7)
AUTHORIZATION ALPHANUMB :
20 (1,6,8)
YEAR_PLACED ALPHANUMB :
13 (2,8)
MONTH_PLACED WHOLE_NUMB:
4 (2)
DISPLAY_RA ALPHANUMB :
20 () disp "RA"
RIPPLE_AUTH REP_ALPHAN:
79 (1,8)
ISSUE_NOTES ALPHANUMB :
79 (1,8)
LOCATION ALPHANUMB :
45 () r
TOTAL_CABLE_DISTANCE
WHOLE_NUMB: 4 () r
BLANK ALPHANUMB :
20 ()
HAS_BUDGET_TEXT ALPHANUMB
: 1
(4)
UNIQUE_ID ALPHANUMB :
20 (4)
-------------------------------------------------------------
Additional Information
color: blue
weight: light for existing
heavy for proposed
lines: dotted line for cable
solid line for leader lines
symbols: arrow head (#27, size 5)
level: 2020 for graphics
2021 for annotation
Worth Sparks
ESS Programmer
Analyst
Rock Hill
Telephone Company
P.O. Box 470
Rock Hill,
SC 29731-6470
Phone: 803-324-7231
Email: Worth.Sparks@RHTelCo.Com
Paul Finley
Managing
Director-Sales
Mesa
Solutions, Inc
7800 Hwy 20
West
Tower Building,
4th Floor
Huntsville, AL
35807
Phone: 256-864-0400 ext. 3055
Email: pfinley@mesahq.com