Quality-rule execution

A quality-rule instance combines an object-group population with a configured SQL condition. Business-group assignments determine who can access and process the resulting findings.

Query scope

The query considers the selected authorised territory, enabled rule definitions and applicable filters. Published reference tables provide the objects and geometries. The object-group relation test used by administration is a different path from the rendered-geometry quality query.

Detailed map requests apply a per-group display limit while retaining a total for the relevant scope. Low-zoom requests aggregate density to avoid transferring every detailed geometry. Neither a display cap nor a density cell is a database deletion or a resolved finding.

Processing a finding

Processing records the typed OSM object, version, rule instance, user and date in lbt_quality_processed_items. Server-side checks validate the caller's access to the rule. The record does not modify an OSM primitive or create an approval in lbt_validation.

A subsequent version or a different rule represents a different processing context. Use Quality to explain this distinction to reviewers.

Authoring and maintenance

Only administrators should edit rule SQL. The form expects a condition handled by the application's query construction and validation, not arbitrary maintenance statements. Test a focused condition and inspect representative matches before assigning it broadly.

Document the intention, expected exceptions and responsible team in the rule description. When diagnosing slowness, identify the rule and territory rather than raising the display limit. See Performance.