As one of the most urgent issues is to create a cross-platform app, I collected some ideas and feedback about the current Android app to think about the next release.
Here is the mockup of how the app will look like, graphically very basic but usable and intuitive.
I forgot to add the channel QR part, I’d add it to the “Pairing” popover page.
Let me know what you think.
(click on the image to see it bigger)
I’m not sure if messages are (or can be) currently tagged with location data, but I like this UI from the inReach app.
It shows a tiny marker next to messages that have location data. Also, you can toggle the location on a per-message basis with the marker above the message composition window (bottom left in the image)
Perhaps that would simplify location sharing? I don’t know.
Of course, if you click the location icon next to the message, it shows message location and detail info with a link to that location on the map screen
I actually put the location sharing in the map, but I can instead create a multifunction button for the user to share the current location or (work in progress) small audio messages.
Going to the “Map” tab, what should the markers represent? Real time node location (a settings that, if enabled, sends the device position every x seconds)?
I’m not sure how it should work, but here’s the Map tab in Earthmate/inReach:
It shows message icons which link to the messages from those locations. It also shows a real-time location indicator (blue triangle).
The flags correspond to GPS waypoints. And there are GPS tracks/routes too. Nice features, but maybe out of scope.
Again, I’m not sure whether Meshtastic messages get tagged with geolocation info or not. But if they do, this is a useful interface. There have been many times where I got a delayed message from someone, and it was helpful to see where they were when the message was sent rather than where they are now. This would be improved by having the individual icons on the map being color-coded to each user, or avatars, etc.
Afaik, InReach doesn’t have the capability of showing friends’ locations on the map in real-time. This would be a good upgrade.
I’m also unsure of the plan to deal with privacy. There are many scenarios in which users won’t want to stream their location to everyone in the network. That is one advantage to being able to select location sharing userX-userY and per-message, which InReach provides. However, their userX-userY sharing does not work in the app, and requires opening a web interface, which is a cumbersome behavior.
[Edit] Here are all of the tabs in that app, though a few of them are unnecessary. Ultimately, it’s not a great app and I wouldn’t recommend exactly following its UI. It does have a few interesting features, and I’m trying to remember the ones I thought were good ideas.
Here is the function of the per-message location sharing. When you tap the icon, it provides a prompt about what’s happening and enables/disables location sharing. It’s sticky, so it stays enabled or disabled for that chat until it’s selected again.
This behavior is a really nice way to share location if it’s something that might work with Meshtastic.
The lightning bolt icon pulls up pre-composed messages. This can be helpful when you’re in a hurry or have wet hands that don’t work well on the touch screen. That’s probably not a high priority, but figured I’d show the feature while I have the screen open.
Quick update, BLE works and connects to other devices, QR scan ok, settings need to be defined.
Small problem: user avatar images, do we need them?
Huge problem: offline maps. Any idea?
I know OSM has offline datasets, but that’s not tiny. I bet the app could cache a certain amount of local mapping, though?
I read something about leaflet JS but I’m not totally sure that’s what we need. Is it possible to cache map tiles intentionally?
It is possible to download tiles to be used when offline. That can be done with your computer or with several map applications.
We should seek for a map engine that handles online (raster) sources, and offline maps (downloaded raster tiles, vector maps and even pdf maps?).
Something about offline maps discussed here: Offline maps on Meshtastic
I’ve been using a really amazing Android mapping app for 9 years called Orux Maps. The only option in the Play Store is a paid version. However, the developer provides a free version on their own website.
It has a fairly simple offline map creator in it. The default installation has map sources whose terms of services allow downloading. Unfortunately, I have added a bunch of custom map sources and can’t remember which are default.
It’s closed source, so maybe not that helpful. And also, it’s a feature-rich mapping app, and might be too complex for Meshtastic to use as a model. But as an example it’s worth a look.
PDF maps can be very handy.
I’d suggest that delineating between raster and vector for online and offline will lead to issues. One thing folks will run into is that areas where some of the primary ise-cases take place (hiking, etc.) have poor options, and vector sources end up being somethink akin to a big green blob.
The easiest interfaces I’ve run across (like the DJI drone mapping app) simply allow caching what you’re looking at online for future use offline and/or have a setting which enables caching all maps you view while you’re online (up to a user-selectable cache size).
I’ve noticed that a lot of apps developed by folks in more urban areas end up choosing map options which bias street grids. Then when users deploy the maps out in the woods, they lack useful details.
As a starting place, I’d recommend a minimum of two basemap options:
In another thread l linked some free offline maps that I have been using, these are free topographic maps, would it be possible to use these? The advantage is that their much more detailed than any other free maps I’ve found, down to 1:50k
Both of those pull from OpenStreetMap, which isn’t necessarily a problem. But to give you an idea of what I hope to avoid, this is a screenshot of the base OpenStreetMap for the 4km surrounding my location:
Of the 5 available layers, all are blank except what they refer to as the “Cycle Map”.
@geeksville, do you have a rough idea for v1.5 and later as far as the scope of Meshtastic as a mapping app vs. a chat/comms app? There seems to be a common issue wherein map apps try to glue on a few communications features and chat apps try to glue on some mapping features.
It’s not necessarily an easy question, and is likely why InReach, which started out as a satellite communicator then got bought out by Garmin. Garmin hasn’t yet done a great job of integrating the two either. Their InReach implementation still feels like a comms app with some mapping features duct taped to it, which is probably annoying to their users who still end up having to buy two separate Garmin devices and use two separate apps to accomplish both.
I’m a heavy-geeky user of map apps, and their functionality seems much more complex than chat apps. So I guess I’m wondering if and when it matters to start answering this question.
For my use-case(s), it would make sense to keep the mapping functionality relatively simple*, and add some kind of API that might feed the geolocation data to other apps. I haven’t looked into whether that’s a standardized process, but I can imagine it may be.
*The holy grail would be one perfect open source app that does it all perfectly, but that sounds like a huge undertaking.
Not exactly 
When I started this project I hoped to not even need to write a message app UI (i.e. use signal). But in terms of the amount of work, the UI for maps and the UI for messaging were both a fairly small amount of work (though as @lgx keeps improving it becomes less small )
Once 1.0 is “out the door” (or earlier if people want - but I’m not going to engage much in such ideation right now) we can have a group chat to go through the ideas and make rough buckets for:
There is already a very easy meshtastic API on android (and python) so if other apps want to use the mesh to do something fancier or custom they can do that also. The Android GUI app just uses the same “MeshService” android service as any other app would.
For 1.1/1.5 ideas see here:
An update of development status:
As suggested by Kevin, mapbox is working and is great. If anyone knows how to make it work offline, ping me.
Very interested in this initiative - the biggest gap currently in lora mesh communications is that there is no cross platform (IOS/Android) app yet to interface with the lora devices (outside of serial) which creates a major problem in terms of groups with mixed cellular devices.
On the topic of offline maps -
Also - any thoughts on ArcGIS?
https://developers.arcgis.com/net/latest/ios/guide/offline.htm
Aside from the offline maps issue, how close is the team to an IOS alpha?
In my opinion, it is better to leave the team to work and fine-tune the application for Android, since Android phones are cheaper. in the future maybe you could think of iOS and its closed source system.
Cheap android phones are… cheap. BLE intermittently working, screens difficult to read, poor hardware. Moreover, in the future Meshtastic may need to offload a certain number of functions (encryption, audio) to the smartphone and promoting inexpensive hardware will cut off a non negligible percentage of Meshtastic users from installing new releases.
