nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Enable MMPK as a Referenced Basemap in Field Maps

avillamo

I’d love to see support for using Mobile Map Packages (MMPKs) as referenced basemaps in Field Maps.

Currently, Field Maps only allows .tpk, .tpkx, or .vtpk formats for referenced basemaps. While these work well, enabling MMPKs would significantly improve flexibility and efficiency in field workflows.

Here’s the use case:

We maintain a few editable layers in ArcGIS Online for data collection.
Each user could then create and sideload their own MMPK, tailored to their region or task, including raster data, contours, or other contextual layers.
This would allow users to switch basemaps easily and work offline with rich, customized content — without needing to centralize or manage all basemap variations in AGOL.

This approach would:

Reduce data management overhead
Empower field users to build their own context-rich maps
Improve performance and offline usability
Simplify the user experience by avoiding basemap switching

Would love to hear if others are interested in this capability or if Esri has plans to support it!

Trouver plus de publications taguées avec

offline

Mobile device management (MDM)

Mobile Map Packages

Status: Ouvrir

Réponses

Jeremy_Z

I fully support this and have been bringing it up quite a bit recently with ESRI.

The usual thing I see folks mention is "Just do a VTPK" of the same data, but why should we duplicate all of this? I am running the BLM's National Mobile Map Package System ( National Mobile Map Package (MMPK) Program | Bureau of Land Management ), these maps are big, and going to get much bigger soon. Having to do these as VTPK's doubles the amount of time it takes to update and doubles the file size we have to store as well.

AlfredBaldenweck

Another thing that my colleagues and I are running into is that MMPKs are great solutions for cases when you want to actually identify the data in the map, as well as manage the layer visibility, etc.

We are seriously behind in serving out the various files that my users use on a daily basis for their work, and having them be able to just make an mmpk with copies of the data they need would solve a lot of headaches from the management side of things. It'd let them get up and running while also saving us a lot of maintenance.

Tile packages are cool, but what my users need is a modern, interactive map. Obviously, I'm not asking to collect into the files in the mmpk, but being able to collect into feature services on top of the mmpk would be spectacular.

Editing to add: the overhead of first publishing a bunch of layers and then trying to get them into offline areas is too high. As it is, offline areas are extremely prone to failure if neither tiny nor super low resolution. I'd like to diminish that by only putting the layers that are to be collected into the offline areas as much as possible.

Rejoindre la conversation

Connectez-vous pour publier, suivre du contenu, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.