By Luke Howells
I’m a strong believer that when you choose to use a specific piece of software that it should be done to increase the productivity of your workflow. Lending itself to your existing practices with as little change as possible. Civil 3D is a prime example of a multiple discipline platform that, with a few pushes in the right direction, can suit most needs required of it.
From recent courses I have led on the Survey Module in Civil 3D, the onsite practices and recording of the data vary significantly from one surveyor to the next. Capture codes used, output files, deliverables required and the software used to transfer and process the drawing, usually 2 different pieces of software to produce the final drawing. Civil 3D can do all of this in one screen and quickly produce 3D environments for Engineers and designers to take onto further design.
I’m not saying Civil 3D can do everything, certainly not on its own anyway. We have to develop workflows and methods to get the desired outcome from the software.
String lines in surveys have been used for decades, it’s the most common form of capture I encounter. However, it’s not the native format that Civil 3D formats. It’s no secret that the method used in Civil 3D is heavily Leica based, if you have a Leica device and are used to working in this fashion then great, the line work codes from the software can be easily adapted but that’s a different workflow.
As you may be aware Civil 3D processes Survey Imports using 4 file formats, Pont Files, Points in the Drawing, LandXML and Fieldbook (.fbk) It is the Fieldbook that we will be using in this workflow. Most capture device can output to a .fbk format.
First things first, I don’t want you to change your capture method on site (unless you want too). Do you survey as you normally would and export the data as an. fbk (Fieldbook)? Most devices when labelling Strings take the capture code and then add a numerical value usually separated by a ‘space’. It is that ‘space’ character that causes most issues.
Civil 3D reads files either by comma delimited or space delimited. This leads to 1 large survey figure drawn in the model which then requires additional work to break up and define as individual strings. If possible this can be changed on the device to either remove the space completely or replaced with an underscore ‘_’.
If you cannot change this on the device, it doesn’t take long to edit the .fbk file on your PC using text editor. Just ensure that it is only the observation capture code this is applied to and not the Survey Station.
If we were to directly import the survey at this stage with no Figure Prefix Database established, we would only see the points. Create your required Figure Prefix Database, set the database to represent your capture codes, assign them a layer and style.
The last thing to change before import is the Linework codeset. This contains an important tool for this workflow to work, Automatic Begin on Figure Prefix Match. As we are not using the native line work code such as Begin (B) Continue (C) etc. We can get the software to create figures based upon the capture code used on site and then defined in the Figure Prefix Database.
With the last piece set we are now ready to import the Survey. Run through the Local Survey import wizard and let the software do the rest.