Allow explicit bbox specification to cc_location
mpadge opened this issue · 9 comments
Current functionality presumes a point and buffer, but it would be good for most of the internals of get_loc to be farmed off to a different internal function beyond my_bbox. Another function could then just call the rest with explicit bbox. cc_bbox or something like that perhaps?
Hey that's coming! :) I thought that loc could dispatch on spatial types and ignore buffer, as a basic interface. Also needs a zoom/resolution/max-pixels or c. The key is to also separate the down_loading from the raster_merging (because we could get thousands of tiles from an extent), and I thought to use VRT for that.
Currently the ux reflects immediate visual feedback, but it's solid enough to move on from that. More soon!
loc can now be any of raster, sp, sf, and if so the buffer argument is ignored. max_tiles or zoom may be used to control the resolution.
Needs sanity for cases listed here
Will definitely need a "return_vrt" option, maybe as the default - use max_tiles/zoom with caution, the easiest is to run cc_location(, debug = TRUE) so you see the tiles and the zoom in use, then increment by 1 in either direction. cc_elevation returns more detail by default, but I think that should be changed.
We're dealing with very similar processes here and in osmdata::osm_elevation(). I'm interested in getting the highest-res elevation data possible. In cc_elevation() terms, this means zoom = 15, which fails on my machine, but even zoom = 14 actually downloads more data for a relatively small area (approx. 0.5-by-0.5) than the standard NASA 5-by-5 geotif anyway. This is what the convergence properties look like (with "zoom14" correlated against itself, so artificially forced towards 1):
That's encouraging that they're doing the same thing, but just suggests that for purposes of elevation alone, at some stage there could/should usefully be a switch from downloading hundreds of tiles to downloading a single 5-by-5 geotif.
Have you downloaded all of 4.1? What's the total size? About 30Gb I guess.
The tif really is GeoTIFF (no need for the .tfw/.hdr) but it's not compressed, it could be compressed internally to avoid the need for .zip. I got 66_20 a 25Mb download and a 65Mb .tif.
This is a good point and is where ceramic suffers scope creep, where it could just be a tile downloader/cacher - all the pull into a raster stuff belongs elsewhere.
When you fail is it because it's trying to build an in-memory raster? You get all the tiles ok?
yeah, tiles download but can't build in-memory raster
I've exposed the downloading separately to the raster merging in get_tiles(), and helper functions get_tiles_zoom(), get_tiles_dim() and get_tiles_buffer().
Currently in branch get-tiles.
Specifically, you can get a given zoom with
get_tiles_zoom(spatial-thingy, zoom)
Or, for the entire world
get_tiles_zoom(zoom = 2, debug = TRUE)
debug means "no download", and it will print the files that it would get
All in master now.
We done here