[R-sig-Geo] mapView: basic interactive viewing of spatial data in R

Tim Appelhans tim.appelhans at gmail.com
Fri Jul 24 15:14:42 CEST 2015

see my answers below.

On 24.07.2015 14:26, Edzer Pebesma wrote:
> Hi Tim, thanks for starting the discussion.
> I started a similar discussion (off-list, with package maintainers) for
> the case where google map or openstreetmap maps are used as background
> in map plots created in R, support for which is now scattered over
> ggmap::get_map, RgoogleMaps::GetMap, dismo::gmap and
> https://github.com/hadley/rastermap. (on r-forge, sp::plot and
> sp::spplot can now deal with these, see sp::demo(webmap)).

The idea behind mapView was not to be able to underly google imagery or 
other map layers as such. The motivation was to avoid the detour via the 
hard drive in order to get interactive viewing capabilities (either via 
saving and opening manually or automatically as in plotKml).
I have not tested rastermap or sp::webmap so far, so I don't know their 
exact capabilities.

> The (un)projection mapView does is towards epsg:4326 (longlat WGS84),
> leaflet assumes this and takes care of the projection to web mercator;
> the message printed in mapView (if verbose = TRUE) and your tutorial do
> the correct thing but suggest they convert to mercator.

It is true that mapView (un)projects to epsg:4326 for Spatial* objects. 
The rest is handled by the leaflet package.
For Raster* objects this is not so straight forward as the current 
leaflet implementation expects two things. From the entry for projection 
argument in the help of addRasterImage:

"if TRUE, automatically project x to the map projection expected by 
Leaflet (EPSG:3857); if FALSE, it's the caller's responsibility to 
ensure that x is already projected, and that extent(x) is expressed in 
WGS84 latitude/longitude coordinates"

which means that the layer needs to be in wgs84 web mercator, whereas 
the extent needs to be in epsg:4326 (longlat WGS84). Therefore this is 
all handled by leaflet at the moment. Giving the user a bit more control 
over this would be desirable in the future.

I included the "projecting to web mercator" message to make people aware 
of the fact that reprojection is done under hood by leaflet. In my 
opinion, this is one of the things that many people do not realise (e.g. 
many of our students) when loading data into classic GIS systems like 
ArcGIS or QGIS who also do on-the-fly reprojection but without telling 
the user. In the case of mapView where we usually simply want to inspect 
the data this is rather unimportant (that's why verbose is set to FALSE 
by default) but once you want to do calculations this becomes an issue. 
Given that calculations in R will be done using the designated packages 
(e.g. sp or raster) this is taken care of anyway.

> Some remaining questions:
> - package leaflet also supports plotting Spatial* and Raster* objects,
> what is exactly added by mapView?

leaflet is great for individual maps. MapView simply provides some 
resonable default behaviour for the most commonly used objects from the 
R spatial universe, e.g. automatic parsing of layer names, pop-up text, 
backgraound maps. Also it enables automatic addition to existing maps 
without the need to manually look up existing layer (group) names.

> - have you thought about integrating this functionality into the leaflet
> R package?

I have contacted Joe Cheng a couple of weeks ago about this, but have 
not heard back from him so far.

> - could we strive towards argument compatibility, so that we can get
> things done by simply changing "plot" or "spplot" into "leaflet"?

Compatibility would be very desirable! Up to now, my efforts into 
mapView were more of a proof-of-concept than a structured 
implementation. This is exactly why I wanted to make the spatial 
community aware of it, so we can together decide where to take this 
approach (ideally including the leaflet maintainers from RStudio). Ther 
are some additional things to consider here, for example the use of 
magrittr pipes implemented in leaflet...

At the end of the day, I think we all agree that interactive GIS-like 
functionality in native R would be a great thing to have. I do recall a 
suggestion by Barry Rowlingson (if I remember correctly) who stated that 
one day a call to library("gis") would be nice. Maybe mapView is merely 
another puzzle piece along these lines.


> On 07/24/2015 11:39 AM, Tim Appelhans wrote:
>> Dear list members,
>> I would like to draw your attention to a little 'project' I've been
>> working on over the past few weeks.
>> Using leaflet for R, I have defined some methods for spatial data (e.g.
>> Raster*, Spatial* objects) to quickly visualise them in either the
>> RStudio Viewer pan or the default web browser. The function I created
>> for this is called mapView().
>> Think of it as an interactive version of spplot()/plot() for spatial
>> data (though less versatile). It enables zooming, paning and basic layer
>> queries (i.e. printing of the attributes in the @data slot of Spatial*
>> objects + the x/y location of the feature). For Raster* objects queries
>> are currently not available as leaflet translates the data into RGB
>> values for display. Furthermore, background maps can be defined and
>> multiple different spatial object layers can be overlaid.
>> At the moment mapView() lives in our Rsenal package on github
>> (https://github.com/environmentalinformatics-marburg/Rsenal) but this is
>> likely going to change at some point in the not too distant future. This
>> also depends on whether there is active interest in developping this
>> sort of thing further to provide more than the current admittedly rather
>> limited functionality. This, however, would involve JavaScript coding
>> which I do not have any experience with.
>> A quick (non-interactive) intorduction can be found here:
>> https://metvurst.wordpress.com/
>> The full introductory article including interactive examples is
>> published here:
>> http://environmentalinformatics-marburg.github.io/web-presentations/20150723_mapView.html
>> I hope this may prove useful for some of you.
>> Also, if anyone is keen to get involved in taking this further, please
>> let me know and we will see how to best proceed.
>> Best,
>> Tim
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Tim Appelhans
Department of Geography
Environmental Informatics
Philipps Universität Marburg
Deutschhausstraße 12
35032 Marburg (Paketpost: 35037 Marburg)

Tel +49 (0) 6421 28-25957


	[[alternative HTML version deleted]]

More information about the R-sig-Geo mailing list