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 Transfer

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

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 files

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 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 Drawing

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 straight-forward.

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 dialog.

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.

Zone description

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 trust.

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 results.

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.

Unity

This option uses a Grid Scale Factor of 1, which essentially disables the Grid Scale Factor.

User-Defined

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 professionals.

Reference Point

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.

Prismoidal Formula

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 is definitely NOT the "preferred option", and in reality, should never be used at all.

Reference Point

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 this.

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 horizontal translation.

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

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 of error.

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.

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.

Danger, Danger!

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

(Note:  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 Database.)

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 issue.

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.

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.

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 Database.

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.

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 the survey.

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 coordinate system.

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.

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 below.

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.

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 Feet".

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!

Copyright © 2003-2012 Edward-James Surveying, Inc.  All rights reserved.