Why this matters

In disasters and other connectivity outages, people on the ground often see road blockages, landslides, bridge damage, or other map-relevant changes before reliable Internet access is restored. Traditional reporting channels fail when cellular networks are down or overloaded.

This post shares a community-oriented experiment: using a LoRa mesh (Meshtastic) to send simple field reports from phones (via Bluetooth to a LoRa device) to a gateway that later publishes them as OpenStreetMap Notes once Internet is available.

Scope & safety: this is not an emergency response system. Please do not include personal data (PII) or life-critical requests. The goal is to support mapping workflows.

---

What we built (high level)

OSM Mesh Notes Gateway turns offline messages into OSM Notes:

1. A field volunteer carries a GNSS-enabled LoRa device (e.g., T‑Echo) and connects their phone via Bluetooth using the Meshtastic app.
2. They send a short message starting with #osmnote.
3. The message travels across the LoRa mesh to a node connected by USB to a Raspberry Pi gateway.
4. The gateway validates that the device’s last GNSS fix is recent (for mobility), queues the report if offline, and creates an OSM Note when Internet is available.
5. The gateway replies by direct message (DM) with an acknowledgement and privacy reminder.

---

Key ideas that make it work in the field

### 1) GNSS recency checks (mobility-aware) Because position updates and text messages may arrive separately in a mesh, the gateway uses the latest known GNSS position per device and enforces strict time thresholds (e.g., 15s ideal, 60s max) to avoid placing notes far from the real location (especially in vehicles).

2) Store-and-forward queue

If the gateway has no Internet, reports are stored locally (SQLite) and retried periodically. Users get a local queue ID like Q-0007.

3) “Queued → published” notifications

When Internet returns and a queued report becomes an OSM Note, the reporter receives a DM: Q-0007 → Note #1234567.

4) Deduplication without losing real repeated events

In disasters, identical text (e.g., “House collapsed”) may describe different places. Deduplication is intentionally conservative: it only suppresses accidental resends from the same device, within a short time window, and at nearly the same location.

---

How to try it

• Hardware: Meshtastic-compatible nodes, at least one with GNSS for field reports, and one connected by USB to a Raspberry Pi.
• Messaging: field users send #osmnote <your text>.
• Gateway: a Python service listens via USB serial, validates GNSS freshness, queues when offline, and posts to OSM Notes.

Source code + technical spec: see the GitHub repository (linked in the repo README).

---

Privacy and limitations

• Do not include personal data (names, phone numbers, exact addresses for individuals).
• OSM Notes are meant for mapping; they are publicly visible and may be moderated/closed.
• The mesh can be public; anyone on the same channel can read messages.

---

Credits

This work is developed within AC3 (Asociación de Cartografía Colaborativa de Colombia) as part of activities under the NASA Lifelines Speed Dating grant, aiming to improve offline field reporting for community mapping.

---

Next steps

• Broader field testing with more nodes and varied mobility.
• Improved volunteer field guides and deployment checklists.
• Optional extensions for private humanitarian reporting backends (out of scope for this MVP).

If you’d like to test, contribute, or replicate this in your region, please reach out via the repository.

---

Links

• GitHub Repository.
• Spanish explanation for NAS Lifelies.