mapview: interactive maps of spatial data in R

Quick and investigative, not presentation grade

mapview provides functions to very quickly and conveniently create interactive visualisations of spatial data. The README is unusually precise about what kind of tool this is: its main goal is to fill the gap of quick, not presentation grade, interactive plotting to examine and visually investigate both aspects of spatial data, the geometries and their attributes.

That sentence is the product statement, and it is worth taking at face value. The gap being filled is the one between static plotting, which shows you the data but not the attributes in context, and a full map application, which takes an afternoon to assemble. mapview is the answer for the moment when you have loaded a dataset and need to see whether the shapes make sense.

Mechanically, it can be considered a data-driven API for the leaflet package, and that is the design in one line. Where leaflet asks you to say what you are plotting, mapview looks at the object and works it out, so it will automatically render correct map types depending on the type of the data: points, lines, polygons or raster. You get markers for points, polylines for lines, a layer with a popup for polygons, and an image overlay for a raster.

Beyond that, it makes use of advanced rendering functionality that enables viewing of much larger data than is possible with leaflet. That is the point where mapview stops being a convenience wrapper and becomes its own thing: the leaflet map is the interface, but the drawing of the features is not leaflet's.

There is a second rendering platform too. If you are a fan of mapdeck, which the README encourages, you can choose to use it as the rendering platform instead of leaflet by setting mapviewOptions(platform = "mapdeck").

The four functions you will actually call

The main user relevant functions are listed in the README, and there are four.

mapview views one or more spatial objects on a set of background maps. That is the entry point, and the basic call is a single line:

mapview(breweries)

which produces a web map visualisation of the breweries data with the components shown in the README's screenshot, the base map, the markers and the popups.

viewExtent views the extent or bounding box of spatial objects, which is the zoom-to-the-data call rather than the plot-the-data call, and it is the one to reach for when the coordinates are wrong or the projection is not what you expected.

viewRGB views RGB true or false colour images of raster objects, so you can look at a satellite scene or a multi band image directly in the browser rather than writing it to a file and opening it elsewhere.

And mapshot easily saves maps, including leaflet maps, as html and or png, or other image formats. That is the export path, and it is the one that turns the interactive view into something you can put in a document.

The fact that there are four functions is itself informative, given the deprecation list discussed later. An earlier version of the package had a much larger surface, and what remains is the part that is about looking at data rather than about building a map.

So the typical session is: view it, look at the extent, view an image if there is one, and mapshot the result if it needs to leave the screen.

The deprecation list is the design of the package today

The README carries a section of functions that have been deprecated or deleted recently, and it is the most informative part of the document for anybody deciding what to install.

Six functions have been deprecated in favour of the package leafem: addHomeButton, addLogo, addFeatures, addMouseCoordinates, addExtent and addImageQuery. Three families have moved to their own packages: latticeView and sync to leafsync, slideView to slideview, cubeView to cubeview, and plainview to plainview. The popup functions popupTable, popupGraph and popupImage are deprecated in favour of leafpop. And addLargeFeatures is no longer the way to do it, with leafgl's addGL* functions as the replacement.

Read as a whole, that list describes a deliberate slimming. The package used to carry the map chrome, the popups, the slide and cube viewers, the synchronised views and the WebGL feature rendering, and each of those has become a separate CRAN package with its own name and its own release cycle. What is left in mapview is the core: turn an object into a map, and look at it.

There is a real consequence for anyone upgrading. Code that called addHomeButton or popupTable now needs a different package and, in some cases, a different call, and the migration is not always a one to one rename because the behaviour moved with the function.

The pattern also explains the package's dependency footprint. A package that depends on leafem, leafsync, slideview, cubeview, plainview, leafpop and leafgl to offer the old surface is a heavier install, and the maintainers have evidently decided that the better trade is a small core with satellites.

The spatial classes it will accept

Objects of the following spatial classes are supported, and the list is the contract you code against.

The first is sf, the modern R spatial package, and it is the one the package was clearly designed around. Then raster, with its Layer, Stack and Brick classes and the SpatialPixels and SpatialGridDataFrame variants, which is the older raster package. Then stars, the newer array-oriented package for spatiotemporal data. Then sp, the package that preceded sf, with its Points, Polygons and Lines classes and their DataFrame versions. And satellite, which is the package holding imagery objects.

So this is not a package that only works with one ecosystem. It accepts both the old and the new R spatial stacks, and objects from raster and stars can be rendered through the same call as sf objects.

The interesting case is raster, because rendering a raster is a different problem from rendering vectors. A raster has to be turned into an image overlay, with the pixel values mapped to colours, and a stack or a brick is several bands, so viewRGB exists as a separate entry point for the true and false colour cases. The automatic map type selection mentioned earlier covers the vector cases, where the choice is between markers, lines and polygons.

For anyone moving from sp to sf, the practical note is that both are accepted, so a script can be migrated piecewise rather than all at once.

Installation, and the branch note that catches people out

The installation section is short and has one detail that trips people up.

For the CRAN release version of mapview, you install it with:

install.packages("mapview")

To install the development version you install the remotes package and then:

remotes::install_github("r-spatial/mapview")

And then the note: as of version 2.9.1 development will happen on the master branch, and you should consider the develop branch obsolete.

That is a small sentence with a large practical effect. The GitHub repository has a master branch and a develop branch, and the convention in most R packages is the opposite, with master being the stable line and develop the active one. Here the development branch is the default branch in the repository metadata, and the develop branch is the one that is being retired. So a contributor who installs from GitHub and picks the wrong branch gets a tree that is not being worked on.

The usage section is shorter than the feature list suggests. The most basic call is mapview of a data set, which produces a web map visualisation with the components shown in the README figure, and the bug reports and feature requests go to the repository's issue tracker.

The project is under the r-spatial organisation, which is where the leading R spatial packages live, and the documentation site is at r-spatial.github.io/mapview.

Badges, releases and what the version numbers say

The badge block at the top of the README tells you how the package is tracked, and it is the usual set for an R package that is on CRAN.

There is an R-CMD-check workflow badge from the GitHub Actions workflow of that name, which is the standard check that runs on every CRAN submission. There is a CRAN checks badge showing the worst status on CRAN's own check results page, which is the one to look at if a package has broken against a new R version. Then the monthly and total download badges from cranlogs, and the CRAN version badge. The licence badge says GPL, greater than or equal to version 3.

Against that, the release list is short. The only visible release is v2.4.0 from 2018-04-28, while the installation section refers to version 2.9.1 as the point at which development moved to the master branch, and the last push to the repository was on 2026-10-14. So the repository is being worked on every week or so, the CRAN version is much newer than 2.4.0, and the GitHub releases are not the record of the project.

The repository layout is a standard R package with a few extras. There is DESCRIPTION and NAMESPACE for the package metadata, R/ for the code, man/ for the generated documentation, inst/ for shipped assets, tests/ for the test suite, vignettes/ for the long articles, data/ for the bundled datasets, NEWS and NEWS.md for the changelog in both formats, _pkgdown.yml for the documentation site, README.Rmd as the source of the README, and mapview.Rproj for RStudio.

The primary language of the repository is reported as JavaScript, which is a clue about the architecture: the parts that draw the features are not R, and the JavaScript assets are what make the larger data sets viewable.

Where mapview is the wrong tool

There is a clear case where this package is the wrong answer, and the README states it in its own opening paragraph.

mapview is for quick, not presentation grade, work. If the map is going to be published, embedded in a report, or shown to somebody who will judge its design, the automatic choices mapview makes for you are the wrong ones. It picks the map type from your data, which is convenient, and it picks the basemap and the popup content, which is not what a published figure needs.

The alternative approach is to use leaflet directly, where you control every layer, the basemap, the popup content and the styling, at the cost of writing the map assembly yourself for every project. The difference in approach is exactly the trade mapview makes: automatic map type detection and a one call entry point against full control and more code. For exploratory work the first wins, and for anything you are going to show to other people the second does.

There is also the alternative of not using a web map at all, and plotting the data statically, which is what most analysis ends with. A static plot of the same geometries answers many questions faster than a web map, and it is the output a paper wants.

Two more limits are worth knowing. The advanced rendering that lets mapview handle larger data is now in leafgl, so a project that needs WebGL rendering has to install and configure that package as well, with the addGL functions rather than the old addLargeFeatures. And the mapshot export is a convenience for saving a view, not a rendering pipeline: if you need a map at a particular size with particular styling for a document, you will be doing that work outside this package.

So the sensible way to use it is as the exploration step and the mapshot step, and to move on when the answer needs to be a deliverable.

Editorial conclusion

mapview suits an analyst who has just loaded some spatial data and wants to look at it, not to publish it, and who wants the geometries and the attribute table in the same window without assembling a Leaflet map by hand. It does not suit somebody building a production map, because the README describes the goal as quick rather than presentation grade, and it does not suit a workflow that needs the popup and layer features the old functions provided, since those now live in separate packages. Check three things before you adopt it: which of your objects are in the supported class list, since sf, stars, raster, sp and satellite are the ones handled, whether the version on CRAN matches the behaviour you need, because the README notes that development moved to the master branch with version 2.9.1 and that the develop branch should be considered obsolete, and which companion packages you will need, since the features that moved out have their own names. The last push to the repository was on 2026-10-14.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. r-spatial/mapview on GitHub