mapview 1.0.0 now on CRAN

we are happy to announce that mapview 1.0.0 has been released on CRAN.
Together with Florian Detsch (R, Rcpp), Christoph Reudenbach (js) and
Stefan Woellauer (js) we have put together a powerful tool for
on-the-fly mapping of spatial data during the workflow.

In addition to the existing functionality described in my earlier mail,
we have:

1) made the whole code a lot faster, so rendering should be much quicker

2) added “big data” support for vector data.
It is now possible to view even very large vector objects without any
This is possible due to the inclusion of special .js functionality. This
means that when working with large Spatial* objects mapview does not use
leaflet for R, but its own functions. This also means that leaflet
integration is not possible for big data. In a nutshell, big data
support is achieved by separating drawing of the geometries and parsing
of the underlying data. This means that in order to query the attributes
of your objects you will need to zoom in a bit. For polygons and lines
the features will turn magenta once they are queryable, for points the
query-radius around the points is restricted quite a bit.
As an example, on my machine (ubuntu 14.04 64-bit, 7.5 GB RAM, Intel®
Core™ i5-4300U CPU @ 1.90GHz × 4, 500GB SSD) 2.1 Mio. points take about
30 sec. to render and the interactive behavior of zooming and panning
is smooth and feels just like dealing with only a handful of points.

For those who are interested in trying yourself, here’s a bit of code to
create an artificial SpatialPointsDataFrame with a bit more than 2.1
Mio. points (to change the size simply change the number of repeats in
the first line.




### blow diamonds up a bit
big <-[rep(seq_len(nrow(diamonds)), 40), ])
big$cut <- as.character(big$cut)
big$color <- as.character(big$color)
big$clarity <- as.character(big$clarity)

### provide some random positions
big$x <- rnorm(nrow(big), 0, 10)
big$y <- rnorm(nrow(big), 0, 10)
coordinates(big) <- ~x+y
proj4string(big) <- CRS("+init=epsg:4326")

### view it

3) added a spplot() method to produce a static version of the
interactive map. Note, this feature is in its infancy so only has very
limited flexibility at the moment.

4) added mapviewOptions(), similar to rasterOptions() to set and
retrieve options session-wide. This means you can now easily set your
favorite background maps or color schemes (among other things) permanently.

5) added a couple of convenience functions:

  • slideview() – to compare two images in a before-after fashion
    (similar to wxGUI Map Swipe in GRASS). See below for a static example.
  • plainview() – an image viewer to view Raster* objects without the
    map background. This means that you can view rather large rasters with arbitrary CRS without too much hassle as no re-projection is necessary.

6) added an alias function mapview() with a small “v” as typing was
quite confusing before. Now it’s mapview with a small v all the way from
loading the package to viewing the data.

Unfortunately we have also BROKEN BACKWARD-COMPATIBILITY.
Due to the inclusion of lattice (levelplot) logic when dealing with
col.regions, we decided to make argument naming more similar to existing
spatial graphics standards. Therefore, some argument names have changed:

  • layer.opacity is now alpha.regions
  • weight is now cex for points and lwd for lines

We hope this does not cause too many inconveniences.

These are the major enhancement/changes of mapview in this release.

We have also updated the demo at

As always, don’t hesitate to contact us for questions, feedback and/or

Formal bug reports and feature requests should be filed at

Tim, Flo, Chris and Stefan

This entry was posted in R. Bookmark the permalink.

20 Responses to mapview 1.0.0 now on CRAN

  1. Jim Collins says:

    Just checked CRAN and it is altogether unclear what is available for mapview? Clearly mapview for Mac isn’t available, but it is unclear what is available even for Windows. I tried installing from github on my Mac and that is a non-starter.

    • Tim Salabim says:

      mapview has been accepted to CRAN about 20 hrs ago and it usually takes some time for the mac and windows binaries to be built (though we already received the windows binary build confirmation).
      As for your github installation problem, I cannot help you unless you provide a little more detail (minimum your sessionInfo() and how you tried to install it).

  2. Pingback: Distilled News | Data Analytics & R

  3. Jim Collins says:

    Thanks for your prompt reply – I will check CRAN later this week. Good to know that it will be available for Mac.

  4. Pingback: mapview 1.0.0 now on CRAN-IT大道

  5. Hendrik Wagenseil says:

    Great work, mate! Just played around a little and it simplifies map creation a lot! Have you testet large polygon datasets? E.g. US census tracts (74k units) or similar sizes? Usually leaflet crashes when trying to bring that in.

    • Tim Salabim says:

      We have tried with landuse polygons for Switzerland (from which has about 90k features and it works just fine. As I mentioned in the post, you need to zoom in a bit before you can actually query the attributes (features will turn magenta), but there is always a trade-off I suppose. We have had success loading a data set with about 300k – 400k features, but there are two things to consider. First, for polygons and lines it is hard to say how many features will work as the number of vertices making up the features is actually the determining number. Second, it also depends on the system you’re working on, hardware does make a difference and so does the state of your system, i.e. a freshly booted system will perform better.

      The other Wöschdla 🙂

      • Hendrik Wagenseil says:

        Ok, sounds great. Will give it a try. Let´s aim for a beer – not just on a map 😉

  6. Jay Leverett says:

    This looks fantastic! Awesome work!

    Any pointers on how to integrate one of these into a Shiny app? I’ve built an app that needs to display a few hundred thousand polygons and don’t think Leaflet would be up to the job. Would really make my day if I could figure out how to use mapview instead!

    • Tim Salabim says:

      I am sure that leaflet won’t help with this kind of data volume.
      In theory it should work as the standard shiny support from htmlwidgets is part of the big data solution in mapview. However, we have not tested this so far. Have you tried it? Any feedback on this would be highly appreciated.
      We will start running our own tests at some stage, but shiny integration was not our primary concern so far.

      • Jay Leverett says:

        Hey Tim – thanks for the reply!

        I did try it in Shiny but wasn’t sure which render function to use on the server side. As a shot in the dark, I tried using renderLeaflet(), but that didn’t do the trick.

        I also tried creating my own renderMapview() and mapviewOutput() functions in a global.R file, but didn’t have any luck there either. Seems like something’s missing, but I just don’t know enough about htmlwidgets to figure out what it is.

        So if you know of a simple hack that might get it working, I’d obviously love to know. Otherwise I can wait patiently for Shiny support in a future version:)

        Thanks again for a great package!


      • Tim Salabim says:

        and I don’t know enough about shiny it seems… though the functions you mention might point us in the right direction. Have a look at

        I think the two functions you are looking for are in the section for bView() between lines 433 and 444. That is for SpatialLines* and SpatialPolygons*.
        For SpatialPoints* they are further up in the code in the code section related to fpView().

        Just to give you a quick run-down of what happens behind the scenes. In mapviewOptions() the default of maxlines/maxpolygons is set to 30k, which means that for any object composed of more features than this threshold function bView() is called internally (objects with less features are rendered using R leaflet). So, if you have more than 30k features, I think the two bView() related shiny functions should be the ones to call.

        Let me know if this does the trick.


      • Jay Leverett says:

        Tim – that worked perfectly! Can’t thank you enough for your help!


      • Tim Salabim says:

        Always happy to help. And it’s good for us to know that it works too.
        If you don’t mind, I would love to see the result (should it be hosted publicly). We are very curious about how people use our software.


      • Tim Salabim says:

        I have had a quick try with shiny integration and for points this works using mapview:::renderfpView, mapview:::fpView and mapview:::fpViewOutput in the appropriate places. For lines and polygons the functions to use are mapview:::renderbView, mapview:::bView and mapview:::bViewOutput, respectively. You need to specifically call them from the mapview namespace with mapview::: as they are not exported, i.e. hidden functions.
        Let me know if you have success with this.


  7. Jay Leverett says:

    Unfortunately it’s for internal use right now, but if we open it up at any point I’ll certainly share. Thanks again!

  8. Chris Hibbert says:

    Hi Tim, thanks for the really neat package. Am I correct in thinking that when many points / polygons are mapped, such as in your example with the 2.1 million points, there is no way of changing the appearance of the points or polygons such as with zcol / cex?

    Thanks for your help,

    • Tim Salabim says:

      Hi Chris,
      at the moment the only appearance change possible for large objects is the general coloring. I am assuming that you want color/size mapping of some attribute? Color mapping will be implemented at some stage in the (hopefully) not too distant future. Regarding size mapping, I am not sure if that is even possible in the current javascript function layout. I will double-check with the co-author who wrote that particular part.


      • Chris Hibbert says:

        That’s correct regarding the colour/size based on an attribute, rather than general colouring. Colouring based on attribute would be great, so I look forward to this potentially being implemented. Thanks for clarifying the current situation.

        Cheers once again for making this package,

  9. Chris says:

    Hi Chris,
    sorry for the delay but finally some news about colouring, sizing and the chance to have an potion to individualize the appearance of points (lines and polygons). Actually this issue is the most important one beside just be able to map this huge number of items correct positions and with correct attributes. The big data approach we choose relies heavily on webGL and it would be easy to use a bitmap representation of the common r-ish dots, but first less flexibile and second slower. So we decide to create basic shaders that meets this needs. This takes a while but it is on the way.

    To make it short I think we will provide soon a develop version that supports also for fast big data standard r-styles, colors and sizing. However according to the pure amount of data we have to keep it straightforward and lean.

    best Chris (me)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s