Add a function basemap to get a static image from Tyler, and some converts for image#91
Add a function basemap to get a static image from Tyler, and some converts for image#91asinghvi17 wants to merge 19 commits intomasterfrom
basemap to get a static image from Tyler, and some converts for image#91Conversation
|
(This doesn't work now but will work with #90, since that imports FileIO) |
Thoughts? How do we determine which CRS the input bbox takes? Its currently WGS84 but do we want to give an option to go to webmerc at all? Conversion between the two is mostly lossless...
|
Is there a reason Would let other packages skip the Makie dep |
|
HTTP.jl and ImageIO.jl are required to stitch the tiles together, but if those can go in MapTiles I'm fine to upstream this |
|
Ahh right. Might be worth it for Plots.jl uses |
|
This will have to be reimplemented based off #95 |
| ````@example nasagibs | ||
| meshimage( | ||
| xs, ys, img; | ||
| source = "+proj=webmerc", # REMEMBER: `img` is always in Web Mercator... |
There was a problem hiding this comment.
would be nice if we kept crs and lookups attached - I think there is a package that does that ;)
There was a problem hiding this comment.
That's true :D - but then we'd have to add that as a dependency to Tyler as well.
The other alternative is to add ImageIO and HTTP dependencies to MapTiles or TileProviders, and have them prompt individually. But I don't think we want that...
There was a problem hiding this comment.
It would be nice to have a method of basemap that returned a Raster at least, in an extension here or in Rasters.
There was a problem hiding this comment.
Question is how to trigger it. We could just pass the Raster type as the first argument?
There was a problem hiding this comment.
I would go the other way and create a constructor for Raster(::TileProvider, extent; size, res, ...).
There was a problem hiding this comment.
This way it's at least a similar interface to what RasterDataSources has, for example
There was a problem hiding this comment.
Right, just call basemap internally to get the data. A bit like RasterDataSources.jl syntax
There was a problem hiding this comment.
Whats weird about that is it would need using Tyler which needs Makie when it really just needs ImageIO and HTTP
There was a problem hiding this comment.
It's the ImageIO part that gives me the shivers, since it's a lot of heavy binary dependencies
There was a problem hiding this comment.
I'm more scared of the Makie precompile time for Plots.jl users
| return basemap(provider, bbox, _size; min_zoom_level, max_zoom_level) | ||
| end | ||
|
|
||
| function basemap(provider::TileProviders.AbstractProvider, boundingbox::Union{Rect2{<: Real}, Extent}, size::Tuple{Int, Int}; min_zoom_level = 0, max_zoom_level = 16) |
There was a problem hiding this comment.
Shouldn't size allow a NamedTuple here?
There was a problem hiding this comment.
Oh right thats handled above. Maybe make this _basemap then so its internal
There was a problem hiding this comment.
That sounds complicated - should it? I don't see that anywhere else as well
There was a problem hiding this comment.
Then you have to handle (; X, Y), (; Y, X), ...
There was a problem hiding this comment.
I just read in _z_index docs that res should be (X=res, Y=res) so thought that was the idea with size/res here. Most of Rasters works like this too so it makes sense to me
|
|
||
| ## Keyword arguments | ||
|
|
||
| `size` and `res` are mutually exclusive, and you must provide one. |
There was a problem hiding this comment.
Would be good to mention that they are approximate
| `size` and `res` are mutually exclusive, and you must provide one. | ||
|
|
||
| `min_zoom_level - 0` and `max_zoom_level = 16` are the minimum and maximum zoom levels to consider. | ||
|
|
There was a problem hiding this comment.
Could we also just let users specify z here?
There was a problem hiding this comment.
As an alternative to res and size, yes
| - Some function that returns the tile size for a given provider / dispatch form | ||
| =# | ||
| tile_widths = (256, 256) | ||
| tilegrid_size = tile_widths .* length.(tilegrid.grid.indices) |
There was a problem hiding this comment.
We should warn here if this is too big. Probably people don't intend to get more than 100MB or so? and its pretty easy to accidentally ask for a 100GB
There was a problem hiding this comment.
Yeah, that could be an annoying footgun if using res instead of size
|
This one also looks like a lot of work has already been put into it. How do we move forward with this, or decide not to? |
|
I think we want to factor a bunch of stuff out of Tyler and put it in MapTiles.... |
|
@asinghvi17 a lot of work went into this already? did things split out somewhere else, or should we try to get this one to the finish line? |
|
Nothing split out yet. We had some discussions about moving this to MapTiles and factoring out a MapTilesInterface.jl from that, which I haven't got to yet but hopefully can get to at some point. In that case most of the downloaders etc will also go to MapTiles and Tyler can depend on that once it's ready. Also there was some form of large refactor after I opened this PR, I don't remember exactly what it was, but I do remember that it may have caused issues with this PR so I didn't merge then. Can take a look again though, maybe we should get this in for now. But eventually it will live in MapTiles. |

This file provides the ability to get static base maps from Tyler.
Its main entry point is the
basemapfunction, which returns a tuple(x, y, z)of the image data (z) and its axes (xandy). The imageis in a web-mercator CRS, we need to figure out a way to also get eg WGS84 tiles.
This file also contains definitions for
convert_argumentsthat makethe following syntax "just work":
You do still have to provide the extent and image size, but this is substantially better than nothing.