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.biv...@nhh.no ________________________________________ Fra: R-sig-Geo [r-sig-geo-boun...@r-project.org] på vegne av Tim Appelhans [tim.appelh...@gmail.com] Sendt: 24. juli 2015 3:14 Til: r-sig-geo@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@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]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo