Last modified: January 17, 2010
Coordinate Transformations in Civil 3D®
(Note: This article was originally written for Autodesk Civil 3D 2008.
It has since been partially-updated for Civil 3D 2010, although there are still
a few things that need to be updated, particularly with regard to the new Import
Events. Unfortunately, it appears that at least most of the issues addressed
in this article remain in Civil 3D 2010. And I have been told by unofficial
sources that Autodesk has received very little feedback on this issue and it is
not a high priority, so nothing is likely to be done, unless Autodesk hears otherwise
from their customers. So if you would like to see Civil 3D Coordinate Transformation
handling improved by Autodesk, head to their
feedback page and tell them "Coordinate Transformations are important
to me!", along with maybe a pointer to this article.)
One of the most-common tasks that Surveyors perform involve coordinate transformations.
Sometimes, a job is begun in an assumed coordinate system, which must later be adjusted
to another coordinate system. And in these days of megaprojects and GPS, it
is becoming more and more common to work in an official grid coordinate system,
such as UTM or State Plane, or even in a custom Low Distortion Projection (LDP).
And when coordinates are in a Grid coordinate system, they sometimes must be converted
to another Grid coordinate system. But whatever the need, coordinate transformations
are an important task in Surveying.
Civil 3D has some support for coordinate transformations, but as of the 2010 release
of Civil 3D, it also leaves us hanging in many key respects. Many aspects
of coordinate transformation are not implemented as we might wish in Civil 3D, especially
when it comes to designing projects in Grid coordinates. However, although
Civil 3D does not support coordinate transformations in the solid and rigorous way
we might desire, it is capable of most aspects of coordinate transformations, as
long as we understand all the limitations and pitfalls. This article explains
how those features are currently implemented in Civil 3D, and how we can use them
to perform the majority of the transformations we require.
Before we begin...
This article assumes you are already familiar with Grid (e.g., State Plane) Coordinates,
Surface (aka Ground) Coordinates, Localized Coordinates, and Project Coordinates.
If you are not familiar with these terms, or if you have only a hazy understanding
of them, you may wish to review the article
"Working with Grid Coordinates" (PDF, 0.5MB) before proceeding.
To summarize, in Civil work, we have two prime methods for dealing with the fact
that the Earth is a curved surface. Geometric calculations on a curved
surface are complicated, so we've come up with a couple of different methods
that let us (mostly) ignore the curvature of the Earth, and use standard Plane
Geometry in our work. One method is to use a Project Coordinate System,
and the other is to use a Grid Coordinate System. With a Project
Coordinate System, each point has two different coordinate values, a Project
Coordinate and an approximate Grid Coordinate. In this type of project, we
can apply a rotation, translation, and scale factor to our coordinates, and thereby
get from Project Coordinates to approximate Grid
Coordinates. With a Grid Coordinate System, each point has only a single
coordinate, the Grid Coordinate, and we use a floating scale factor to adjust
our distances between Ground and Grid. Civil 3D fails to make a
distinction between these two different types of projects, and the vast majority
of the problems we have with Coordinate Transformations in Civil 3D can be traced back
to this point.
Unit and Zone Settings
Before we get into the question of how to do transformations, we must first understand
the "Unit" and "Coordinate Zone" (or "Zone") settings.
An important point to remember is that, with with survey data, the data passes through
a series of steps, generally involving various pieces of hardware and software,
and with conversions along the way between various
file or data formats. An error in settings at any point in this chain can
cause a problem. It starts in the survey instrument, which may be set to measure
in some unit of measurement, such as meters, International Feet, or US Survey Feet.
This data is then processed in the data collector, in a Job which may have a coordinate
zone setting in addition to the unit setting. The data then may pass to a
file format that contains further settings - e.g., FBK files contain Unit settings,
and LandXML files contain Unit and Coordinate Zone settings. The Survey Database
in Civil 3D has Unit and Zone Settings. And in the drawing itself, we actually
have a plethora of settings - Civil 3D has Unit and Zone settings, but we also have
some Unit settings that come from the core Autocad product.
In addition to all of that, we can have different types of coordinate systems going
on. As illustrated in the previously-mentioned paper on
"Working with Grid Coordinates", there are two main ways of working
with coordinates in construction projects - one is to use a set of Project coordinates
(which may or may not be the same thing as the Localized coordinates), and the other
is to use Grid Coordinates. And to top it all off, our Grid Coordinates might
be in meters, or in International Feet, or in US Survey Feet.
With all these different settings, all in different places, things can easily get
muddled. And as we shall see as we go along, Civil 3D doesn't always support
what we really want to do. So sometimes we are left trying to sort through
things, and "make do" as best we can. To start, let's take a
look at the various places where we can identify and control our unit and zone settings.
The Instrument and Data Collector
Generally, the settings in the instrument are controlled through the data collector,
although most instruments also provide ways of controlling these settings from the
main instrument panel. The location of these settings and their exact function
varies between manufacturer and model or version, so we will not get into details
about them here.
The important part is that these settings be correct for the project at-hand.
The instrument and data collector should be configured to function in the correct
units (meters, International Feet, US Survey Feet). If we are using Grid Coordinates,
the data collector should also be configured with the current Coordinate Zone and
set to work with a floating scale factor, or if we are using Project Coordinates,
it should be configured to work "normally", i.e., with no scale factor.
Data may then be transferred to or from the data collector using a variety of methods.
Some of the most-common methods involve CSV files, XML files, and FBK files.
Point files are simply files that contain lists of values, with the fields separated
by some value. The most commonly-used variety is the CSV (comma-separated
value) file. CSV files are simply comma-separated lists of values. All
values are listed in a specific order, and anything reading or writing to the file
must know the order of the data. When used as a Point File, each line in a
CSV file contains the data for a single point. The CSV file does not contain
any unit or zone settings; all users of the CSV file must simply be aware of what
sort of data is in the file, and treat it correctly. Basically any data can
be passed in a CSV file, as long as all users of the CSV file agree upon the data
format. In Civil 3D, this format information is specified in a Point File
Format setting (located in the Point Settings, on the Settings tab of Prospector).
We will discuss Point File Format settings later.
XML (extensible markup language) files are similar to CSV files, except the file
also contains the definition of each piece of data within the file. So while
a CSV simply has a list of numbers like "5,500,600,100,MYPT" and we would
have to know that it is a point file in PNEZD format, an XML file would contain
data that says something more like "Here's some point data, and the point
number is 5, the northing is 500, the easting is 600, the elevation is 100, and
the description is 'MYPT'". We do not need to know the order
of the data before-hand, or even the type of data included in the XML file; that
information is contained within the file itself. In this way, an XML file
can also contain the Unit and Coordinate Zone information for the data it holds,
and we do not need to create a File Format as we must with CSV files.
FBK (fieldbook) files were designed as a way of allowing field surveyors to specify
linework at the same time as they collect data in the field. This eliminates
the need to "connect the dots" to create a topographic or design survey
from field shots. The FBK files may contain a set of linework commands, along
with points coordinates and/or survey instrument raw data readings. FBK files
typically contain unit settings, but not coordinate zone settings.
It is important to note that settings in the Transformation Tab are NOT applied to
survey data being imported into the Survey Database via a FBK file.
Settings on the Transformation Tab are only applied to data as it is being added
to (or exported from) a drawing. As such, the Transformation Tab cannot help
transform data in an FBK file before adding it to the Survey Database. The
Survey Data must first be imported from the FBK into the Survey Database, then translated/rotated
in the Survey Database using the Survey Addition available from Autodesk Civil Community
website, or some other third-party solution. Given the fact that it is often
necessary to reimport a FBK file multiple times before the data is "good",
this can be a horrendous drawback for Surveyors.
Starting with Civil 3D 2010, we now have other options. For example, we
can process the field data in our data collectors, or in other software such as
Trimble Geomatics Office, and create CSV files. We can then import the CSV
file into our drawing, which applies the
Transformation Tab settings. Then we can use an Import Event to "import"
the data from the drawing into the Survey Database, creating the linework. This method
basically bypasses most of the functionality of the Survey Database, which means
we are giving up the power of Civil 3D's Survey Networks. But due to other
limitations in the Survey Database (which we will not discuss in this article),
many people do not use the Survey Network features of the Civil 3D Survey
Database anyway, and this may not be a big loss. In addition, this allows
us to completely ignore things like Civil 3D's Equipment Database, which can
help simplify Civil 3D (always a good thing). So this may be the ideal
method for many.
However, for those who are still using an older version of Civil 3D, the options
aren't as palatable.
Another option is to translate/rotate the data BEFORE creating the FBK file, but
for that, you will probably wish to use some third-party product. If your
linework commands are included in the point descriptions, and you are using something
(like this) that lets you create FBK files from
CSV files, then another option is to use a multi-step approach: import the raw points
into Civil 3D, rotate/translate the points using the normal Move and Rotate commands
(or the similar commands in the Sincpac-C3D),
then export the rotated/translated points back to a CSV file. Finally, convert
the new CSV file to a FBK file and import it into Civil 3D through the Survey Database
to create the linework in the drawing. This option involves a lot of steps,
and converting a CSV to a FBK can be tricky, but it works (even for data collected
with GPS equipment).
And finally, it is always possible to drop Civil 3D's linework generation
entirely, and use a third-party solution for creating linework and surface
breaklines from the points after they are brought into the drawing. There are
some third-party programs available which provide better solutions than that
found in Civil 3D 2010, and you may wish to check them out if Civil 3D's
built-in features are not adequate for your needs.
The Survey Database
The Survey Database contains settings for Units and Zone. Unfortunately, it
does not contain any way of specifying which type of project we are working with
- a Grid-based project, where all coordinates are Grid Coordinates and we use a
floating scale factor to convert distances between Ground and Grid, or a "Normal"
project, where all coordinates are either Project or
Localized coordinates, and we use a scale factor and optional transformation/rotation
to tie our Project coordinates to a Grid. This makes it very ambiguous as
to whether the coordinates in the Survey Database are Project or Grid coordinates,
and casts severe doubt on what the Zone setting in the Project Database does.
As we shall see later, this is a potential source of huge problems. In fact,
Civil 3D itself seems conflicted on this issue; some operations in Civil 3D
treat the Survey Database as if it contains Grid coordinates, and some operations
treat the Survey Database as if it contains Project coordinates.
The Civil 3D drawing is probably the most-confusing part. Like the Survey
Database, the drawing has no way of specifying what type of Project we are working
with - a Grid-based project or a "Normal" project. Instead, C3D
is actually designed so that all C3D elements - Alignments, Surfaces, Parcels, etc.
- use the "Northing" and "Easting" values in C3D at all times.
C3D also has "Grid Northing" and "Grid Easting", which are calculated
from the "Northing" and "Easting" by applying the settings in
the Transformation Tab.
Unfortunately, this design means that Civil 3D does not fully support Grid-Based
projects. A Grid-Based Project can be done in Civil 3D, but since all Civil
3D elements (Alignments, Surfaces, etc.) are defined using the "Northing"
and "Easting", we must disable the Transformation tab in order to do a
Grid-Based Project, so that the "Grid Northing" and "Grid Easting"
are the same as the "Northing" and "Easting". This is
all well and good, in fact it is desired, because in a Grid-Based Project, our Project
coordinates and Grid coordinates are the same thing. The problem is that C3D
has no automatic support for calculating and labeling ground distances in
a Grid-Based Project. We can use Expressions in Label
Styles to kind of "hack in" this functionality, but as we shall see later,
this solution is chaotic, difficult to manage, and error-prone. It also
does not work well at all for sites where we cannot identify a single "average
scale factor" that will work for all points in our project. In other
words, if our project site is too large or has too great an elevation change, we
may need to define multiple Expressions, each using a different scale factor,
simply to label ground distances. This exacerbates the Style Breeding
Problem in Civil 3D, in addition to introducing a lot of potential for error. As another
drawback, using a Grid Project means we must completely disable the Transformation Tab, which
means we cannot
easily dump our State Plane coordinates out into a known Project Coordinate
System or to an Assumed Coordinate System. Again, this is something we can
manage via a roundabout and non-intuitive procedure, but Civil 3D does not
support it in a clean fashion that would make the task easy and
There are even more issues in the drawing itself. The core Autocad product
has a number of unit settings. These unit settings include almost any unit
between Angstroms and Parsecs, except for US Survey Feet. Because of
this, the default Autocad scaling features - such as those that autoscale Blocks
and XREFs, and are controlled by the INSUNITS, INSUNITSDEFSOURCE, and INSUNITSDEFTARGETS
system variables - cannot really be used for those who are using US Survey Feet.
These features use International Feet to perform all scaling operations between
other units and feet, and return the wrong results for those using US Survey Feet.
(This problem also affects the new 2010 feature for attaching XREFs using the "Geographic
Data" option. Effectively, it means that this feature can give incorrect
results when US Survey Feet are involved, and this option often cannot be used.)
Iin addition to the core Autocad units, there are additional units settings found
in the Civil 3D Drawing Settings. Civil 3D itself is only designed to be used
with meters, International Feet, or US Survey Feet. When changing the Civil
3D Drawing Settings, Civil 3D will also change the Autocad Units to match.
However, the Civil 3D Drawing Settings are not changed when the Autocad Units settings
are changed. This means it's possible to get a drawing into some very
strange and unpredictable states by setting the Civil 3D units and the Autocad units
to incompatible settings. Care should be taken so that you never do this;
when adjusting unit settings, always make sure that the Civil 3D units and the Autocad
units are set compatibly. Usually, you can avoid issues by always changing
the units from the Civil 3D Drawing Settings, and not from the Autocad Format->Units
The Transformation Tab
Now that we've reviewed some basics about settings, let's see how transformations
are implemented. The heart of coordinate transformations in Civil 3D is located
on the "Transformation" tab in the Drawing Settings. To access it,
go to the "Settings" tab in Prospector, right-click on the drawing name,
and select "Drawing Settings. The tab is shown below.
Before we get into the usage of this tab, I should warn you that changing settings
on this tab after you have data in a drawing, especially if the drawing came from
survey data and is also in the Survey Database, is VERY DANGEROUS.
It is very easy to completely ruin the integrity of your data, get your drawing
and Survey Database completely out-of-sync, and wreak havok in general. However,
at times, changing the data in this tab is exactly what you need to do, so there
are no simple rules to follow. Hopefully, by the time you complete this article,
you will know enough about this tab to avoid getting yourself into a nasty situation.
To begin, let's go over the items in this tab, and discuss each one briefly.
Then, we'll see how these settings might be used in our work.
This item simply displays the current coordinate zone setting. The value here
cannot be changed on this tab, and is here simply for informational purposes; to
change this value, go to the "Units and Zone" tab.
Sea Level Scale Factor
This setting is something of a puzzle. The Help File is rather silent on
this item, saying only that it is used to reduce measured horizontal distances
to the distances at mean sea level. That would tend to indicate that the
purpose of this setting is to help when we're working in a Grid Project, and we
have data collected using conventional equipment. And in truth, this
setting does seem to do something to the distances when processing a FBK file.
Unfortunately, it also uses this value to adjust the coordinates of any Control
Points imported via the FBK file, creating a result that I do not understand or
In addition to whatever this setting is doing during FBK imports, it also
multiplies our Northing and Easting for our drawing's Cogo Points by some value, and puts the result in the
"Grid Northing" and "Grid Easting" columns. If we are really using a Grid
Project, then our Northing and Easting should be identical to our Grid Northing
and Grid Easting, so this operation makes no sense. On the other hand, if
we are using a Project Coordinate System, then we should key our Combined Scale
Factor into the setting for the user-defined Grid Scale Factor (which we'll talk
about in a moment), and we have no need for an elevation scale factor.
As another point, the calculations performed by this setting are somewhat
confusing. This seems to be related to the value used for Radius of Curvature.
One problem is that we cannot specify this value; instead, Civil 3D seems to
calculate it somehow, based on the point you have selected as your "Reference
Point". Yet even then, something strange seems to be happening. For example,
in one test I performed, Civil 3D was telling me that it was using R=6,367,400m,
but when I tried checking the numbers I was getting, it seemed that Civil 3D was
actually using a value closer to 6,356,000m. It was not really clear what Civil
3D was doing. From mentions in the user discussion groups, it appears that most
people find that, when using this Elevation Factor, they get results in
distances that are correct to about 0.01' from what they expect, which is close enough for typical
survey data. Still, it is troubling that Civil 3D seems to give unexpected
As one final point,
I have also seen postings in the various discussion groups, wherein people mention
that they have needed to specify a value in this field in order to get their FBK
files to process adequately. Usually, the complaint is that the results still
aren't correct, but they are within 0.01' of the correct value. So if you are
having trouble processing FBK files in Civil 3D, you may wish to attempt to use
this option, just to see what happens. However, I personally have yet to
find a valid use for this setting, and I always leave it disabled.
Grid Scale Factor
This value controls our scale factor for converting between Grid and Project coordinates.
This option functions somewhat differently for each of the Computation methods.
This option uses a Grid Scale Factor of 1, which essentially disables the Grid Scale
This is the most-useful option, and supports the calculation of an approximate Grid
Coordinate from a Localized or Project Coordinate. This option lets us
loosely-equate items in Localized or Project Coordinates to a Grid system, using
one control point as the base point, and applying a "combined scale factor".
When using this type of setup, the "Northing" and "Easting" in Civil 3D contain
Localized or Project coordinates, and the "Grid Northing" and "Grid Easting" in
Civil 3D contain the approximate grid coordinates calculated for the point.
These "approximate grid coordinates" are only precisely accurate at the control
point we're using as the base point for our coordinate conversion. But assuming the Project extents are not
too large, the error in the conversion can usually be ignored. Unfortunately,
this option is not used by the Export to Autocad or eTransmit
commands, so this option is not particularly helpful when it comes to converting our drawings into the
Grid system, as we often need to do when sharing information with GIS
This option is a puzzle. It causes Civil 3D to somehow autodetermine a scaling
factor, based on the Reference Point. I think it is intended as a way of using
a drawing point to have Civil 3D automatically come up with a grid scale factor,
but its implementation seems incorrect. The big problem with it is that the
Reference Point is also used to add a horizontal translation (we'll discuss
this in a moment). Since the horizontal translation between Localized and
Project coordinates should be completely separate from the Grid Scale Factor used
to get between Localized coordinates and Grid, I am completely puzzled by an option
that links them. Therefore, this option appears to have no valid use.
Like the Reference Point, this option is a puzzle. According to the Help, it is
the "preferred option", because it creates a different grid scale factor for
each point in the project. The only problem is that the Prismoidal Formula is
actually used to calculate the approximate distance on the ellipsoid, given two
coordinates that are on the grid. It is not used to calculate the floating
scale factor. Not to mention, when using a Grid system with a floating
scale factor, the floating scale factor is only applied to distances. We
never multiply our coordinates by
a floating scale factor. So
this option appears to be a general error on many levels, and it should never have
even been included on this tab. Contrary to what the Civil 3D Help says, this option
definitely NOT the "preferred option", and in reality, should never be used at
Points as they appear in the Survey Database. Note that these are Grid Coordinates.
This options allows us to specify parameters for specifying a translation between
the Northing/Easting and Grid Northing/Grid Easting coordinates found in the drawing.
As with the Grid Scale Factor, we can use these options for some tasks, if we are
careful. Because of the way Civil 3D performs the scaling and translation
options in the wrong order, we have to come up with "funky settings" to
achieve what we want. Typically, the settings in Civil 3D are so funky
that we can't simply key in values from our
plans, but instead must use a couple of known coordinates to let Civil 3D
calculate some of the settings for our transformation.
The nice part is that, with some caveats, it is usually relatively easy to do
As an example, the image to the right shows some survey data that has been imported
into the Survey Database from a FBK file. Note that the coordinates are Grid
Coordinates in the Survey Database.
This survey network was also simultaneously inserted into the drawing. The
image below shows the contents of the drawing, along with the Drawing Settings.
Notice that the Grid Coordinates in the Drawing are the same as the Survey Database.
In the drawing itself, the points and figures are found at the Northing and Easting;
e.g., Point 1 is located in the drawing at X=193900 and Y=435800.
And now, just to illustrate the problems that can arise from changing the settings
in the Transformation Tab after data is already in the drawing, take a look at the
image below. All I did was reset the Reference Point settings. But look
at the coordinates. Civil 3D kept all points at their drawing location, and
revised the Grid coordinates, so now both the Northing/Easting and the Grid Northing/Grid
Easting in the drawing contain Project Coordinates. But the Survey Database
still contains points in State Plane Coordinates, so they are now out-of-sync with
the points in the Drawing. This can be a recipe for nastiness. However,
when using the Import Points or Export Points options, it can also be exactly what
we need to change. Sometimes, we can change this value temporarily, just to
get some points imported or exported, then change it back, so everything is still
in sync with the Survey Database. But extreme care should be used.
Also note that there is an option for "Point Number" for the Reference
Point, which may be used to specify a translation between two assumed coordinate
systems. This option is useful when the desired coordinates in the target
coordinate system are known for a point. Specify the Point Number, and the
Northing and Easting for the point are placed in the "Local Northing"
and "Local Easting" spaces in the grid. The Northing and Easting
for the same point in the target coordinate system may then be keyed into the "Grid
Northing" and "Grid Easting" fields. See Example 2 at the end
of this article for an example of this.
Rotation Point, Grid Rotation Angle
The Rotation options allow us to apply a rotation to points in addition to a
However, there are some complications. The "Azimuth"
setting only has an effect when a Rotation Point is selected, and when a Rotation
Point is selected, the "Azimuth" specifies an angle to the line formed
by the Reference Point and the Rotation Point. This forces the Reference Point
to serve double-duty, used to specify both the Rotation parameter and the Translation
parameter at the same time. This creates a mass of confusion - in fact, it
creates so much confusion that I generally consider the Rotation setting to be
too difficult to set directly. Instead, it is far easier to simply specify
a Reference Point and Rotation Point, and let Civil 3D calculate the values it
wants to use. This is shown in Example
2 near the end of this article.
The Missing Option - Unit Conversions
And finally, there is an option that is completely missing from this tab.
Sometimes, we may need to tie our project to a grid system that is in different
units than our project. For example, we may be using Project Coordinates,
and tying our project to a grid zone that is in meters, but our project itself may
be in US Survey Feet. There is no provision in Civil 3D for this situation;
should it arise, you must simply proceed in whatever manner is necessary.
However, since Civil 3D does not support automatic conversion of Localized Projects
to Grid during eTransmit or Export to Autocad, the fact that this feature is "missing"
will probably have a minimal impact for most users.
Labeling Ground Distances in Grid Projects
An expression that multiplies a segment length
by our approximate scale factor.
As stated earlier, all Civil 3D design elements (Surfaces, Alignments, Profiles,
etc.) are defined using the Northing and Easting in Civil 3D. However, in
a Grid-based project, we must define all of these elements using our Grid coordinates.
So, in Civil 3D, the only way to do this is to completely disable the Transformation
Tab, so that our (Northing, Easting) coordinates are the same as our (Grid Northing,
Grid Easting) coordinates.
But when we disable the Transformation Tab, we lose all automatic support (such
as it is) for converting between grid and ground. This means that, if we are
working in a grid-based project, we are left largely to our own devices.
Specifically, our option now is to create special label styles that use Expressions
to multiply distances by a scale factor. In order to use this method, we need
to come up with an approximate "combined scale factor" for our job, and
multiply measured distances by that combined scale factor to come up with an approximate
ground distance. This is not strictly correct... Really, we should be
using a floating scale factor. But Civil 3D does not support a floating scale
factor, and the amount of error introduced by using an approximate "combined
scale factor" is generally so small as not to matter. However, care should
be used, to make sure that you do not inadvertantly introduce unacceptable levels
The image to the upper-left shows the settings for our Expression. (Note that
you may need to create a similar Expression in multiple places in Civil 3D - basically,
you need one in every category where you need a Label Style that can label ground
distances.) After examining our project, we determined that a good "average"
combined scale factor for our job would be 0.9998539998, meaning we would multiply
ground distances by 0.9998539998 to come up with a grid distance. Since we
actually want a label that takes our grid distance and comes up with an approximate
ground distance, we'll create an Expression that multiplies our grid distances
by the inverse of 0.998539998, or 1.000416022. This expression can be seen
in the image to the left.
A label that uses our new Expression for Ground distance.
Finally, we need to create a label style that uses our Expression to label our linework
with approximate ground distances, as seen in the image on the right. As long
as the distance we are labeling does not carry over too great a distance, this label
should work fine for most purposes, since the error we introduce with our "combined
scale factor" is usually so small that it makes no difference in our label.
Unfortunately, this method can cause us to create many Expressions, though, which
introduces a lot of potential for error. However, it can be made to work,
as long as care is taken.
The Transformation Tab and the Survey Database
As mentioned earlier, we can specify Unit and Zone settings in both our Drawing
and in the Survey Database. In general, we should make sure that those zones
are set the same. If they are different, Civil 3D will attempt to translate
coordinates between the Zones as we move data between the Drawing and the Survey
Database. This may be exactly what we want, but incorrect settings can lead
to some very bad results, so the first thing to do is make sure that the Unit and
Zone settings are correct in both the Drawing Settings and the Database Settings.
This step is very easy to forget, especially since a lot of people tend to do the
majority of their work in a single coordinate zone, using the same units all the
time. But an error in the coordinate zone settings can cause quite a lot of
trouble, so this is an important point to remember.
Another source of potential trouble lies in the difference between International
Feet and US Survey Feet. If you are using Feet as your units, there are
settings in both the Drawing and in the Survey Database that specify they type
of foot to use. It is important to make sure that the settings are the
same in both the Drawing and the Survey Database, otherwise Civil 3D may try to
"help" you by silently applying an unwanted data conversion.
Unfortunately, simply remembering to check all our settings isn't enough.
In the current implementations of Civil 3D, the settings in the Transformation Tab
are applied inconsistently between Civil 3D and the Survey Database. This
means we must be very careful in how we use the Transformation Tab.
In Civil 3D, we have a Survey Database, which typically contains all our field survey
data, and we have the drawing, which may also contain the field survey data.
When using an FBK file to import survey data, data is being imported into a Survey
Network in the Survey Database, but we can also have Civil 3D simultaneously insert
the data into the drawing. The important thing to remember is that both the
Survey Database and the Drawing contain a separate copy of our data. Civil
3D will try to maintain a linkage between this data, so that changes in one can
be reflected in the other, but that linkage has some issues. Let's take
a look at a couple of those issues.
Transferring Points between Drawing and Survey Database
Starting with the 2010 version, the "Create from Drawing" option has been
removed from Civil 3D, and this section no longer applies. Instead, we may
now use an "Import Event" to "import" points from the drawing into the Survey
In Civil 3D, we may open up our Survey Database in Toolspace, browse to our Survey
Points in the database, and Insert the points into the drawing. We may also right-click on "Non
Control Points" in the Survey Database, and select the "Create from Drawing"
option to add drawing points to our Survey Database.
But as stated earlier, each point in the Survey Database has only a single Northing
and Easting for each point, while each point in the drawing has a Grid Northing
and Grid Easting in addition to a Northing and Easting. Whenever we insert
points into our drawing from the Survey Database, the coordinates in the Survey
Database are used as the Grid Coordinates for the point in the drawing. As
always in Civil 3D, though, the points are actually located in the drawing at their
Northing and Easting values, not at the Grid Northing and Easting. And when
we use the "Create from Drawing" option to add a Drawing Point to the
Survey Database, the point in the Survey Database gets the point's Northing
and Easting values, not its Grid Northing and Grid Easting.
In other words, if we take a point from the Survey Database and insert it into the
Drawing, then create a new Point in the Survey Database from that Drawing Point,
we will not end up back where we started. The image below illustrates the
In the image above, Point #6 existed in the survey database, and was inserted into
the Drawing. Point #7 was created in the Drawing directly on top of Point
#6, and then added from the Drawing to the Survey Database. Note that the
coordinates for Points 6 and 7 are the same in the drawing (as seen in the Point
Editor in Panorama), but they are different in the Survey Database (as seen in the
Survey tab in Toolspace). They should be the same in both locations.
Importing FBK Data
The image below illustrates what happens when we turn on the Elevation Scale Factor
on the Transformation Tab, and then try to import FBK data. The first image
shows how the data comes in when the Elevation Scale Factor is disabled. The
second image shows how the data comes in when the Elevation Scale Factor is turned
on. Notice that when the Elevation Scale Factor is used, the Points and the
Survey Figures are not inserted into the drawing at the same place. The Survey
Network and Points are inserted into the drawing at the Drawing Northing and Easting,
after the Elevation Scale Factor is applied. But the Survey Figures are simply
inserted into the drawing at the same coordinates as the Survey Database, which
are the Grid Coordinates. Of course, since there are other reasons the Elevation
Scale Factor cannot be used, this issue is something of a moot point. But
it is yet one more issue to be aware of.
These images should look the same. In the image on the right, an Elevation Scale
Factor was used, and consequently, the Survey Figures were inserted at a different
location than the Survey Network and Points.
Importing and Exporting Points
When Importing or Exporting Points, Civil 3D relies upon the Point File Format mentioned
earlier in this article. A sample Point File Format is shown in the image
to the right.
Earlier in this article, we stated that Point Files do not contain any information
about the data that is inside them. Well, this is how we tell Civil 3D what
data belongs in the Point File. In this example, each line of the Point File
can contain up to five values, separated by commas. The first value is the
Point Number, the second is the Northing, etc.
Note the setting for "Coordinate zone transform". If we select this
option, we can then specify what Coordinate Zone the points in the CSV file belong
to. Civil 3D will then use this Zone and the Coordinate Zone setting in the
current drawing to transform the coordinates when Exporting points to or Importing
points from a file.
Also note the "Load..." button in the lower left-hand corner. After
pressing this button, you may browse to a text file, which is loaded into the display
window, which may sometimes make it easier to create a Point Format that works for
a specific file.
Example 1 - Project Coordinates
Let's look at an example of using the Transformation Tab to perform a common
coordinate conversion. (Note: you can see a brief video demonstration of this
example on the Quux Software website, in the
video on Coordinate Transformations - Project Coordinates to Grid Coordinates.)
In this example, we have a job using a Project Coordinate system. The system
was defined using Control Point 217. First, a combined scale factor was identified,
using Control Point 217. Then we divided the State Plane coordinates by the
combined scale factor, to come up with some Localized coordinates. Then, in
order to prevent confusion, we dropped 1,000,000 from the Northings and 3,000,000
from the Eastings to come up with our Project Coordinates.
We then entered those values into Civil 3D. The image below shows an example
of the Transformation Tab settings, as well as some of the resulting coordinates
calculated by Civil 3D.
Configuring the Transformation Tab to convert between Project Coordinates and
Approximate Grid Coordinates, using a combined scale factor and Control Point 217.
With these settings, our Civil 3D drawing uses our Project Coordinates. However,
our Project Coordinates are at ground level, and to get to the datum surface for
our Grid System, we apply the combined scale factor. This combined scale factor,
however, is only accurate at one point. In the example above, the conversion
is only accurate right at Control Point 217. For every other point, there
is some error introduced. This means the values in the "Grid Northing"
and "Grid Easting" columns are approximate Grid Coordinates.
The further we get from Control Point 217, the further these coordinates deviate
from true State Plane Coordinates. But as long as our project extents are
relatively small, the amount of error introduced should be insignificant.
Care should be used, however, not to extend a Project Coordinate System too far.
Warning: When using Civil 3D in this manner, any design elements we create
- such as Alignments, Corridors, etc. - will use our Project Coordinates.
However, if we now use an Import Event to import our data from the drawing into
a Survey Database (such as when creating Survey linework, using the linework functionality
new in Civil 3D 2010), the values in the Survey Database will be the same as our
"Grid Northing" and "Grid Easting". If we use the
Transformation Tab, the "Grid Northing" and "Grid Easting"
contain our approximate Grid Coordinates,
then the coordinates in our Survey Database will be these approximate Grid Coordinates.
This is probably undesirable, since if we are using a Project Coordinate System,
we probably expect to see our Project Coordinates in the Survey Database.
Essentially, this means that, if you want to have Project Coordinates in your Survey Database, you must
make sure that the Transformation Tab is disabled whenever you are using the Survey
Now let's assume that we want to export all the points, but we want to export
them with their approximate State Plane coordinate values, and not the Project coordinates
we're using in our drawing. We can define a new Point File Format as shown
below, and use it to export the data to the file. A sample of the resulting
output is also shown.
This Point File Format defines a CSV file, but the coordinate values are Grid Northing
Grid Easting, instead of Northing and Easting.
When exporting points, we select the new Point File Format that we
just created, and the result is that the exported file contains
the "Grid Northing" and "Grid Easting" from the drawing.
Example 2 - Translating/Rotating between assumed systems
(Note: you can see a brief video demonstration very similar to this example on the
Quux Software website, in the
video on Coordinate Transformations - Assumed Coordinates to Project Coordinates.)
Let's say we have a project with the coordinates shown on the left. These
coordinates were assumed - basically, the Surveyor went out into the field, assigned
the coordinates (5000,5000) to Point 1, guessed at a backsight azimuth, and started
Now let's say we want to equate this to another assumed coordinate system.
In our target coordinate system we want to translate to, we know that the coordinates
for Point 1 are (N,E)=(1435800,3193900) and the coordinates for Point 6 are (N,E)=(1436000,3194200).
In order to setup the Transformation Tab to perform this transformation/rotation,
we first pick Point 1 as the Reference Point, and Point 6 as the Rotation Point.
When we pick these points, the Northing and Easting coordinates for the points will
automatically be placed in the "Local Northing" and "Local Easting"
fields in the Transformation Tab. Now, in the fields for "Grid Northing"
and "Grid Easting" in the Transformation Tab, we type in the coordinates
we want for Points 1 and 6 in our target coordinate system. Civil 3D will
use these values to determine the translation and rotation. The net result
is shown below, where the Northing and Easting columns contain our starting coordinates,
and the Grid Northing and Grid Easting columns contain the coordinates in our target
Example 3 - Coordinate Zone Transformation
In this example, we have a Grid-Based Project. As we have already stated,
in order to use a Grid-Based Project, we need to disable all transformations on
the Transformation Tab. So for this example, the Transformation Tab is disabled,
and the Northing and Easting in the drawing are the same as the Grid Northing and
Grid Easting - both are Grid Coordinates. In the Drawing Settings, we have
selected the NAD83 Colorado Central (US Foot) coordinate zone.
Now, let's say we wish to export the coordinates in our project to a UTM Coordinate
Zone. We can setup a new Point File Format like the one below.
This Point File Format defines a CSV file that contains coordinates in NAD83 UTM
Zone 13 coordinates. Clicking on
the small globe-like icon next to the Coodinate Zone setting calls up the "Select
Coordinate Zone" dialog. Note
that this Point File Format is using the "Grid Northing" and "Grid
Easting" values for the Point File.
Now, when we export the points, we should select the "Perform coordinate transformation
(if possible)" box in the Point Export dialog. The results can be seen
The starting coordinates, in Colorado State Plane (numbers in the 1,000,000 and
can be seen in the Panorama window. The CSV file contains the exported data,
and has been
opened in Notepad. Note how the coordinates in the CSV file are in UTM Zone
with coordinates in the 4,000,000 and 500,000 ranges.
XML Import and Export
As one final note, Coordinate Zone transformations can also be accomplished using
XML import/export. The XML file itself contains a line that specifies the
Coordinates Zone and Unit settings for the data. However, in Civil 3D, data
imported to or from XML data contains the Northing and Easting coordinates only,
and not the Grid Northing and Grid Easting. This is an important point
to keep in mind. It means that the automatic Coordinate Zone transformation
capability built into XML Import/Export only works if you are using a Grid-Based
Project, where the Transformation Tab is disabled and the Northing and Easting in
Civil 3D are the same thing as the Grid Northing and Grid Easting. If you are
using Localized or Project coordinates, you will get incorrect results if you attempt
to use XML Import/Export to perform coordinate Zone tranformations.
Another point to keep in mind is that Civil 3D does not automatically handle US
Survey Foot data when it comes to XML. In theory, since the Coordinate Zone
is set in both the XML file and in the Civil 3D drawing, this should be handled
correctly automatically. Unfortunately, it is not. The LandXML file
actually contains two separate lines - one specifies the measurement units, the
other specifies the coordinate zone. These items can be set inconsistently
(although this should probably not be allowed), so it is possible to create a LandXML
file that says it is in a US Survey Foot zone, but is using International Feet as
the unit of measurement.
A snippet of a LandXML export. Notice that the Units are set to "USSurveyFoot"
in Line 4, and the Coordinate System is
set to "NAD83 Colorado State Planes, Central Zone, US Foot" (US Foot means
the same thing as "USSurveyFoot"). With improper
settings in Civil 3D, we can export a file that has the incorrect units specified
in Line 4, even if the Coordinate System is correct.
And in Civil 3D, there are two other settings, located in the "XML Settings"
in your drawing, that control how US Survey Foot data is handled. To get to these
other settings, go to the Settings tab in Toolspace and right-click on your drawing
name, then select "Edit LandXML Settings...". This will call up
a dialog box with two tabs, an "Import" tab and an "Export"
tab. The two settings we must worry about are located on these tabs, one in
the Import Settings, and one in the Export Settings.
The important "Import" setting is located on the Import tab in the "Data
Conversion" section, and it is called "Convert Survey Foot to International
Foot". If this option is set to YES and the LandXML File contains data
in US Survey Feet, this data is automatically converted to International Feet as
it is being imported. This conversion will happen even if the Coordinate Zone
is set to a zone that uses US Survey Feet. The net result is that,
if this option is enabled, you can get incorrect results during the XML Import.
In my experience, I have yet to find a reason why I would ever want to set this
option to TRUE, and recommend that you leave it set to FALSE unless you discover
you must change it.
The important "Export" setting is located on the Export tab in the "Data
Settings" section, and it is called "Imperial Units". This
unit specifies how Civil 3D should flag the data in the LandXML file. No data
conversion is applied to the data, so you must make sure that you set this to "US
Survey Feet" if your Project is in a Coordinate Zone that uses US Survey Feet,
and set it to "International Feet" if your project is in a Coordinate
Zone that uses International Feet. Otherwise, you may create a LandXML
file that contains coordinates in US Survey Feet, but claims that the unit of measurement
is International Feet (or vice-versa). This can create the inconsistent sort
of LandXML file mentioned earlier, where the LandXML file says it is in a Coordinate
Zone that is in US Survey Feet, but it also says the unit of measurement is "International
It's as easy as that!
OK, maybe it isn't that easy. But if you've managed to hang in there
all the way to the end, hopefully the information contained in this article will
allow you to successfully navigate the hazardous realm of Coordinate Transformations
in Civil 3D. Good luck!