Can Tyler support other projections? about tyler.jl HOT 21 OPEN

@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.

from tyler.jl.

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.

from tyler.jl.

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

from tyler.jl.

Is it though?

Don't we just define a warped mesh so the warping of tiles happens on the GPU?

from tyler.jl.

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

from tyler.jl.

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.)

from tyler.jl.

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.

from tyler.jl.

@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?

from tyler.jl.

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 ...

from tyler.jl.

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)

from tyler.jl.

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?

from tyler.jl.

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

from tyler.jl.

grounded pessimism is my comfort zone ;-)

from tyler.jl.

Honestly by default I expect a Julia package to end up being the fastest and most flexible implementation that exists 😂

from tyler.jl.

@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.

from tyler.jl.

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.

from tyler.jl.

@visr do you have that code you wrote for projecting maps somewhere? I've never actually made a mesh plot with Makie.jl 😅

from tyler.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

from tyler.jl.

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.

from tyler.jl.

from tyler.jl.

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.

from tyler.jl.