Can Tyler support other projections?
Opened this issue · 21 comments
Has anyone tried to get Tyler.jl to work with basemaps in different projections?
Not yet, but I created JuliaGeo/MapTiles.jl#26 for this. I think that as long as your plot is in the same projection as the tiles, it is relatively easy. If not, we need to warp tiles, that would probably require some work here, perhaps using GeoMakie.
Warping of tiles is costly and should probably be done outside of Tyler. I would think that the tiles should always be in the desired projection and if they are not then the user would need to create a warped tile set
Is it though?
Don't we just define a warped mesh so the warping of tiles happens on the GPU?
I think you'll run into latency issues if your warping x/y/z tiles on the fly but maybe I'm wrong... thinking about QGIS, a base map in another projection always slows things down considerably
But qgis is doing that with the CPU right? Why would there be latency on the GPU?
(This is for GLMakie.jl so its done with opengl - this warping cant be harder for a GPU than e,g, rendering video game graphics onto meshes at 60fps.)
I'm not sure what QGIS is using but I do know that leaflet only works in native tile projection... but maybe this is somewhere where Julia can stand out... on the fly warping would be an amazing feature... as right now for our projects we need to create base maps in multiple projections which is a bit of a pain.
@visr can we just generate the mesh points for any projection using Proj.jl and use that to warp tiles, like you were doing in Angra?
Its some work to set up the pipeline. But it should run fast once the warped mesh is defined?
That sounds slow to me... Proj.jl transformations is often the slowest part of my pipelines. Would this only be applied when the figure is first compiled or would it be calculated every time the user panned or zoomed on the map... the later might create undesirable latency issues ...
So much doubt haha
The Proj.jl transformation is for the points in the mesh, at the start. So pretty fast.
Then the mesh warps the tiles on the GPU with no use of Proj.jl.
Or that's how imagine it will work.
(By some work to set it up, I meant for us to write it and make it work, but it didnt quite read like that)
I guess it would need some updating as you zoom in, but it shouldn't need too many points in the mesh at high zooms?
For global x/y/z tiles I think panning and zooming will be an issue ... for a local rendering I don't think it will matter
grounded pessimism is my comfort zone ;-)
Honestly by default I expect a Julia package to end up being the fastest and most flexible implementation that exists 😂
@visr can we just generate the mesh points for any projection using Proj.jl and use that to warp tiles, like you were doing in Angra?
That would be a fun experiment. You'd need at minumum to have every tile (corner) in the mesh. For zoom level 20 that'd be 1e12 nodes. So we probably need ways to reduce that number.
Yeah I was thinking for most projections tile corners would be enough. We could have a mesh_density keyword to change that if your doing something really warped.
And we only need to get one point per tile because its a grid, besides the edge tiles.
So just updating as we go is probably fine? Say we have 40 tiles plotted, we need to convert ~55 points from Proj.jl to get all the corners. And that's pretty fast? We can do that a few times a second as we move around without much overhead.
@visr do you have that code you wrote for projecting maps somewhere? I've never actually made a mesh plot with Makie.jl 😅
The three most common projections for global visualization are web mercator, south polar stereo and north polar stereo... so i think the warping would need to be more than corner points but I guess that's semantics at this point since we can adjust as we go
Yeah, I think we can try it with corner points, see how blocky it is and tweak from there. It may be that we need more points as we zoom out or something as well, rather than a fixed number.
And probably a lot of people wont be doing polar plots, in most of geography and ecology they're rare. Instead it will be warping from webmercator to something our analysis is usually in, like epsg:4326, or some local projection with better spatial properties for a simulation.
@visr do you have that code you wrote for projecting maps somewhere?
I never really cleaned this up properly, but here is what I was working on at the time:
https://gist.github.com/visr/33b2b67634833d7b45dc08e97da25cda
If you use the first rect I define, and color instead of img in mesh(gm; color = img) it plots it north up.
The thing I was trying was to see if we could avoid having to permute or flip dims by just creating the mesh in a way that aligns with the raster orientation, but didn't manage yet. Though for Rasters.jl you mentioned at the time that these operations were lazy anyways. And for tiles the orientation is known as well.
It's also worth noting that the idea of different layers/plots possibly having different source CRS, that is also part of MakieOrg/GeoMakie.jl#148. That should allow for more QGIS like combining of different source CRS onto one project CRS.
You'd need at minumum to have every tile (corner) in the mesh
At least in the GL backends, you can use uv coordinates over the mesh in order to not have to do this. It isn't quite as good looking as CairoMakie, but should suffice for our purposes here.
I wrote up a recipe which displays an image over a mesh in this fashion, and it should in theory be easy to make efficient. It's in this gist https://gist.github.com/asinghvi17/896b7851f6f91fae29242edfa6e08579 - the picture in the comments has a different boundingbox, but is actually the same when you look at the x and y values. The approach is kind of similar to yours, just with a small twist when it comes to how the transformation is implemented.
About the problems you seemed to have with rasters there - once the Rasters.jl Makie recipes are merged, we should be able to use those with no issues.