Bug/feature: Use actual repeaters region data and not observer based

[luckystriike22]

Currently, a lot of data appears to be grouped based on the location of an observer. For instance, the 2-byte hash data for Maastricht (MST, the Netherlands) is collected by an observer that is marked as being in MST. Even data from Belgium that flows through that observer is labeled as MST. In my opinion, this gives a misleading impression of the data. It should instead be marked based on the location of the repeater that the data is passing through.

Issue:
Repeater data flowing through an MST observer is marked as MST. As a result, the 2-byte hash data that is collected becomes polluted with data from other regions. It would be helpful if the data could be filtered based on the actual region and if it were possible to retrieve all repeaters located within a specific region.

Possible fix:

• Add a way to configure (sub)region polygons per country.
• Mark each observer as belonging to a specific region.
• When new repeaters appear, assign them to a region based on an advertisement that includes the repeater’s location.
• Since repeaters are already stored in the database, data can be linked to a repeater. This can be done by mapping on the key byte (for 2-byte data) or, in some cases, on the full key.
• Allow data on the site to be filtered by region.

Possible issues:

• Mapping may be difficult because many users still use 1-byte messages, although this issue should diminish over time.
• This approach may require additional resources, as data will need to be mapped to both a repeater and its region.

[efiten]

Hi @luckystriike22 — thanks for the detailed write-up. We've worked out a design for this and would appreciate your review before we start implementing.

---

Design: Area-Based Visual Node Filter

Problem

The existing ?region= filter uses the observer's IATA code to attribute data. Any packet heard by an MST observer is tagged as MST — even if the transmitting node is in Belgium. This pollutes per-region analytics with traffic from neighbouring regions.

Approach

A new, separate display-side filter (?area=) that attributes packets to regions based on the transmitting node's own GPS coordinates (from its advert). The existing observer-based ?region= filter is kept unchanged alongside it.

Key decisions:

• Display filter only — no ingestor changes, no schema migrations.
• Nodes without GPS are excluded when the filter is active.
• Only the originating node counts — relay hops do not determine area membership.
• Only the node's own advertised lat/lon is used — relay hops are not used to infer region.

Config (config.json, server only)

Named polygon areas, same coordinate format as the existing geofilter:

{
  "areas": {
    "MST": {
      "label": "Maastricht",
      "polygon": [[50.84, 5.66], [50.87, 5.71], ...]
    },
    "BEL": {
      "label": "Belgium",
      "polygon": [...]
    }
  }
}

Managed manually in config.json for now. No UI editor in this milestone.

How filtering works

1. At query time, load the polygon for the requested area from config.
2. Query the nodes table (~1 500 rows) for nodes with lat/lon inside the polygon.
3. Cache the resulting pubkey set for 30 seconds.
4. A packet is included only if its decoded_json.public_key is in that set.

No DB schema changes. Performance impact is negligible at current scale.

Scope

The ?area= filter will be applied to:

• Nodes list
• Packets / Traces
• All analytics (hash sizes, collisions, channels, RF, distance)
• Map and Live view (best-effort)

Known limitations

• Packets from nodes with no GPS are excluded — consistent with your note about 1-byte messages being harder to map. This should improve naturally as more nodes upgrade.
• No management UI for areas in this milestone — polygons are defined manually in config.

---

Does this match what you had in mind? Any feedback before we start the implementation would be welcome.

[efiten]

Implemented in PR #839.

The area filter works differently from ?region=: instead of attributing packets to the observer's IATA location, it attributes them to the transmitting node's own GPS coordinates (from its advert). This fixes the cross-region pollution problem described in the issue.

What's in the PR:

• areas map in config.json — define named polygons or bounding boxes
• GET /api/config/areas — serves key/label list to frontend (no coordinates exposed)
• ?area=<key> filter on /api/packets, /api/nodes, and all analytics endpoints
• Pill-bar selector in the dashboard (auto-hidden when no areas configured)
• 30 s server-side cache for the node→area resolution (DB query + Go polygon check)
• No DB schema changes, no ingestor changes, existing ?region= filter untouched