Geo: Using the Mapbox SDK for Android

Ideas
27

Thanks for laying out all these details, @Ivangayton! Never hurts to have clearer information out in the open so that everybody is on the same page.

There's seems to be a pretty clear consensus that, as @LN suggested, the user-facing settings should not be focused on a developer-facing concept like the choice of SDK.

I also think having three layers makes sense. @LN's proposal is a shift from internal implementation details toward user concepts, and I see @Ivangayton's proposal as a further step in that direction.

Let's present the layers in terms of the purpose they're used for; that makes sense. I'll try to propose some user-facing terminology, then:

  1. Base layer: A fully opaque layer. Could be a map with authoritative or general-purpose information; could be satellite or aerial imagery. Because the layer is fully opaque, it only makes sense to have one of these. (I'm suggesting "base layer" rather than "base map" so there's no confusion about what a "map" is: there are 3 layers and they go together to make a map.)

  2. Reference layer: An optional layer of additional information that is more specific to the task at hand, mostly transparent, drawn on top of the base layer. The purpose of the layer is to help you find your way around or to provide related information, but it is not the thing you are manipulating or collecting data about; hence the name "reference".

  3. Content layer: An optional layer of geometry drawn on top of the reference layer. The name "content" is intended to imply that this is the geometry you are working with—either you're collecting data about it, or you're editing the geometry.

You wouldn't be restricted to online, or offline, or vector, or raster, in any particular position among these layers—with the one exception that the content layer must be a vector layer.

So the ultimate list of supported formats would look like this:

  1. Base layer:

    • OSM online raster tiles
    • Mapbox online vector base map
    • Google Maps online vector base map
    • Any offline mbtiles file (raster or vector)
    • Any online mbtiles file (specify a URL)
    • Any online raster tile service (specify a URL template)
    • Any online vector tile service (specify a URL template)

  2. Reference layer:

    • Any offline mbtiles file (raster or vector)
    • Any online mbtiles file (specify a URL)
    • Any online raster tile service (specify a URL template)
    • Any online vector tile service (specify a URL template)
    • GeoJSON

  3. Content layer:

    • GeoJSON

From a user perspective, my question is: Would this make sense to users? My hypothesis is that presenting it this way, and minimizing the restrictions on which formats are allowed in each slot, means less extra stuff that users will need to understand.

From an implementation perspective:

  • The "specify a URL" options are not ones we've really been talking about so far. I would prefer to do them as part of a second round; they are only listed for completeness.
  • Although this does allow a wider range of possibilities than the proposals mentioned previously, I don't think it's actually harder to do with the Mapbox SDK. We'd be supporting the same set of formats and facing the same issues; all that's new is the possibility of two sets of raster tiles or two sets of vector tiles, which is not any harder than one set of each.
  • If Google is selected for the base layer, then the other layers are disabled. Or maybe we allow semitransparent raster tiles, but that's all.

Thoughts on this?

1 Like