A new Settings screen for Maps

Hi, for all those who use the geospatial functions in ODK, we are considering a reorganization of the map-related preferences in the General Settings. Here's what we have in mind.


Currently, there are two preference settings for maps, Mapping SDK and Basemap, and they are in a Mapping section at the bottom of the User interface screen in General Settings.

So to switch from Google to OSM, for example, you tap General Settings > User interface, then scroll down to Mapping, and tap Mapping SDK. This preference lets you choose which mapping software to use

The second preference, Basemap, lets you choose the base map to show. If the Mapping SDK is "Google Maps SDK", this gives a list of the map types provided by Google (Streets, Terrain, Satellite, etc.). If it's "OpenStreetMap SDK", it gives a list including base maps provided by OSM, USGS, Stamen, and CartoDB.

If your phone has offline base map files installed, these files will also appear in the Basemap list, regardless of whether "Google Maps SDK" or "OpenStreetMap SDK" is selected for the SDK.

This design has a few shortcomings we'd like to address:

  • Most users don't know or care what an SDK is.
  • If you are looking for, say, USGS maps, it isn't obvious that you have to first choose "OpenStreetMap SDK" before you can see the USGS options.
  • These settings are a little awkward to get to at the bottom of the User interface screen.


We're considering moving these preferences to their own Maps screen, so the General Settings screen will now have 5 items (Server; User interface; Maps; Form management; User and device identity).

On the Maps screen, the first preference will offer 6 choices:

Base layer:  [ Mapbox        ]
             [ Google Maps   ]
             [ OpenStreetMap ]
             [ USGS          ]
             [ CartoDB       ]
             [ Local file    ]

(We have been discussing whether to present this option as "Base layer source" or simply "Base layer".)

Based on which one you pick, further options will appear below.

If you choose Mapbox, you'll have a choice of various Mapbox map styles (Light, Dark, and so on). If you choose Google Maps, you'll have a choice among the Google map styles (Terrain, Satellite, and so on); and similarly for USGS and CartoDB. If you choose OpenStreetMap, there won't be any further options (you'll get the standard OSM raster basemap).

If you choose Local file, you'll get a selection of the .mbtiles files available on the phone.

The future

This paves the way for additional options on the Maps screen, following the three-layer model discussed in this other topic: Geo: Using the Mapbox SDK for Android.

  • If we decide to support arbitrary tile URLs, we'll add another choice to the Base layer list (probably called "WMS" or "URL template").
  • If we decide to support offline vector or raster overlays, we'll add a new Reference layer preference to this screen that lets you choose a layer to overlay on top of the base layer.
  • If we decide to support selectable geometry, there will be a new Content layer preference on this screen that lets you choose a GeoJSON file.
  • Once we've added a way to add other layers, we might add a "None" option to the Base layer list so you have the option to turn it off.

Your thoughts?

Let us know what you think of these changes; we're open to your feedback and ideas!

A few people who I'm guessing will be interested in this: @smit1678 @Ivangayton @mathieubossaert @paul.uithol @langstonsmith @Marena

1 Like

This seems very sensible.

Any thoughts on why we might or might not support arbitrary tile URLs? Is there a policy decision to be made, or is it simply a question of the effort of implementation?

Just implementation effort, as far as I know. It's not hard, it's just a lower priority than the other stuff right now.

1 Like

Thanks, @zestyping, this makes a lot of sense! My initial thought was that users might want to pick basemaps based on some characteristic other than their source but I can't think of a simple taxonomy. What you're suggesting strikes a good balance between having a first-level list that's not too long and helping users find what they're looking for. The documentation can provide links to see previews of the default online layers available so that project managers can pick them ahead of time.

Even if we leave the user-facing title as "Base layer", I think it'd be helpful to have a clear definition of what the elements in that list are. Is it where the source data comes from? Or where the layers themselves are provided from? Something else? For example, I notice you don't have a top level item for Stamen even though a Stamen Terrain map is currently made available in the settings. Was that just an accidental omission or would you put it under OpenStreetMap because that's where the data comes from? In that case, should the CartoDB layers also be under OpenStreetMap?

My preference would be for the base layer list to display a list of sources and for Stamen and CartoDB to be separate from OpenStreetMap.

Regarding options under OpenStreetMap, would there be value to exposing the humanitarian map style (e.g. http://a.tile.openstreetmap.fr/hot/7/63/42.png) and if so, where would that one go? @Ivangayton @paul.uithol

The documentation can provide links to see previews of the default online layers available so that project managers can pick them ahead of time.

Yeah, that's a good idea!

Omitting Stamen from the list was accidental on my part.

I think we should organize the menu in whatever way is easiest for users to find the things they want and to describe them in written or verbal communication with other users. Let's list Stamen and CartoDB separately from OpenStreetMap as you suggest—I think that will work best.

If we wanted to add the /hot/ tiles, we could add a selector under OpenStreetMap with two items, e.g. "Default" and "Humanitarian" or "Humanitarian OSM Team". Should we?


That sounds like a good option. It doesn't change the top level menu so doesn't need to be decided immediately. I think it's a style that would be useful to our users but I haven't personally had a need for it. It might become more compelling as some of the custom layer features get added.