← Back to Blog
Tools & WorkflowSeptember 19, 2026 · 9 min read

Field-to-Finish Point Coding: What Your Crew Can Do to Make the Drafter's Job Easier

Whether a topo drafts itself in an hour or costs someone a day of manual cleanup is decided in the field, not at the workstation. The difference is almost entirely point coding discipline — and most of it comes down to habits a crew can fix in a week.

Field-to-finish is the workflow where the descriptions your crew attaches to each shot drive automatic drawing generation: symbols placed, layers assigned, linework connected, all without a drafter manually tracing anything. When the coding is clean, a few thousand points come into the drawing already looking like a survey. When it isn't, someone spends the morning connecting dots by hand and guessing what “EP” meant on shot 847 versus shot 848.

The important thing about that split is that the office has almost no control over which way it goes. The drafter can build the best description key set in the world, and it does nothing if the crew shot inconsistent codes. This is a field-side problem with an office-side symptom.

What the CAD Side Is Actually Doing With Your Codes

Both major packages work on the same principle, with different names for the machinery.

Civil 3D uses description keys. A description key set matches incoming point descriptions against patterns (wildcards included) and controls what happens to each match: which point style and symbol gets applied, which label style, which layer the point lands on, and how the raw field description translates into a full description in the drawing. Parameters like $1 and $2 let a key pull extra information out of the description itself — so TREE 12 OAK can become a tree symbol with the size and species carried into the label. Linework is handled alongside this through the figure prefix database, which decides which codes create figures and what layers and styles they get.

Carlson uses a field code table (the .fld file) doing essentially the same job: each code entry defines the layer, symbol, whether the code generates linework, what linetype it draws with, and whether the result is a 2D or 3D polyline.

The practical takeaway for a field crew is the same either way: the description string is not a note to yourself. It's an instruction to software.Anything that doesn't match a code in the table doesn't get processed — it just becomes a point with a description nobody asked for, sitting on a default layer.

Linework Control Codes: The Part That Lives in the Field

Symbols and layers are the easy half; the software handles those from a straight code match. Linework is where the crew's decisions in the field directly control the output, because only the crew knows which shots are supposed to connect to which.

Exact codes are configurable and vary between shops and software setups, but the concepts are universal:

  • Begin and end — a code that opens a new figure and one that closes it out. Common defaults are some form of B/BEG to start and E/END to finish.
  • Close — typically CLS, telling the software to connect the last shot back to the first, closing a building, island, or any other polygon without requiring a duplicate shot at the starting corner.
  • Curve — codes that tell the software to fit an arc through a run of shots rather than connecting them with straight segments. Essential on cul-de-sacs, curb returns, and anything else genuinely curved.
  • Numbered strings— the one that saves the most grief. When you're shooting two or more concurrent linework runs (both edges of pavement, say), numbering them (EP1, EP2) keeps them as separate figures. Without it, the software connects shots in the order they were taken and you get a zigzag stitched back and forth across the road.

The Mistakes That Cost the Office the Most Time

Almost every field-to-finish failure traces back to one of these:

  • Inconsistent codes between crew members. One party chief shoots EP, another shoots EOP, a third writes EDGE. Only one of them matches the table. This is the single most common cause, and it's purely an agreement problem, not a skill problem.
  • Typos. A single mistyped character produces an orphan point that never joins its figure — and because the linework still draws, the error is easy to miss until someone notices a gap.
  • Missing numbered strings on concurrent runs. Produces the zigzag described above, and untangling it manually takes longer than the shots did.
  • Forgetting to close figures.Buildings that don't close have to be closed by hand, one at a time.
  • Shooting out of sequence along a line. The software connects in shot order. Doubling back mid-run produces linework that crosses itself.
  • Free-form descriptions.“edge of pavement by the big oak” is a note, not a code. It matches nothing.
  • Too few shots on a curve.Three points on a cul-de-sac produces an arc that doesn't match the ground, and the office has no way to know that from the data.

Building a Code List Your Crew Will Actually Use

The fix for nearly all of the above is a written, agreed-upon code list — the same problem, and the same solution, as building a written field note standard. A few things that make the difference between a list that gets used and one that lives in a drawer:

  • Keep it short. A list of 200 codes nobody remembers is worse than 30 codes everyone uses correctly. Add codes when a job genuinely needs them.
  • Make it match the CAD table exactly. The field list and the description key set / field code table are the same document viewed from two ends. If they drift apart, the field is coding against a standard the office no longer uses.
  • Put it in the truck, not just on the server. A laminated card or a reference inside whatever the crew already has open beats a PDF nobody opens in the field.
  • Review the first drawing with the crew. Showing a party chief the linework their codes produced is the fastest training there is — the feedback loop between field decision and CAD result is normally invisible to the person making the decision.

Consistency across multiple crews is its own problem, and it's worth reading how to keep field data consistent across crews alongside this — a code list only works if every crew is working from the same one.

Anything the Codes Can't Carry Goes in the Notes

Point codes are a constrained language on purpose. They can't express “the curb here is broken and the shot is on the remaining edge” or “this fence corner is set 0.4' inside what looks like the occupation line.” That context has to live in the field notes, tied to the same job and ideally to the same point numbers, or it doesn't survive the trip to the office at all.

This is the same principle covered in the most common field note mistakes: the measurement is only half the record. A clean set of codes gets the linework drawn. The notes are what let anyone understand it six months later.

Quick Reference

  • Civil 3D — description keys control symbol, label, layer, and description translation; figure prefix database controls linework
  • Carlson — field code table (.fld) defines layer, symbol, linework behavior, and linetype per code
  • Linework codes — begin, end, close, curve, and numbered strings for concurrent runs
  • Biggest single failure — crew members using different codes for the same feature
  • Number your concurrent strings (EP1, EP2) or the software will connect them into a zigzag
  • Codes can't carry context — condition, ambiguity, and judgment calls belong in the field notes

The context your codes can't carry

SlateTablet keeps structured field notes and geotagged photos tied to the same job and point numbers as your shots — so the judgment calls behind the data reach the office along with it.

Get Started