Parcel Fabric Topology Compliance

Purpose

Parcel Fabric Topology Compliance validates cadastral parcel and administrative boundary topology, detects overlaps and gaps, and enforces compliance with land fabric standards enabling authoritative reference data maintenance.

Typical Questions This Tool Helps Answer

• Which parcels violate topology rules (overlaps, gaps, slivers) and where are they located?
• Will our parcel fabric pass jurisdiction-specific quality thresholds before publication?
• What can be safely auto-fixed now versus what requires manual cadastral review?

Background

Network planning workflows use graph-theoretic representations of roads, routes, or linear assets, where node-edge topology and impedance attribution directly control results. Missing restrictions, incorrect turn logic, or stale demand assumptions can dominate outcome quality.

These tools are best interpreted as constrained optimization and diagnostics frameworks. Decisions should be based on trade-offs across service, resilience, and cost objectives rather than any single metric.

Land-fabric topology compliance checks enforce geometric and adjacency integrity so downstream governance and analytics are legally and operationally defensible. Error classes should be triaged by business impact.

Methodological Considerations

• Topology validation should precede optimization or scenario simulation.
• Explicitly represent operational constraints (time windows, restrictions, capacities, closures) before comparing objective outcomes.
• Test outcomes under stress scenarios so selected plans remain stable under realistic disruptions.

Practical Interpretation Pitfalls

Single-metric improvements can hide degraded resilience or equity; compare candidate plans across multiple KPIs and scenario conditions.

Inputs

For sliver detection, the workflow first measures parcel area from geometry. If that is unavailable, it falls back to an existing area field named gis_area, shape_area, shape_starea__, st_area, or area.

Parameters

Outputs

Output artifact keys below are runtime outputs, not input parameters.

Important JSON report fields

Returned payload keys

The workflow returns these output keys:

• topology_violations
• issues_csv
• compliance_report
• summary (same file as compliance_report)
• corrected_parcels when auto-fix is enabled
• remediation_queue_csv when requested
• html_report when requested

Example

import whitebox_workflows as wbw

env = wbw.WbEnvironment()
env.parcel_and_land_fabric_topology_compliance_workflow(
        parcels="county_parcels.gpkg",
        jurisdiction_template="ontario_mpac",
        min_sliver_area=2.0,
        auto_fix=True,
        topology_violations="/tmp/parcel_violations.gpkg",
        issues_csv="/tmp/parcel_issues.csv",
        compliance_report="/tmp/parcel_compliance.json",
        corrected_parcels="/tmp/parcel_corrected.gpkg",
        remediation_queue_csv="/tmp/parcel_remediation_queue.csv",
        html_report="/tmp/parcel_compliance_report.html",
)

References

• NSDI cadastral data standards
• Ontario MPAC parcel-fabric operating practices reflected by the ontario_mpac template

Parameter Interaction Notes

• If you omit min_sliver_area, the workflow uses the default attached to jurisdiction_template.
• If you supply min_sliver_area, that explicit value overrides the template default.
• pass_fail and rule counts are based on the pre-fix audit stage, even when auto_fix=true.
• sliver_calibration_profile is useful for deciding whether your current sliver threshold is too aggressive or too permissive.

QA and Acceptance Criteria

1. Confirm the parcel layer is polygon or multipolygon geometry in a projected CRS.
2. Confirm the example arguments match the runtime names exactly.
3. Verify issues_csv uses the header feature_fid,geometry_type,issue_type,detail.
4. Verify topology_violations contains the documented fields.
5. Verify compliance_report includes the documented keys, including pass_fail and sliver_calibration_profile.
6. If auto-fix is enabled, verify corrected_parcels exists and auto_fix_enabled=true in the JSON report.
7. If remediation_queue_csv is requested, verify its header is priority,issue_type,rule_or_code,count,recommended_action.

The workflow fails if the parcel layer is unreadable, not polygonal, not projected when CRS metadata is known, missing required output arguments, missing corrected_parcels while auto_fix=true, or uses an unsupported jurisdiction_template.

Advanced Operational Guidance

• Review issues_csv and topology_violations together. The CSV is better for spreadsheet triage; the point layer is better for map review.
• Be cautious when increasing min_sliver_area. Small valid parcels can be reclassified as remediation items if the threshold is too high.
• Use auto-fix only inside a controlled review workflow. It helps with cleanup, but it does not replace parcel governance.
• If you intend to standardize thresholds across jurisdictions, compare calibration profiles first rather than copying one template blindly.

Implementation Patterns

• Baseline audit: run without auto-fix to produce the compliance package.
• Review triage: add remediation_queue_csv to split overlap, gap, and sliver work.
• Controlled cleanup: enable auto-fix, review autofix_changes_applied, then rerun the workflow if you need a refreshed compliance status.
• Threshold calibration: compare multiple min_sliver_area settings before locking a program standard.

Related Tools

• topology_validation_report
• topology_rule_validate
• topology_rule_autofix
• crs_harmonization

When To Use This Workflow

Use this workflow when parcel-fabric maintenance needs a complete QA package rather than a one-off geometry repair. It is especially useful when you need to separate geometry QA, rule-based violations, sliver threshold review, and remediation planning into one repeatable deliverable.

What this workflow helps you do:

• Measure parcel-fabric compliance in a repeatable way.
• Prioritize cleanup work by issue type.
• Document pre-fix condition separately from remediation activity.

Results Delivery Checklist

1. Deliver issues_csv, topology_violations, and compliance_report together.
2. State clearly whether generic or ontario_mpac defaults were used.
3. If auto-fix was enabled, call out that compliance metrics describe the pre-fix state.
4. Review sliver_calibration_profile before finalizing any policy recommendation around sliver thresholds.
5. Include remediation_queue_csv when the next step is operational cleanup assignment.

Common Questions

Q: Why can pass_fail still be false even when corrected_parcels was written successfully?
A: Because pass_fail reflects the pre-fix audit result. Auto-fix activity is reported separately through auto_fix_enabled and autofix_changes_applied.

Q: What does share_pct in sliver_calibration_profile mean?
A: It is the share of parcels smaller than each threshold in the calibration table. It helps you choose a threshold; it is not a legal compliance label by itself.

Q: Which setting most strongly affects sliver findings?
A: min_sliver_area. Even small changes can noticeably increase or decrease sliver_count, especially in dense urban fabrics.

Q: How should operations use remediation_queue_csv?
A: Use it to assign overlap, gap, and sliver work by priority. It is a work-planning output, not a substitute for the feature-level details in issues_csv.