Bug Description

The Map Analysis view's node type filter uses MeshCore-centric category names regardless of which source types are actually connected. On a Meshtastic-only instance, the filter categories don't map meaningfully to Meshtastic node roles.

Current Behavior

The filter exposes 5 fixed categories (nodeTypeCategory.ts):

• Companion → MeshCore advType 1 only (no Meshtastic equivalent — never matches)
• Repeater → MeshCore advType 2 OR Meshtastic ROUTER role
• Room Server → MeshCore advType 3 only (no Meshtastic equivalent — never matches)
• Sensor → MeshCore advType 4 only (no Meshtastic equivalent — never matches)
• Standard → everything else — collapses all remaining Meshtastic roles (CLIENT, CLIENT_MUTE, TRACKER, SENSOR, CLIENT_HIDDEN, LOST_AND_FOUND, TAK, TAK_TRACKER, ROUTER_LATE, CLIENT_BASE) into a single bucket

The filter has no awareness of which source types are connected (NodeTypeFilterControl.tsx has no access to source connection state).

Expected Behavior

On a Meshtastic-only instance, the filter should expose Meshtastic role names with meaningful granularity (e.g. CLIENT, ROUTER, TRACKER, SENSOR, ROUTER_LATE, CLIENT_BASE, etc.).

Ideally the filter adapts based on connected source types — showing MeshCore categories when MeshCore sources are present, Meshtastic roles when only Meshtastic sources are present, or a combined/unified view when both are connected.

Impact

• Meshtastic users cannot filter by meaningful node roles in Map Analysis
• Three filter options ("Companion", "Room Server", "Sensor") are permanently empty on Meshtastic-only instances
• All non-Router Meshtastic nodes are indistinguishable in the filter

Relevant Files

• src/utils/nodeTypeCategory.ts — categorization logic
• src/components/MapAnalysis/NodeTypeFilterControl.tsx — filter UI
• src/components/MapAnalysis/layers/NodeMarkersLayer.tsx — filter application

Authored by NodeZero 0️⃣