This year, Mark and his team have been helping a transportation agency with their InRoads configuration for both Engineering and Survey. As part of this support we created a survey code reference book to help out the field crews that are collecting data. A section of this book discussed some unique behavior of InRoads Survey that Mark has always tended to share since he found out about it. When the lead surveyor at this transportation agency asked Mark a question about his documentation, Mark responded (as he often does) with an expansion of that section adding further illuminations. And here it is ... for all the surveyors in the house!

Here is the Zen Dude's response:

Single Shot Breakline Coding:

The ST Control Code -

When a series of shots is intended to create a breakline or draw a line, an ST code is added to the first shot to begin the connection of subsequent similar shots. In InRoads Survey the Feature Code itself is configured to expect a series of similar coded shots, which then creates the linear connections.

If a single usage of that Feature Code is entered (with a ST Control Code), even though it is identified as a breakline within the software (InRoads Survey), it will be added to the DTM as a Random point and drawn in the CAD file from the Field book as a point. This is rarely planned, and this is not a common occurrence but it happens often enough to mention; however the value goes beyond just understanding and extends to being able to use it to your advantage.

An example would be collecting an Edge of Pavement using code 301, or EP. A 'single shot' linear code with an ST Control Code has an expectation that other EP or 301 shots will follow it. When no other similar shots follow then that observation will be visually bold in the InRoads Survey field book.

 The rules to be understood here are:

ul>

• Any codes that are linear, or used to define a breakline, should begin with a ST code on the first shot. Coded in this way a line will be drawn in the Plan view and that series of shots will be added to the DTM as a breakline. 
• This is the typical way this collection would be done and the usual results that would be desired and obtained.
  • 301 ST
  • 301
  • 301
  • 301 ST
  • 301
  • 301
• If a single shot is taken using a Feature Code that is configured to draw a line or develop a breakline, it will place a single point at that location and will not draw a line. Also that single shot will be added to the DTM as a Random point despite the breakline 'configuration'

• 301 ST

• Each instance of a single-shot linear Feature Code will only draw a point (not a line) and will be added to the DTM as a unique Random shot. A single N/E/Z per Feature. The coding below will result in 3 surface Features in the DTM, containing a single point each.
• 301 ST
• 301 ST
• 301 ST

•  Refer to the following graphics as an illustration for what you would see with coding such as this.

The coding illustrated above does not pose any real problems with the resulting display or surface DTM. And lucky for the user that when InRoads Survey encounters only a single shot for a 'linear' code, that it's smart enough to add it into the surface as a Random point.

The only problem would be the unexpected nature of the results versus what one might be expecting, i.e. expecting a line and only seeing a point, or expecting a breakline in the DTM and only seeing random shots in the surface.

This technique can be used to your advantage if you have a linear code such as a flowline that is configured to create a breakline; however you want to take a single shot at a drain or inlet. By using that code with a ST and taking no other subsequent shots with the same code, it will be added as a Random shot and draw a point at that location.

• If a linear code is collected and the ST code is omitted, something a little different happens.
• 301
• 301
• 301
• 301
• 301
• 301

Unfortunately the InRoads Survey Field book doesn't give you any indication that a 'linear' code is being used without the necessary ST code. This is just something that you have to pay close attention to when you are reviewing field data.

In this case a single point will be placed at each shot identified with that Feature code as before; however it will be added to the DTM as a single surface Feature containing all of the single shot locations.

• The difference here is how the DTM Features are formed when that field data gets pushed to the surface. In this instance all of the similarly coded shots will be contained in a single Feature, but are still Randoms.

Note: A caution should be given here relative to this last scenario and variations in viewing data collected this way. This 'caution' is because the Surface (DTM) and Field book (FWD) are different databases using different display settings.

When the Field book data of this nature is viewed in the CAD file, it will be displayed as single points as already described. This is controlled by the Survey Feature portion of the Style that it is using as defined by the field code.

The surface data however is displayed using the Surface Feature settings contain on that Style. These settings are defined independently of the settings that define the Survey Feature, but they are typically synced up to view in a similar way. But remember that we are talking about a situation where the field code is configured to collect and draw a line, and export a breakline to the surface. This would require that the Surface Feature portion of the Style also be configured to expect that it would be dealing with a linear item. And that's what you'll notice in the next picture of the Surface Feature settings.

The surface settings are configured to view that field data as a line, and not a point.

Because of these settings, viewing the surface Features from the last scenario will produce a linear graphic from the surface, and point graphics from the field book. Basically, the Survey display side of the Style is smarter than the Surface display side of the Style. This only poses a problem when creating MicroStation base graphics from the surface model. And unfortunately this can be a common practice in some design workflows.

I hope this helps.

Civilly yours,  

-zen