The Archives link lists all posts...

Civil 3D Survey Query Name Rules

Tags survey, query, names, naming conventions, implementation

Certainly our Civil 3D civil engineering and survey projects share a common survey and design language: Keys (Point Keys), Codes (Figure Prefix Names), and therefore typical Survey Query logic.

The Civil 3D Survey Upside Down

We covered some of those Stranger Things last time in Civil 3D Survey Query Essentials post and video.

The Framework for Civil 3D is, in part, all about what I call The Power of Names. Simply put what you name it always matters in Civil 3D if you want to become more productive. Register and learn more about that in our Members>>Documentation and Help section.

Based on a wee bit of Civil 3D Survey experience in this Upside Down, two brief naming rules for Survey Queries are probably all that’s needed.
One for Generals and another for object type Specifics.


Name rule chunks are separated by a hyphen (“-“) character delimiter.


Used for important non-specifics. You may employ a two-digit number to sort these into an order that makes sense to the normal data assessment and quality control tasks you must perform.
Hint: Using plain text names and raw alphabetical sorts becomes no fun when your Library becomes substantial and well-developed.
Yes. This is pretty familiar if you use the Framework Toolspace Style name and Civil 3D Feature naming rules.

The General rule is intended for things like show or get:

  • All the points with an Elevation sort
  • All named figures with number of Vertices sort
  • All the edited Figures (i.e. Autogenerated = No =False) – someone edited it
  • All named Figures (with Points) on these Layers
  • Etc

Employ classic camelback strings in <GeneralContent> (e.g. “00-AllPointsAndFigures”) for readability.

Start the <GeneralContent> string with our Civilized NCS Standard Keys when that makes sense
(e.g. 10-UTSS-AllSewer or 00-ROAD-EDGE). Get those useful Open Keys here.
See the Specifics rules below for other ways to do this.


Name rule chunks are separated by a hyphen (“-“) character delimiter.

<Object><Key|Code> More Key|Codes...<Optional Sort Type>

Specifics are employed for more detailed and specific view and edit tasks.

The Specific rule is intended for task-based things like show or get:

  • points and figures outside of a roadway
  • only the pavement paint figures
  • only edge of travelled way figures and points
  • flowline figures with top of curb points
  • only sewer manholes, inlets, and structures
  • etc

<Object> type name codes:

  • A = Points only for Annotative Label Edits and/or Code checks
  • B = Both Point and Figures are the same and included
  • F = Figures only are included
  • P = Points only are included
  • D = Different Point and Figure queries

<Key|Code> type name codes:

  • A Standard NCS 4-digit Key may be used in the first and other <Key|Code> position as shorthand for typical collections
  • Keys Values match preferred Point Keys – the survey raw not Key Set resolved Descriptions
  • Codes Values match Figure Prefix Codes - Figure Names

For any Queries in Libraries supplied in the Framework - the Keys and Codes are typically matched as per Framework integrations and the name rule methods employed in the Framework’s Spreadsheet Tools for Survey Codes, Description Key Sets, and Figure Prefix Libraries.

<Optional Sort Type>
These are typically confined to simple “ELEV”, “CNT”, etc. suffixes.
On a practical basis Sort orders can be easily changed in the respective Editors.

Survey Query Descriptions

  • Be careful to include and update the external Survey Query (QML) descriptions.
  • Descriptions must be short.
    Only a single line of text is supported – no line feeds allowed.
  • Be concise. A list of space delimited Codes can be used to speed up QML edits and maintenance.

Survey Query Hints

The previous post and video – Civil 3D Survey Query Essentials covered some of these.

  • Keep it simple and double check the Value entries and results carefully
  • Queries change and can get better which is why a Survey Query Library matters
  • Many basic, critical, and often employed queries are groups of somewhat similar OR conditions
  • Be aware of accidental ANDs in front of ORs that may wreak havoc on the unwary
    A logical AND is the Survey Editor default
  • You can temporarily change the Property condition of the last row in an existing query to ADD a new condition row below when one is not obviously available in the Query Editor.
  • starts with and contains are definitely not the same thing
    Use contains when you mean it. The search is for the entire text string in the Survey Db.
  • You can combine a group of starts with plus OR conditions with a final condition AND conditions, that employ contains to effectively exclude data.
    For example all data that includes a “1” or “2” to separate lefts and rights without lots of individual specific OR conditions.
  • The Points and Figures sections are two independent and potentially unrelated queries
    This can be more useful than you may expect to provide visual context for decisions.
  • Due to recent Windows XML security updates Survey will convert all exported or imported query properties to the default contains.
    That’s annoying, but an external query still saves us time and produces consistent repeatable results faster.

QML Query Edit Hints

  • It is generally faster to edit and copy the QML files than build them individually in Civil 3D
  • If you edit the QML files, employ an editor that will validate the finished XML syntax.
    The Survey Query Editor does not like bad QML files.
    I employ Notepad++ which allows me to Search and Replace update the strings in multiple open files at once.
  • You can ADD or remove default empty condition rows in the QML that display (or not) in the Survey Query Editor
  • Test queries in multiple Survey Db datasets to reduce the prospect of unforeseen and unexpected circumstances and consequences
  • The current name of the query appears twice in the QML file along with the originating file name reference.
    Maybe you really want all to be the same when you copy to create a new QML file?
  • You can replace the drawing, project, and user specific XML text strings in the QML file.
    Currently Civil 3D seems to care about the file name on load, but Civil 3D will always update these details when changes are saved to the QML from inside Civil 3D.
  • That external Survey Query SAVE feature can be a useful form of audit.
    Where did the latest changes come from for a library that is shared or not.
  • The GUID ids in the QML file refer to GUIDs from the originating SurveyDb.
    They are not checked, validated, or updated if the QML file is employed externally.
    These will be updated after an Import into a Survey Db and a subsequent new Export.

Needless to say if you own the Framework for Civil 3D, you should employ a copy Survey Code Spreadsheet Tool, Description Key Set Tool, and/or Figure Prefix Spreadsheet Tool to aid you in the Query specifics. The tools help you document and keep the pieces working well together.

Don’t have the Framework Spreadsheet Tools? Our customers say the Spreadsheet Tools alone are worth the price of admission. The reason?

The Freedom to Work Better in Civil 3D

The following list of posts - most of which contain videos - should help you get your head around Survey Query basics, method and practice, and/or useful workflows in AutoCAD Civil 3D.

The Recent Survey Query Series