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

Fri Jul 24 17:23:37 CEST 2015

Please also see my comments on a parallel issue in the leaflet github:

https://github.com/rstudio/leaflet/issues/139#issuecomment-124035792

Briefly, no automatic system can help if the input geometries (raster or vector) have an incomplete CRS, which is very often the case. Users need not only a warning, but first to be told that their input CRS is probably incomplete, where to look for help, and then more help if the input CRS was complete but was wrong (or the Eastings and Northings were reversed in the input data. There is no easy way to do this, and indeed fundamental parts of our infrastructure for handling CRS, like the PROJ.4 library (bug corrections), datum grid versions, and the copy of the EPSG CRS definitions used do all change over time. Arguably, automatic projection or reprojection should be treated with sufficient caution unless all data acquisition is strictly managed (as it would/should be in a large professional organization employing its own surveyors or contracting photogrametric and surveying services). If position matters, it is worth taking the time to find an appropriate CRS, or we all end up at sea without an anchor.

Roger

--
Roger Bivand
Norwegian School of Economics
Helleveien 30, 5045 Bergen, Norway
Roger.Bivand at nhh.no

________________________________________
Fra: R-sig-Geo [r-sig-geo-bounces at r-project.org] på vegne av Tim Appelhans [tim.appelhans at gmail.com]
Sendt: 24. juli 2015 3:14
Til: r-sig-geo at r-project.org
Emne: Re: [R-sig-Geo] mapView: basic interactive viewing of spatial data in R

Edzer,
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.

Tim

>
> 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)
Germany

Tel +49 (0) 6421 28-25957

http://environmentalinformatics-marburg.de/

        [[alternative HTML version deleted]]