add R/map_location.R

[mpadge]

This addresses #78 by getting rid of current warnings described there, and also enables this:

mapdeck (location = roads,
         zoom = 12) %>%
    add_path (data = roads,
              stroke_colour = "RIGHT_LOC")

The map will then be centred on the roads item. @tim-salabim is happy to help with the zoom-to-bbox kinda stuff necessary to establish values for zoom, although deck.gl seems to do this quite differently to leaflet ...?

[mdsumner]

Ping @MilesMcBain

[SymbolixAU]

Thanks for this, and I can see the logic.

But, I'm wondering if there's a way we can do it without passing the roads object twice to two different calls.

And I think we need to consider if the map should zoom to a specific layer, or show all the layers. Take this contrived example

mapdeck( location = roads ) %>%
  add_path( data = roads ) %>%
  add_scatterplot( data = capitals )

All the capitals data will be out of the boundaries of the map because it's focused on the roads (in Victoria).

This may need to be handled at the javascript level once all the data has been processed?

[mpadge]

Yeah, fair point, although my view on those things at the moment is that until it is clear that most operations will be piped, the primary mapdeck() call may still be made as stand-alone. This was an attempt at a minimal, and minimally intrusive, fix for cases when location is passed to that function yet causes the current warning, soon-to-be error of #78.

The larger issue of where best to focus can then be handled through percolating through series of modifications to your current x object:

 x = list(
    access_token = token
    , style = style
    , pitch = pitch
    , zoom = zoom
    , location = location
  )

  # create widget
  mapdeckmap <- htmlwidgets::createWidget(
    name = 'mapdeck',
    x = structure(
    	x,
    	mapdeck_data = data
),

Each call can then simply query x$x and expand bounding boxes to encompass the maximal range of any subsequently submitted / piped data (and I guess re-center as well). Relatively straightforward, but you'd still need something like the map_location functions to get you started. At least that's the way it seems to me, but with the big caveat that I've only perused what I thought to be relevant bits of code, and you're the one with the master overview here, so entirely your call of course.

[SymbolixAU]

I think it's on the right lines. And I think I need to handle the multiple layers each requiring their own bounding-box within the javascript code, where I can make use of the change_location() function to change the view dynamically each time a new layer is added.

The zoom level will be tricky though.

Also, for #78, I'm moving away from jsonlite so I'm not sure this will impact mapdeck that much.

[mpadge]

That sounds good. One extra thought: It will likely be useful / necessary somewhere down the line to enable a fixed grid to be plotted (as in any pandoc-type outputs where strict control might be desirable). What I mean is creation of some kind of static document from (for example) an .Rmd with a mapdeck chunk that outputs the viewport as a static image. (This is not currently possible because, as far as I'm aware, htmlwidgets don't actually render anything in this way other than direct leaflet, but that will change.) This would then need an ability to override any automatic, dynamic change of view with successive layers. The thought is then that the ability to pass location and zoom to the initialmapdeck function could easily be implemented as a kind of "master" control over these aspects that is not be changed by subsequent layers.

And so

mapdeck( location = roads ) %>%
  add_path( data = roads ) %>%
  add_scatterplot( data = capitals )

will simply stay focussed on Melbourne, but

mapdeck( ) %>%
  add_path( data = roads ) %>%
  add_scatterplot( data = capitals )

would zoom out to encompass all capitals

[SymbolixAU]

yeah I'm thinking along those lines too. I'm also considering something like

mapdeck() %>%
add_scatterplot( data = capitals ) %>% 
add_path( data = roads, focus_layer = T )

So you can focus the viewport on a specific layer. I think this will be useful in Shiny when adding & removing multiple layers.

[SymbolixAU]

I can't find any reference in deck.gl on how to dynamically set the zoom and bounds.

But I think we can make use of the OSM zoom levels (which mapbox uses) to calculate the required zoom for each layer
https://wiki.openstreetmap.org/wiki/Zoom_levels

bbox <- sf::st_bbox( roads )
str( bbox )
abs( bbox[["xmin"]] - bbox[["xmax"]] ) 
## 0.122197
## approx zoom = 11 (https://wiki.openstreetmap.org/wiki/Zoom_levels)
lon <- mean(c(bbox[["xmin"]], bbox[["xmax"]]))
lat <- mean(c(bbox[["ymin"]], bbox[["ymax"]]))

mapdeck() %>%
	add_path(
		data = roads
	) %>%
	mapdeck_view(
		location = c(lon, lat)
		, zoom = 11
	)

[SymbolixAU]

Also, for #78, I'm moving away from jsonlite so I'm not sure this will impact mapdeck that much.

Argh - it's caused inside htmlwidgets or shiny, so I guess I also have to account for it.

[SymbolixAU]

Each layer now gets an update_view = TRUE and focus_layer = FALSE arguments so the map will auto-locate to the data being plotted.

It's a bit crude, but I think it's OK for now.