BCF 2.1 geometry round-trip: why most tools lose data, and how to preserve it

BCF 2.1 was designed for issue exchange between BIM tools, but the geometry round-trip is where most tools quietly drop information. Here's what gets lost, why, and how to preserve full markup geometry on import.

BCF 2.1 is the BIM industry's lingua franca for issue exchange — every coordination tool worth using imports and exports it. But "imports BCF" doesn't mean what most teams think it means. The format carries enough information to reconstruct an issue's title, status, viewpoint, and screenshot in any compliant tool. What it carries badly — and what most tools quietly drop on import — is the actual markup geometry: the rectangles, clouds, dimensions, and callouts that the original reviewer drew on top of the page or model.

This is the gap that derails coordination workflows: you export a clean set of issues from Tool A, import them into Tool B, and the geometry shows up as a flat screenshot — useful for reference but no longer editable, no longer linked, no longer measurable. The next reviewer has to re-draw everything to actually move the issue forward.

This post walks through why the geometry round-trip is hard, what BCF 2.1 actually specifies, and how to preserve the full editable markup state on import — using LocusBIM's BCF importer as the worked example.

What BCF 2.1 actually carries

A BCF 2.1 file is a ZIP archive. Each issue lives in its own folder containing three things:

• markup.bcf — XML with the issue metadata: title, description, status, priority, assigned user, dates, comments.
• viewpoint.bcfv — XML with the 3D camera state (position, target, up vector, field of view) plus optional clipping planes, component visibility, and a <Components> list of selected element GUIDs.
• snapshot.png — A raster screenshot of how the issue looked when it was created.

The viewpoint XML has slots for <Lines>, <ClippingPlanes>, and <Bitmaps>, but those slots describe 3D constructs (a 3D line between two model points, a clipping plane normal, a bitmap positioned in 3D space). They don't describe 2D markup geometry — the rectangles and clouds drawn on top of a sheet inside a PDF viewer.

The result: a BCF export from a tool with rich 2D markup capability hits a fork in the road. Either it serialises markup geometry into a non-standard extension (typically a custom XML namespace inside viewpoint.bcfv or a sibling JSON file in the issue folder), or it flattens everything into the snapshot.png and accepts that downstream tools will only see the image.

Why most tools drop markup geometry on import

Three reasons, in descending order of how often we see them:

1. The importer is one-shot, not round-trip

Most BCF importers were built to handle the common case — pull issues from a coordination meeting back into a viewer so the team can see them. The exporter on the other side is doing the heavy lifting: capturing the camera, snapshotting the canvas, serialising selected elements. The importer just needs to recreate the issue card. Reconstructing markup geometry is out of scope because the importer was never given a place to put it.

2. Markup geometry needs a target document

A rectangle from Tool A was drawn on top of a specific PDF sheet (or in 3D space anchored to a specific element). To recreate that rectangle in Tool B, the importer needs to know which document or element to attach it to. If Tool B can't find the source PDF, it can't reconstruct the markup even if the geometry data is in the file.

3. The tool's markup data model doesn't match the source

Even when the geometry survives the wire, the receiving tool's internal markup format may not support every shape the exporter used. Bluebeam's freehand polyline becomes a generic polyline in Solibri. Revizto's revision cloud becomes a series of arcs in Navisworks. Each translation step loses fidelity.

What "preserve the geometry round-trip" actually looks like

A round-trip-preserving importer needs to do four things on every imported issue:

1. Detect the geometry payload. Check viewpoint.bcfv for custom extension namespaces and any sibling JSON file. Parse what's there into a tool-neutral list of shapes (tool type, stroke, fill, coordinates).
2. Resolve the target document. Look at the issue's source-file reference (BCF 2.1 supports a <DocumentReference> element) and try to match it to an open PDF or model in the current project. If no match, queue the geometry to a "pending" state.
3. Ask the user where to attach the geometry. When auto-match fails (no matching PDF, or multiple candidates), surface a small dialog that lists the imported issue + its reconstructed markup count, plus a PDF picker scoped to the current project. The user picks once per issue; the tool remembers the mapping.
4. Reconstruct the shapes with full editability. Each imported shape becomes a normal markup in the receiving tool — same right-click menu, same property panel, same selection behaviour as a hand-drawn shape. The shape carries an imported-from: bcf audit flag so the cost engine and other downstream tools know its provenance.

LocusBIM's BCF importer follows exactly this flow. When it finds reconstructed markups in an import, it opens a "Attach reconstructed markups" dialog that shows the count per issue plus a PDF dropdown pre-selected with the active PDF. The user clicks Attach; the markups appear on the chosen page as normal editable rectangles, clouds, and callouts. The dropped count (any shapes whose tool type isn't in the local registry) is surfaced inline so nothing disappears silently.

How to validate your own BCF round-trip

You don't have to take any vendor's word on this. The test is straightforward:

1. Pick a representative issue. Open a coordination issue in your current tool, draw a few 2D markups on a PDF (a rectangle, a cloud, a callout with text), and link the issue to a 3D element. This is a realistic mid-complexity issue.
2. Export to BCF. Use the tool's BCF 2.1 export. Unzip the resulting .bcfzip file and inspect the issue folder. Look for the markup.bcf, viewpoint.bcfv, and snapshot.png. Note whether there's a custom extension namespace or sibling JSON file carrying the 2D geometry.
3. Import into the receiving tool. Open the BCF in the tool you want to test. Look at the imported issue. Are the markups editable shapes, or is the screenshot the only trace of them? Right-click a "markup" — does the contextual menu treat it as a real markup or just an image?
4. Round-trip back. Re-export from the receiving tool and diff the issue folders. The markup count should match; the geometry coordinates should match within a small floating-point tolerance.

If the count drops, the receiving tool dropped geometry on import. If the geometry comes back as a flattened image, the receiving tool can render it but can't reconstruct it.

Every issue you import without its markup geometry is a small tax on your next coordination meeting — someone has to re-draw the same shapes before the conversation can continue.

Why this matters for AEC firms specifically

The interoperability story most BIM vendors tell is "we support BCF 2.1." That's true in the narrowest sense — they can read and write the format. But coordination is iterative, not one-shot. Issues bounce between tools across reviews: the structural engineer flags a clash in Solibri, the architect responds in Revit, the contractor adds context in Bluebeam or LocusBIM. Every hop is a chance to drop information.

When you're evaluating a coordination tool, run the four-step test above before you commit. The tools that preserve the geometry round-trip cost you less per issue over a project; the tools that drop it cost you a re-draw at every handoff.

Where to go from here

If you're already using BCF in your workflow, the next step is to audit one round-trip end-to-end with a representative issue — most firms have never actually inspected what their tools are writing.

If you're picking a new coordination tool, ask the vendor directly: "Show me a BCF round-trip between your tool and one other tool where the 2D markup geometry survives both directions." Most vendors will struggle to demo this on the spot, which itself is a useful signal.

LocusBIM was built around the assumption that BCF round-trip is the workflow, not the exception. The importer reconstructs markup geometry and surfaces dropped shapes explicitly; the exporter writes the same geometry payload back so the next tool in the chain can read it. If you want to see it in practice, the 30-day free trial unlocks the full BCF round-trip workflow — no credit card, no upload.