Apologies if this is not the right place for this

I believe there is supposed to be a map app for web. Is the intended design of that documented anywhere, and is there a development roadmap? I think an issue would be a good place for that. I have no idea where to start though... because the client can't assume that it has access to the corporate internet, right? Or can we make the assumption that pre-disaster, the user has opened the app while connected to the internet, so we can fetch some maps near them?

Also, I believe GPS still works with no service, so would a reasonable proposal be to use some react-leaflet type thing, with GPS (something like this)? But err on the small, lightweight, PWA side of things, like this neat app?

resources

Offline maps, a shared problem in need of a shared solution

Hi! There isn't a road-map and this is a good place to talk.

The plan is to host an offline vector map of the local area on the disaster-radio nodes on a microsd card. This card will probably be 128 MB. The vector maps will be rendered in-browser by the client.

GPS will work on the devices accessing the disaster.radio web app, but of course only if they have GPS. The disaster.radio nodes will know their own positions (either through wifi-based positioning or because the node-operator is asked to provide this during initial setup).

Here are some of the challenges and my notes from when I last looked at it:

Generating the offline map-tiles

There is already software to do this but it should probably either be bundled as a vagrant system or at least set up on a server for the devs to access as getting this all set up is non-trivial.

We will need to strip out the zoom-levels we don't want (very near and very far) due to storage constraints, select the target geographical area and strip out irrelevant details in the map to both reduce map size and client-side rendering time. We will also want to change the styles (colors etc.) though that is less important right now.

Generate our own maptiles

https://github.com/openmaptiles/openmaptiles/

Downloading tiles

You can download a custom extract of openstreetmap tiles for $10 at: https://openmaptiles.com/extracts/

This might be useful to start developing on the other aspects of this project but eventually we'll need our own solution.

Notes on downloading and slicing pre-generated tiles

Some notes I wrote for myself a while back:

https://openmaptiles.org/docs/generate/create-custom-extract/

https://openmaptiles.com/downloads/

Install tilelive and MBTiles support.

npm install -g tilelive mbtiles

Visit boundingbox.klokantech.com and drag a rectangle around your desired area.

Copy the bounding box in CSV format

To create an extract the tilelive-copy utility is used. It takes a bounding box and a MBTiles file as input and creates an extract clipped to the bounding box.

Replace the bounding box in the following command with your bounding box.

tilelive-copy \
    --minzoom=0 --maxzoom=14 \
    --bounds="5.9559,45.818,10.4921,47.8084" \
    planet.mbtiles extract.mbtiles

Use mbutil to extract .mbtiles to directory of vector files:

mb-util --image_format=pbf extract.mbtiles extract_dir/

These files will be called .pbf but they are actually .pbf.gz and if your webserver doesn't send gzip as the content-encoding then it won't work. To un-gzip them for development purposes do gunzip -S ".pbf" -r extract_dir and ensure that the tiles url in the javascript now references e.g. /extract_dir/{z}/{x}/{y} instead of /extract_dir/{z}/{x}/{y}.pbf.

removing unneeded layers and shrinking file size

https://github.com/rastapasta/tilegrinder

https://github.com/rastapasta/tileshrink

Rendering and UI

We'll need something that is fast and light-weight for the client side rendering. The ESP8266 is slow at sending data over wifi so we don't want to hav eto send megabytes of javascript to the client.

Existing code

Some of this might be interesting:

vector rendering for leaflet OSM OpenLayers In-browser tile slicing! probably not viable(?) but cool OSM editor

Server

Serving up the tiles should be doable from just a properly organized file-system over HTTP. Mostly the challenge will be configuring the ESP8266 to talk to the microSD card and not having that interfere with the rest of its critical operation. We may have to switch to an ESP32 if this proves infeasible.

Heya! I saw this while I was on a train without wifi, and I wrote a bit about my thoughts on this:

Disaster Radio: Offline Maps

Mapeo Desktop is a native Electron app for Windows, macoS, and Linux for viewing and editing offline maps, compatible with OpenStreetMap. Users sync map edits to each other using USB keys (a sneakernet or over the local network.

Disaster Radio is a long-range low-bandwidth mesh network that can be deployed at a city scale to permit networking in disaster situations, or in places that lack existing internet infrastructure.

Finally, Secure Scuttlebutt (SSB) is a distributed network protocol and platform, which works well in offline environments. Users exchange messages across peers using a gossip protocol, where friends share their feeds with other friends until they reach the breadth of their social graph.

Mapeo Desktop and SSB could be modified to work with Disaster Radio. Here is how I think this could work:

Writing Map Data

In OSM, all edits to a map are wrapped in a changeset, which has a unique identifier and can be used to identify all of the edits that were made by a certain user at a certain time. When a changeset is submitted via Mapeo:

That changeset is published to the local disasterradio node, if one is in range. The LoRa radio will broadcast a serialized version of the changeset in some compressed binary format.
That changeset is simultaneously published to SSB, as a custom diasterradio/map/changeset message type.

This dual-broadcast will allow the map edits to reach other users in two different ways:

The LoRa broadcast, while low bandwidth and high latency, enables map edits to reach a very broad audience.
The SSB publish will allow the map edits to propagate via local wifi networks (SSB does this automatically) and also via internet if a user with the map edits happens to find themselves connected to a network with such access.

Reading Map Data

Users can receive map edits in two ways, as established above: via a Disaster Radio node they are connected to via wifi, or from another user via SSB. Edits received over Disaster Radio will be published to their local SSB database, so that SSB can be used as the principal database for apps to read map data from.

Reading and writing map data will happen through a custom SSB plugin: a program we can pre-publish with Disaster Maps (or whatever we call it) that is offers APIs for publishing and querying map data.

Message Deduplication

Users who receive map edits via Disaster Radio will check their local SSB database to see if the edits have already been published. If they don't see the edits locally, they will publish that map data to SSB as well.

However, it's possible that the map edits were published to SSB by other users and just haven't propagated their way to this user yet. This means some map edit messages will be published to SSB multiple times. This redundancy is OK: the SSB plugin that exposes the map read/write API will deduplicate redundant messages so applications won't need to worry about it.

Aerial Imagery

Aside from map elements like schools, lakes, and relief centers, there is also aerial / satellite imagery. This raster data is very useful for identifying landmarks and context that may not be explicitly placed by anyone on the map. It is essential that offline imagery be made available as well.

Mapeo supports bundling offline imagery, but it's still a fairly manual / technical process. It would be possible, in the interim, for Disaster Radio developers to pre-download and load this imagery for known areas of interest with the Mapeo bundled on USB keys.

App Distribution

Mapeo Desktop is an Electron app. Electron packages a subset of the Chromium web browser, so it is known for creating rather large app downloads. We determined that the app (over 50mb) will be too large to store and distribute from a Disaster Radio node, so for now the app will be packaged for all 3 major platforms on a USB key situations near/with each Disaster Radio node. This is flexible & powerful: other app authors could also distribute their apps on this key, or even store offline map data for an area that's ready to go!

Thanks! I am still just entering this world (SSB! Mesh! This stuff is so cool!), so forgive any n00b thoughts:

Is the limiting factor here going to be the size of messages exchanged over Disaster Radio? I think I read about a fairly small maximum packet size, and rules that looked more like UDP that TCP...
Sorry if you aren't into this format, but are these user stories accurate?

As a user during a disaster (UDD), I would like to connect to the Disaster Radio network (without having connected prior to the disaster), and be able to load a map of the area (the map app)
As a UDD connected to the map app, I would like to see my location, via GPS
As a UDD connected to the map app, I would like my position to be more accurate (by triangulating based on signal strength of various transmitters, or by )
As a UDD I would like the map app to allow me to mark areas (for example, as "safe", "hazardous", etc)
As a UDD, I would like to see the marks other UDDs make on their maps (is this done with a Waze system - is there a fire here? - or is UDD input assumed valid, or something else?)

Also, even though it has to work for UDD w/o having connected prior to the disaster, maybe it can be optimized for UDD who connected before the disaster, when the network still had a connection to the corporate internet? Then, many users on the network could have the maps in localStorage.

Definitely not n00b thoughts. :) Asking Qs from the user's POV feels like a good exercise.

Yes, I think packet size will be challenging. This is why I think relying on LoRa for message dissemenation should be a best-effort, and rely on user-to-user message scuttlebutting for more reliable data transfer.

Sounds good. The map app is an Electron desktop app only right now, which is too big for the DR node to transfer via wifi. Me and @juul were thinking that we could package a USB key with each DR node that users can use to copy the app binary to their machine and run it. From there, it would presumably find the DR node on the local network and be able to transfer map edits to it for dissemenation.
Desktop app only right now, so probably no GPS. :( Maybe we could hack something together where we hardcode each DR node to know its deployment location, so you'd at least know where you are when at a DR node, but that might be a stretch for this prototype.
Same as 2 ^^^.
Yes: included. Just like with OpenStreetMap, you can create points, lines, and areas and tag them however you'd like. Maybe we could create some presets for common objects like safe/danger zones, shelters, and so forth.
Yes: included. Syncing through a DR node or over SSB should pull in edits from everyone else. I think we'd assume valid user input for now -- I'm not sure how else it might work.

This issue is stale. We have since written a mapping web app that uses MapBox tiles and requires an SD card to store the map tiles, https://github.com/sudomesh/disaster-radio-map, We also have a BLE android app that provides a map, https://github.com/beegee-tokyo/disaster-radio-android. There have been similar discussions about how to distribute the android app without real internet.

There are a lot of great ideas in this thread,so I encourage people continue referencing this issue, but I am going to close it to remove cruft.

If new ideas or issues arise related to maps or the distribution of apps/files on the network please open a fresh issue.

sudomesh / disaster-radio

Map #10