Xref shells and partial views

A production civil drawing is rarely one self-contained file. It’s a host drawing plus external references (xrefs): the base survey lives in one file, the utility design in another, the proposed grading in a third, and each sheet drawing references the ones it needs. This keeps disciplines independently editable — and it shapes what you receive when someone “sends you the drawing.”

Three states of an xref, three very different files

Live xrefs, host only. If you receive just the host file, each xref appears as little more than a reference record — a path to a file you don’t have. The geometry isn’t there. A surprisingly common failure mode: a 300 KB “site plan” that renders as a title block and nothing else. survey_dxf_layers makes this diagnosis instantly (almost no entity-bearing layers), which beats discovering it three tools later.

Live xrefs, full set. With all the referenced files delivered alongside the host you have the data, but each file must be analyzed separately — the host still doesn’t contain the xref geometry.

Bound xrefs. Before sending files out, drafters often bind xrefs — merging the referenced files’ content permanently into the host. This is the best case for analysis: everything is in one file. But binding leaves fingerprints, and they matter for every layer-pattern parameter in this server.

What binding does to layer names

To prevent collisions between the host’s layers and each xref’s layers, binding rewrites the xref’s layer names with the reference name and a $n$ separator:

C-PROP-LINE            (in the referenced file, before binding)
XREF-PLAN$0$C-PROP-LINE  (in the host, after binding)

The digit increments when repeated binds would collide. Block names and text styles get the same treatment. After binding a multi-discipline plan set, the layer table becomes a paste-up of every referenced file’s layer standard — this is how a real subdivision plan set arrives at 941 layers, and why the original layer names you’d guess (C-PROP-LINE) may not exist at the top level at all.

The matching rule

Every layer-pattern parameter in the DXF analysis tools applies fnmatch twice: against the full layer name, and against the suffix after the last $. So:

• C-PROP* matches C-PROP-LINE and XREF-PLAN$0$C-PROP-LINE
• You write patterns against the layer standard you know; bound-xref prefixes are handled for you
• When you genuinely want only one bound reference’s content, match the prefix explicitly: XREF-PLAN$0$*

Without this rule, the intuitive pattern silently misses the bound half of the boundary linework — and a parcel extraction that sees half the courses doesn’t fail loudly, it just reports dangles where the missing layers’ segments would have closed faces.

Partial views are normal

The general lesson: any single CAD file is a partial view of a project, and the tools are designed to make the partiality visible rather than paper over it. The layer survey shows what’s actually present; parcel diagnostics count what didn’t close; annotation containers distinguish host content from block-embedded content. When results look thin, the first question isn’t “which tool failed” but “which files am I missing” — and the survey usually answers it.