support for other projections

[edzer]

https://kartena.github.io/Proj4Leaflet/ provides other projections using leaflet. It would be nice to have the option to plot an sp object in its own CRS, and let the user define the tile server URL for this CRS.

[tim-salabim]

Edzer, I totally agree that this would be nice to have. I think this will not be trivial and we need to be really careful not to compromise mapview's ease of use for spatial non-expert users. Another point to consider is that mapview is in large parts a wrapper around RStudio's leaflet package and I am hesitant to ship mapview with a local modified fork of the leaflet package. Hopefully they will include the proj4leaflet plugin in a future release.

My take on this is that it would be best to provide an option for expert users to set an argument (e.g. force.proj = TRUE) to indicate that the native CRS of the data should be used which will then entail that the user needs to provide a suitable tileserver for that projection as it will be impossible to cater for all CRS flavours in a general manner. For this case we could then use a special function to render the data with its native CRS utilising proj4leaflet. This would, however, mean that look and feel of the generated visualisation may be slightly different from the leaflet package based solution.

@Stefan: do you think you will have time to give this a go on the JavaScript side of things? @gisma: any additional thoughts, especially regarding the big data solutions? @edzer: any additional thoughts?

[gisma]

Actually even if I was a bit cautious while agreeing with Tim's point of keeping mapview as easy as possible I think it would be a great feature especially for more advanced users in their all day work. So if we are able to ensure that the mapview user ist NOT able to take the common online maps but has to use local data or appropriate web based data I suppose we will generate no bigger problems or disadvantages for the ease of use. For the first solution we have already a prototype-function that generates map tiles of any given local raster for the usage with leaflet. Well and the second opportunity has to be controlled by the users themselves. Tim has addressed the big data solutions. As far as I see there should be no problems at all. If we take the already existing plugin that Edzer has mentioned, we will be able to use the integrated map-to-canvas approach. Actually this is all we need so far for big data. I think this is a very promising issue and I will try to implement it for big data during the next weeks.

Am 20.02.2016 um 02:21 schrieb tim-salabim:

Edzer, I totally agree that this would be nice to have. I think this will not be trivial and we need to be really careful not to compromise mapview's ease of use for spatial non-expert users. Another point to consider is that mapview is in large parts a wrapper around RStudio's leaflet package and I am hesitant to ship mapview with a local modified fork of the leaflet package. Hopefully they will include the proj4leaflet plugin in a future release.

My take on this is that it would be best to provide an option for expert users to set an argument (e.g. force.proj = TRUE) to indicate that the native CRS of the data should be used which will then entail that the user needs to provide a suitable tileserver for that projection as it will be impossible to cater for all CRS flavours in a general manner. For this case we could then use a special function to render the data with its native CRS utilising proj4leaflet. This would, however, mean that look and feel of the generated visualisation may be slightly different from the leaflet package based solution.

@Stefan https://github.com/Stefan: do you think you will have time to give this a go on the JavaScript side of things? @gisma https://github.com/gisma: any additional thoughts, especially regarding the big data solutions? @edzer https://github.com/edzer: any additional thoughts?

— Reply to this email directly or view it on GitHub https://github.com/environmentalinformatics-marburg/mapview/issues/13#issuecomment-186474715.

[gisma]

Folks, I am afraid there are some more new questions but at least I have integrated some very raw prototype routines in the develop branch. Unfortunately it was necessary to update to the last stable leaflet 0.77 to make proj4leaflet running. I did already a lot of checking but I do not know if it breaks something. Testing is highly appreciated. The main problem is that afaik there is no obvious solution to initialize htmlwidget objects during the creation dynamically. However to keep in line with all the benefits of the leaflet/htmlwidget concept we have to use it.
As far as I see this will be not a problem in between +/- 85 deg latitude. You can use then the basic map objects with its 4 CRSs and adapt it. But if you leave the common webmapping area you have to set up a static map object. Exactly this is what I did for the antarctic region. IMHO the central problem was to get a correct and fast handling of the raster data. This is not even always working with served maps from public tile servers. To handle it on the users side is even using a mature GIS like QGis not always that easy. I think the three functions makeTile, localTiles3031 and visEarthPole are a fairly good starting base on which we can build. On JS side sp objects are pretty easy to implement. So up to now my idea is to use (as Tim suggested) an argument force.proj = TRUE. If this is used you will switch to local projections and at least at the moment a subset of the mapview styling options.

@edzer do you think this is worthwhile even if there is not the full set of mapview arguments? @tim-salabim do you think we first should focus on the integration the proj4eaflet plugin in the R leaflet package or in the update of big data and extension of a seperate force.proj branch?

[tim-salabim]

Chris, this looks like a pretty good starting point to me. Awesome work!! I don't see why we need to integrate this into the R leaflet based solution at all. It is, much like the support for big data, a feature of mapview. Therefore, I would suggest we focus on integrating it as closely as possible to the R leaflet wrappers (much like bview and fpview), but I don't see a problem with it being not 100% compatible with leaflet.

We can surely define a "+" function that can serve the special cases bview, fpview and the proj4leaflet solution.

For the time being, I suggest we treat the proj4leaflet implementation similar to the big data implementation. It is, after all, a very specialised case.

Thus, to answer your question, I would propose to treat it as yet another specialty function and not integrate it into bview etc. This way we keep things clean and can re-visit the whole infrastructure once we know how all the functions play together.

[edzer]

Chris, I get stuck at makeTile; after manually making the directories, downloading and manual unzipping, I see:

> makeTile(fn=fn,outPath="~/proj/LeafletTiles/etopo1/", s_srs= epsg3031,t_srs= epsg3031)
Error in makeTile(fn = fn, outPath = "~/proj/LeafletTiles/etopo1/", s_srs = epsg3031,  : 
  unused argument (fn = fn)

with

> sessionInfo()
R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8          LC_NUMERIC=C                 
 [3] LC_TIME=en_GB.UTF-8           LC_COLLATE=en_US.UTF-8       
 [5] LC_MONETARY=en_GB.UTF-8       LC_MESSAGES=en_US.UTF-8      
 [7] LC_PAPER=en_GB.UTF-8          LC_NAME=en_GB.UTF-8          
 [9] LC_ADDRESS=en_GB.UTF-8        LC_TELEPHONE=en_GB.UTF-8     
[11] LC_MEASUREMENT=en_GB.UTF-8    LC_IDENTIFICATION=en_GB.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] mapview_1.0.9     leaflet_1.0.1     curl_0.9.5        gdalUtils_2.0.1.7
[5] raster_2.5-2      sp_1.2-2         

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.3         magrittr_1.5        rasterVis_0.37     
 [4] munsell_0.4.3       colorspace_1.2-6    lattice_0.20-33    
 [7] foreach_1.4.3       plyr_1.8.3          parallel_3.2.3     
[10] rgdal_1.1-3         grid_3.2.3          gtable_0.2.0       
[13] png_0.1-7           R.oo_1.20.0         latticeExtra_0.6-28
[16] htmltools_0.3       iterators_1.0.8     digest_0.6.9       
[19] OpenStreetMap_0.3.2 rJava_0.9-8         RColorBrewer_1.1-2 
[22] ggplot2_2.1.0       htmlwidgets_0.6     R.utils_2.2.0      
[25] codetools_0.2-14    scales_0.4.0        R.methodsS3_1.7.1  
[28] stats4_3.2.3        satellite_0.2.0     hexbin_1.27.1      
[31] zoo_1.7-12         

[gisma]

Edzer,

thanks for checking. As far as I see I did rename the fn argument to x. So please try:

x="/home/creu/proj/antarctica/Quantarctica2/Basemap/Terrain/ETOPO1_DEM.tif" t<-makeTile(x=x,outPath="/home/creu/proj/makeTile/etopo1DGM", s_srs= epsg3031,t_srs= epsg3031)

Please note that you have to use absolute pathes. It seems that the gdal wrapper calls don not handle correctly the ~/ abbreviation. The outpath directory will be created. In addition you'll probably see some warnings. I have to deal with them later but they should be no problem.

[gisma]

Tim ,

sounds good. I think I will be able to integrate the sp objects till the weekend and clean it up to allign it with the current concept. I will keep it in the "big data way".

[gisma]

Folks, you will find an update. Mainly a function called projView is producing arbitrary projected leaflet maps. Please have a look at the help. It works for the examples and if you deal carefully with the values you can integrate your own online resources. Nevertheless there are a lot of things to do. Up to now it is just for wms services, common tile servers (OSM tiles). Additionally you can put vector data on the maps (up to now without interactivity). I know thats the commandline looks pretty ugly and complicated. I think in future there should be a hefer function to generate the correct input lists. Any suggestion are welcome. cheers Chris

[gisma]

I' ve added interactivity. Basically this is now working for "normal" amounts of data.

Due to the fact that the "big data" approach is using optimized latlng to canvas mapping it will be not that easy to integrate as I thought. To be honest right in the moment I have just some faint ideas.

Any suggestions and feedback is highly appreciated. cheers

[gisma]

The first release of projView is on the develop branch. I will soon add some howtos. Please note: (1) it is still only for WMTS REST and similar services. (2) projections issues keep toublemakers. Even more you have to control a lot of additional parameters if you deal with online projections (you'll find a first help version at projView) (3) to keep it flexible I think it makes sense to integrate in projView a defined interface similar to the visEarthPole example.

so please check and make suggestions. cheers Chris

[mdsumner]

I'm having issues with this code (otherwise I can do other things pretty well like contour a polar raster and projView() it. )

library(mapview)
library(maptools); data(wrld_simpl)

library(rgdal)
## pick the polar service and project southern regions
tileservice <- map.types$NASA
projection_ts <- function(x) x$params$t_srs

mp <- spTransform(subset(wrld_simpl, NAME == "Antarctica"), projection_ts(tileservice))
## so far so good
pv1 <- projView(mp, map.types = tileservice) 
## but now I just get "?" after new lines (why?)
pv2 <- projView(campsQ2)

If I try to "+" any projView objects together I get the problem, or by creating the objects one after the other.

This is mapview develop 1.0.13 6c012c1f486654f79fd0b180c7f98cb8e2083e8f

Built: R 3.2.4; x86_64-w64-mingw32; 2016-04-14 10:52:05 UTC; windows

Thanks, this is looking very useful.

[tim-salabim]

@mdsumner I also see the ? and I am not sure where it comes from as of now. As a solution to get the second projView() call working:

pv2 <- projView(campsQ2, map.types = tileservice)

should get rid of the ? and render correctly.

As for + this is not yet implemented for the non-leaflet (as in leaflet-package) based functionality. We will add this at some stage, but this comes down to understand the nitty gritty bits of the leaflet package which, as always with other people's code, can be a bit tricky.

[mdsumner]

@tim-salabim Oh! Very sorry, let's put that down to first-use blindness. :)

Very good - more soon. Thanks

[tim-salabim]

Given that leaflet now has proj4leaflet support I am closing this issue