Calculate Coverage

Calculate Coverage answers one question: which products does this project need from this type? It reports the answer per bouwnummer and writes it to an Excel workbook or a JSON file.

Unlike Missing Coverage, which inspects the open Revit document against live Alpha data, Calculate Coverage needs no open document and, when you use the JSON sources, no Alpha account and no API key at all.

Opening it

Click Calculate Coverage in the Tools panel of the Alpha ribbon.

Choosing the inputs

The project and the type are picked independently. Each can come from three places:

So a fully offline run is "Heijmans JSON" (or "Alpha JSON") for both sides. This is the intended way to check a project handed over as two files before anything is imported into Alpha.

The add-in checks the file you pick against the source you selected. If you point at a WOCO type export while "Heijmans project JSON" is selected, it says so instead of failing somewhere inside a parser.

Press Load. The add-in resolves which houses use the chosen type and lists their bouwnummers.

Choosing bouwnummers

Every matching bouwnummer is listed with its house type and block, ticked by default. Untick the ones you do not want, or use All / None. Verifying one bouwnummer is the quickest way to sanity-check a new project file.

Scope: which choices count as fixed

This setting changes the answer substantially, so it is worth understanding.

The default matters for Heijmans data in particular: Heijmans marks its VAR - … options (beukbreedte, entree, kapvorm, …) as CONSUMER but pins them per bouwnummer. With buyer choices open, a single bouwnummer therefore expands into every beukbreedte × entree combination the type allows; for a real B01, that is the difference between roughly 700 and roughly 12,000 products for one bnr.

Use buyer choices open when you are deciding what to export so the configurator and viewer are complete. Use house choices fixed when you want a specific bouwnummer's bill of models.

Filling the RVT / GLB columns

Coverage means "required and available", but a pair of JSON files says nothing about which files have been produced. There are two ways to fill that in:

• A live type. When the type comes from the Alpha API, the RVT/GLB status is read from Alpha's own coverage records.
• An export folder. Tick Also check an export folder and pick a folder. Any product with a matching <product>.rvt or <product>.glb under that folder (searched recursively, case-insensitively) is marked present. This is what makes a fully offline run report real coverage.

With neither, the RVT/GLB columns are left blank rather than claiming everything is missing.

Filtering on the element name

Name filter narrows the export to the products whose name matches a search term: "only the DAK models", "everything starting with B01_", a regex for a code pattern. It takes two choices: which name to test, and how to compare it.

The two differ exactly where a name override applies: a bouwnummer with Entree = ZGE can require a product named …_VGEL_…. Filter on the product name to ask "which models must exist"; on the generated name to ask "what did this bouwnummer itself ask for".

Matching is case-insensitive, like the export-folder scan; a filter that misses on casing alone would read as "nothing required".

Combining terms

Terms combine with AND, OR and NOT, grouped with brackets:

NOT binds tightest, then AND, then OR, the usual order, so A OR B AND C reads as A OR (B AND C). &&, || and ! work as aliases. Each operand is compared with the mode you picked, so under matches regex every term is its own pattern.

Two things worth knowing:

• Without any operator the whole box is a single term. VK eerste verdieping searches for that phrase, not for three words; multi-word names keep working exactly as before.
• Quote a term to search for the keywords themselves: "and" looks for the letters and.

The condition is applied to each name whole. With either name selected, VGEL AND ZGE needs one name to hold both terms; it will not take VGEL from the product name and ZGE from the generated one.

A malformed search (DAK AND, an unclosed bracket or quote) is reported in words and nothing is written.

The filter runs after the RVT/GLB check, so the rvt/glb columns are unaffected by it. Bouwnummers left with no matching product drop out of the export, and the Run info sheet records the filter and how much it kept. If nothing matches, no file is written and the window says so rather than leaving you an empty workbook.

Output

Pick Excel (.xlsx) or JSON (.json) and a file path. Leave the path empty to write to your Desktop with a generated name like coverage_DeGroteWielen_Veld1A_B01_20260803-1530.xlsx.

The workbook has three sheets:

The JSON output carries the same data plus the full choice list per row.

The grid in the window is a preview capped at 2000 products; the exported file always holds every row.

Splitting the output per bouwnummer

Split decides how the bouwnummers are spread over sheets and files:

With one file per bouwnummer, choosing …\coverage_run.xlsx produces …\coverage_run\coverage_run_bnr002.xlsx, …_bnr003.xlsx, and so on, a folder rather than 200 loose files on your Desktop. Open folder goes to that folder. Each file is a full report for its own bouwnummer: its Products sheet is re-rolled for that bnr only, and its Run info sheet notes which larger run it came from. This split works for JSON too.

A run of a single bouwnummer stays one file, since a folder holding one workbook helps nobody.

Product names and name overrides

The exported product name is the final name: the one the RVT/GLB file and the Revit group are called. Where a name override applies, the pre-override name is kept in the generated name column.

This matters when reading the output: Heijmans types deliberately map some variants onto a shared model, so a bouwnummer with Entree = ZGE can legitimately require a product named …_VGEL_…. That is an override, not a mistake. The generated-name column always shows the bouwnummer's own codes.

Warnings

Anything the run could not do cleanly is listed in the window and on the Run info sheet: a name override that still contained an unresolved placeholder, an exhaustive option missing from the type, a bouwnummer in the filter that does not exist, or a branch skipped for exceeding the combination cap. Coverage is never silently truncated.