I can think of a use case for 70-80 tiles with an existing client... I know that's not 100+, but it's more than a handful! I don't think it would be a frequent issue.
One separate question - is there a way for ODK Collect to MOVE the file rather than COPY? Storage space could be an issue on some devices that I don't have direct 'control'. Probably not a showstopper, but could be helpful...
I have one project where the 10 tiles are almost 700Mb; the set of 70 tiles I have managed to keep down to 300Mb, but doubling those up will start to impact on older devices...
We have a new beta rolling out with the fixes that @seadowg mentioned! Hopefully those work for you @ahblake
Not related to maps, this beta adds periodic auto-send retries at an increasing time interval after an auto-send failure. To support this, we had to make a change to how WiFi vs. cellular is detected. If you use "WiFi only" or "cellular only" auto send options, I recommend testing this out. I've updated the first post in this thread to reflect this.
An additional change is that we've renamed "reference layer" to "offline layer" as discussed in the design thread.
The beta also adds the possibility to delete mbtiles files from Collect's storage:
Note that the icon for that delete button is currently a + when it should be a . We'll get that fixed shortly but it should not affect behavior.
Do these all get used from the same device? When does the user switch between them? Could the data be represented as geojson or entities with geometry if we had a way to display that kind of data as context when capturing a point/trace/shape? Same question for you @ahblake
Unfortunately not as far as we can tell. Some options you have:
Use Google Drive to distribute the files. The file picker should allow access to those and they will be downloaded directly to Collect. Some things you've mentioned before make me think you may not have Google accounts on your devices so that may not be a good option. Note that you could share a single account across devices (mycoolmbtiles@gmail.com)
Manually delete from downloads after the files are confirmed to be in Collect
Delete from Collect using the new functionality mentioned above after a certain layer is no longer useful
Typically in the 70-80 tile scenario, most enumerators need 1-10 of the tiles on their device, but a small number of them will potentially need all of them as their role requires them to cover all sites.
The underlying data for my offline layers can be relatively complex - a combination of base map (topographic or aerial image) and prepared vector overlay(s). Because we can't fully control styling of vector layers with ODK Collect (i.e. export a vector tile with embedded symbology) I am not yet convinced that I can drop MBTiles - my offline layers can have a combination of points lines and polygons, depending on the project. But the new styling is definitely a step towards that, when selecting from CSV / entities!
I have used shared google accounts exactly as you suggest for the small number of dedicated devices I can control - but can't do that where the devices are managed by a client. But Drive might be a good solution, by sharing folders.
I realise I'm often an edge case (trying to give you enough context to reassure you I'm not just being awkward), so I'm pulling you towards me and you just need to tell me when to stop being too weird
These new features are definitely beneficial and I can adapt admin work flows accordingly - getting people to manage their own device storage is not so hard - and the ability to delete MBTiles in the Collect folder directly is also really great - I'll try that shortly.
For a master device and avoiding adding/removing, it could have easily over 100, one project has over 200 alone. (But with easy add/remove ability, they could all be stored in a different folder and added from there as needed.)
For field users, they could be taught to manage them and add and remove them for different locations which would bring the immediate requirements down to 10-20.
Maybe/sometimes. If it's a tileset that is mostly created from a shapefile etc and there was an abiltity to style it i think that could work. Would it matter if the shapefile has 10s of 1000s of elements? Further, could the displayed data be dynamic based on other user inputs or form values? (Gets to my prior desire for dynamic setting of reference layer)
If it's a tileset with raster data, then like @seewhy , then that wouldn't work, my most recent set (the one that is mysteriously corrupting on device) is zoom level 0-18 with styled vectors over the top of satellite imagery as there is no cell data service in the area to fetch basemap imagery.
Ok, on Beta 3 now and it's fixed all those little gremlins.
Tiles are A-Z sorted in project settings & map widget selectors
Selecting tile doesn't jump to top in both selectors
Tiles for Project A only aren't visible in Project B in both selectors
⌄ button on RHS opens up 'Delete layer' button, delete works as expected, with confirmation.
(bonus, it shows the path and filename, which is very useful, especially as if you render a tileset out in QGIS the title is the filename, but if you rename the file post render, the title doesn't change.)
Limit of none plus 99x layers removed
(Coincidentally I had exactly 99 layers available to a project, so to test I copied an extra 9 layers using Files, but they didn't appear in the layer picker in settings until I fully exited settings and reopened. But then they were there and the 99x limit was also confirmed gone)
I have been able to load and delete offline layers using Beta 3. Hoorah!
The added function is helpful but it's not immediately obvious that you can also delete a layer, so suggested edit to the text on the 'Select offline layer' screen:
Select the offline layer to use for all maps in this project. You can add layers to the list by selecting an MBTile from your device and delete existing layers from the list.
On reflection, it could be an effective means of managing offline layers with this functionality - so files can be 'stored' in a public folder and then copied to ODK folder when required, and deleted from this folder when no longer needed (without needing to plug in the device of course!). That would have the advantage of keeping the list as short as required on this screen - if people choose to.
You've probably noticed that I've shied away from testing offline / local entities I'm not yet confident with managing entities and the workflows they introduce!
Apologies - I meant to confirm that this is new and useful. Works when shutting down the device without saving the [test] form! Not that I would ever do that, of course. Answering for a friend.
. We'll get that fixed shortly but it should not affect behavior.
