-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a function basemap
to get a static image from Tyler, and some converts for image
#91
base: master
Are you sure you want to change the base?
Conversation
(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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good, but it kinda seems to me like basemap
should return a Raster
so it's one self contained object with all the metadata needed to plot in GeoMakie etc
Of course, dependencies etc make that more annoying
````@example nasagibs | ||
meshimage( | ||
xs, ys, img; | ||
source = "+proj=webmerc", # REMEMBER: `img` is always in Web Mercator... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question is how to trigger it. We could just pass the Raster type as the first argument?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go the other way and create a constructor for Raster(::TileProvider, extent; size, res, ...)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way it's at least a similar interface to what RasterDataSources has, for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, just call basemap
internally to get the data. A bit like RasterDataSources.jl syntax
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't size
allow a NamedTuple
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right thats handled above. Maybe make this _basemap
then so its internal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds complicated - should it? I don't see that anywhere else as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then you have to handle (; X, Y)
, (; Y, X)
, ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we also just let users specify z
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that could be an annoying footgun if using res
instead of size
This file provides the ability to get static base maps from Tyler.
Its main entry point is the
basemap
function, which returns a tuple(x, y, z)
of the image data (z
) and its axes (x
andy
). 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_arguments
that makethe following syntax "just work":
You do still have to provide the extent and image size, but this is substantially better than nothing.