Survey Fun Da Mental Questions

Jump Kit

The Framework for Civil 3D
Get More

Templates Only

See The Framework Work
Get More

Become a Member

Master Civil 3D
Get More

Autodesk Civil Videos

Free Civil 3D Training
Get More

Framework Videos

Free Civil 3D Videos
Get More

I hope you’ve enjoyed my man in the straw hat posts. Ain’t history a little fun? We’ll get back to that tale of western tales real soon now.

This spring Autodesk finally put Land Desktop to rest forever - from their perspective anyway. Some folks must stumble and stagger into AutoCAD Civil 3D. I suggest they buy an InstantOn since it solves most of the upgrade problems in one affordable swoop. I admit to bias about that. Anyway, I get questions like this.

“I know LDT really well, but I’m pretty new to Civil 3D. Can you tell me if I have to use an fbk file to make use of the Survey features and figures in Civil 3D? There seem to be a lot of different choices of how to approach things now.”

Nope and You Betcha

What is an fbk file really?

It’s a collection of survey observations in a text file in a specific format designed to pass equipment gathered observation data and its particulars into a Survey Network Feature’s data structure with Survey command language calls.

In the LDT days, that data structure was called the Survey Observation database. The Survey ObDb allowed us to resolve multiple equipment observations into individual resolved points given classic Survey adjustment rules and processes into fixed point locations. These could be represented in AutoCAD as LDT point blocks. We were only allowed to really have ONE Survey ObDb in an LDT project at a time and one set of COGO points.

Civil 3D Survey Takes the Gloves Off

AutoCAD  Civil 3D allows us many Survey ObDb’s. Any single Survey Database (Db) collects these into one or more named Survey Networks. Civil 3D doesn’t really care how many Networks you have or even how many Survey Dbs you may want or need to attach to any drawings in any “project”. You are responsible to maintain order.

Therefore it is important to deal with and think of Survey data as separate things. Input data, data in edit, and published output data are NOT the same even though it is now much easier to move back and forth between them. The Survey Toolspace makes this somewhat more visible in 2012+, but it’s easy to miss and/or misunderstand this. I’m just saying.

Work in progress and published work are NEVER the same thing.

Pay Attention to the CURRENT or Be Shocked

If you have equipment and software that generates fbk files or you can generate the files in other ways, Survey in Civil 3D operates much the same as before on the INPUT side. Survey now has a step by step wizard that does help guide you through the steps. Each wizard pane also allows you to access the backend settings too. The internal setup and number of settings in Survey  in Civil 3D is bigger and more complex for obvious reasons.

Because things are more flexible, the concept of “CURRENT” is a lot more important in Survey in Civil 3D. In other words, there isn’t ONE WAY there is the CURRENT way.

Each Survey database has its own specifics that are independent both from other Survey Dbs and any drawing. That “data independence” is a big plus for this “new” breed of Survey, but you have to pay attention to the details each and every time.  Not the least of these is the coordinate system you're working in. You don't get your survey to a known coordinate system? Why not?

The classic Civil 3D approach is to have a “default” or “template” coupled with settings to manage the complexity. Survey employs this approach with default Survey Db databases, database definition extensions, and an externalized collection of User Settings. You should employ these. If you don’t, you risk and lot of user confusion and frustration with the significant differences in Survey’s behavior that can occur if you do not.

Set and Match

As a Survey User you have a set of independent “operational” settings that can dramatically affect how the data is interpreted. You can and should always Save and Restore these user .set files. A Survey user .set file acts much like an AutoCAD Profile. Civil 3D stores these by default in a workstation specific Windows folder location. Why? It makes things easier for automated installs to succeed. I move them to a place of the Known Good. This is often a project Resources location.

Know the Features

“On Create or “On Entrance” are important concepts in Civil 3D. This is true for Survey too. Once an object is created as any specific Civil 3D Feature you may NOT be able to change fundamental things about it. On Create results are a question of BOTH the data input AND the process steps and particulars that you follow.

This brings up something I can’t neglect to mention because Autodesk civil users never had the following choice is the old days. You NEED to ask yourself,

“Do I need this in a drawing at all?”

Most of the time, you may NOT.  NEVER create Survey Features in a drawing without good reason and purposed intent. Most of your drawings will be something built to throw away as you pursue a better finished and published product. This really is good news, but it rearranges how you think about your work.

On entrance Survey can and will interpret almost any form of observational or locational data that you can find and/or define a format for.

The first classic case - you have resolved point locations (maybe from GPS or other survey software) with descriptions in a text file that you just want built into a simple collection of Survey Points and into attached Survey Figures.

Another common case being someone supplied you with a drawing file with points (in some form) from which you can extract the same information and want the same end result.

Survey in Civil 3D makes both of these processes a piece of cake. Of course the recipe changes based on the data you are faced with and your end purpose. Drawing (or other CAD format) conversions often have more steps to success. They might involve use of both Civil 3D and Map 3D tools. They can include esoteric processes like Map report queries to get the form of the data adjusted.

Text File In

The simple text file in known ASCII format with descriptions in easy to deal with. It will generate Survey point locations and Civil 3D Point Features in drawings based on: the CURRENT Point Group definitions and order; Description Key Sets and order; and those CURRENT operational settings we discussed above.

Survey can and will generate Figures from the point data given you have an appropriate and CURRENT Figure Db. Are the imported Figures here necessary? 

That same separate process from Point creation can also generate Parcel segments and even complete “Closed” Civil 3D Parcel Features too. Where these “things” end up a what they look like is all a matter of Style. Hint hint - Existing and proposed processes do not need to be different. They do remain separate.

Survey handles multiple inputs well. Divide and conquer is often a better strategy than a dump it in and sort out the garbage on the screen approach. This applies to edited and chopped up versions of fbk files too. If you actually use Windows Notepad alone as your Civil 3D Survey text editor, you have probably missed this point. I use Notepad2 and Excel EVERY time.

Survey is Lot of QA

Survey has become much better at displaying and editing the Features produced in the Survey Db and in drawings in Civil 3D.
This figure has been edited. How can you tell?
That's right - Auto-generated is OFF and what's that sidewalk shot doing in here?
Connecting the dots.

As modifying and adjusting what is in there got easier, backing up the changes got easier too. You still have to do the backups systematically and choose your poison. You are responsible.

Backups to Survey LandXML DO work, but Survey output to Survey LandXML is very specific and still somewhat simplistic about Figure construction particularly where curves are concerned. Therefore, what you backup, may NOT be exactly what you get and expect when your complex Figure edits come back. The issues are usually minor, but they are annoying and often disconcerting too.
You didn’t do anything wrong.

The data in Survey is NOT the same EXACT data in Survey LandXML by definition.

Remember that you can always simply copy and relocate the Survey Db files themselves. Wouldn’t a Survey Toolspace pick to do THAT and another to Restore them be nice.

Tell Autodesk not me!