Hi @LN!
Please forgive me for over-explaining stuff I'm quite sure you already know; I'm not just answering you but hopefully laying out some of the details for other readers of the thread!
File format
Yes, I'm thinking of MBTiles files with protofuffer blobs in the tiles table. So yes, Mapbox Vector Tiles format in a SQLite container—these have a .mbtiles extension, and the blobs have a .pbf type. As per the spec here.
The online tile-server equivalent of vector tiles have a .../z/x/y.mvt name schema. That spec is here.
Layers
I agree that it would be good to change the way users specify layers (and that "Mapping SDK" probably doesn't mean much to the average field data collector and should be removed). However, I'd like to specify in a bit more detail what I'm thinking in terms of the choices and how I'd see them stacking into three discrete layers:
- Bottom: Opaque base layer (offline opaque MBTiles or an online tileserver)
- Middle: non-editable semi-transparent layer (offline Vector MBTiles or online MVT from a tileserver, perhaps even static GeoJSON)
- Top: editable layer (GeoJSON or other, to be implemented later)
Base Layer
Sometimes an actual picture (raster) is the only thing you can get that allows you to see what's on the ground. When dealing with an unmapped area, a new refugee camp, or a newly-damaged area from a natural disaster, there's little chance that you'll have vectors representing the current features on the ground, but you might be able to get an aerial image, even quite soon after a natural disaster. So that capability should always be there (as it is now with OSMDroid, albeit with a few rough edges in the implementation).
It should be possible to make this an online or offline layer without much practical difference. The current online Google or OSM layers being used by OSMDroid are rasters (well, the OSM ones certainly are, and I think the Google ones are as well). Once the functionality for a given online raster layer is built, it's relatively straightforward to enable any online raster layer (here is an example of a general way to access image tiles from any online raster tile server—albeit in Python, but the math and URL manipulations are all the same).
Semi-Transparent Layer
This may be standalone, as opposed to overlaid on top of a vector layer. Standalone (and opaque) is the usual style of the vector tiles in the MapBox SDK; the vector tiles are simply a way to generate a map view locally from much less data-intensive vector geometry instead of downloading a bunch of images (which is what the current OSM layer in ODK does). However, a huge advantage of vector tiles is they can overlay an raster with transparency between features. So you can have a layer with, for example, a bunch of road traces, but also see the satellite/aerial imagery of the raster layer beneath. Really useful for incomplete maps; you can see what's been already mapped, but you can also see the raw imagery beneath what hasn't been done yet.
Vector tiles can be offline using the MBTiles format with tile type "pbf"
instead of JPEG or PNG. They can also be online, using (among other potential sources) the MapBox vector tile server that they're (very generously!) offering ODK (that's where the .../z/x/y.mvt schema comes in; instead of grabbing the tiles out of a SQLite container, the application grabs them from an HTTP tile address).
Editable Layer
This should, I propose, be on top and always render overlaying the raster or tiled-vector layers. That's simply because they're the thing the mapper is probably working on! Between features should, of course, be transparent.
Choices
Note that I'm only proposing one layer of each type for now. As much as it might be tempting to allow multiple vector tile layers so people can choose what they want to see on the map—and maybe that's a discussion for the future—if we initially only allow a single vector tile layer, this still allows the survey creator to give the mapper anything they choose. The vector tile layer can contain, or not, roads, buildings, fire hydrants, etc. So for the moment I don't see the need to allow stacking multiple discrete vector tile layers. One is enough.
I do think it's worth letting people decide for either of the two bottom layers whether they want offline or online. There's no reason not to allow someone to use a high-resolution offline drone image layer as their raster background for a specific area, while still having the online MapBox/OSM layer on top of it. Or, I suppose, vice versa; an online raster layer with an offline vector tile overlay (though I can't really think of a situation where that would be tremendously useful given the greater file size of rasters).