deflock-app/V2.1.1_OVERPASS_QUERY_OPTIMIZATION.md

Overpass Query Optimization - v2.1.1

Problem

The app was generating one Overpass query clause for each enabled profile, resulting in unnecessarily complex queries. With the default 11 built-in profiles, this created queries with 11 separate node clauses, even though many profiles were redundant (e.g., manufacturer-specific ALPR profiles that are just generic ALPR + manufacturer tags).

Solution: Profile Subsumption Deduplication

Implemented intelligent query deduplication that removes redundant profiles from Overpass queries based on tag subsumption:

• Subsumption Rule: Profile A subsumes Profile B if all of A's non-empty tags exist in B with identical values
• Example: Generic ALPR subsumes Flock, Motorola, etc. (same base tags + manufacturer-specific additions)
• Query Reduction: Default profile set reduces from 11 to 2 clauses (Generic ALPR + Generic Gunshot)

Implementation Details

Location: lib/services/map_data_submodules/nodes_from_overpass.dart

New Functions:

• _deduplicateProfilesForQuery() - Removes subsumed profiles from query generation
• _profileSubsumes() - Determines if one profile subsumes another

Integration: Modified _buildOverpassQuery() to deduplicate profiles before generating node clauses

Key Benefits

✅ ~80% query complexity reduction for default profile setup
✅ Zero UI changes - all profiles still used for post-query filtering
✅ Backwards compatible - works with any profile combination
✅ Custom profile safe - generic algorithm handles user-created profiles
✅ Same results - broader profiles capture all nodes that specific ones would

Performance Impact

• Query clauses: 11 → 2 (for default profiles)
• Overpass load: Significantly reduced query parsing/execution time
• Network efficiency: Smaller query payloads
• User experience: Faster data loading, especially in dense areas

Architecture Preservation

This optimization maintains the app's "brutalist code" philosophy:

• Simple algorithm: Clear subsumption logic without special cases
• Generic approach: Works for any profile combination, not just built-ins
• Explicit behavior: Profiles are still used everywhere else unchanged
• Clean separation: Query optimization separate from UI/filtering logic

The change is purely a query efficiency optimization - all existing profile matching, UI display, and user functionality remains identical.