ezwarp ideas...

[h-a-graham]

👋 Hello and welcome to ezwarp!

This package is very new and no doubt could be improved - let's chat about what could be better!

[mdsumner]

I understand better now why the key focus is on resolution, it's because usually we're reprojecting a whole map, and it will have a new extent but we'd like to match the resolution of the source, or we know the resolution we need.

This is different to my first successes with the warper, I knew it could deliver pixels to any window fast, and the minimum is ncol,nrow,extent, which is the way rasters in R are presented too (and rasterImage and any plot for that matter).

So with gdalwarp most users just give a crs, and it figures out the projected extent, and does a bit of heuristics to match the target resolution to the source - next level user (probably) specifies the resolution, and further use then the extent.

It's advanced use to set up a target extent, and especially one aligned to a specific (integer) offset, but that's where I started getting traction (also that works for multiple disparate and global sources, we might want a map anywhere it has no real relationship to the entire available dataset).

So then, there's all the alignment logic, for the source and no crs change that is what projwin in gdal_translate does (with nearest neighbour), and in gdalwarp there is -tap that ensures the -te if specifed (or the implied extent if not) aligns neatly to the grain of -tr and there's a few other cases for alignment heuristics and desirable situations. (one thing gdal needs is -tap for -ts, to align to the source so it's the same as a simple gdal_translate call without us doing the math externally).

All that stuff for me is in vaster , and I'd like to collect it all in one place, I just haven't done anything with a resolution-first input, and some of the cases need actual proj to reproject, but most is pure arithmetic.

I'm putting some stuff into gdal itself, but I haven't figured it all out yet and there's a few complications still. This project is awesome for stimulating my thoughts and perspectives, in summ for now I just want to make sure we get this core logic stuff in one place, not all in gdal but at least clear how it relates to it. The wk package will be important here too, and I hope we can get all the pure grid logic cleaned up into one core. (slippymath is another part of this).

more later, thanks! interested to hear your thoughts

[mdsumner]

hey so I just wrote a new version of the vapour warper code, it's way simpler - and now all of target crs, extent, dimension are completely optional - inside GDAL there is a "suggested warp output" feature to handle all these cases, so I think we can get a function that's much more like gdalwarp itself, but with some layers to give our most common needs:

• crs + res
• crs + extent
• crs only (naughty!) **
• crs + extent + res
• crs + extent + dim

All the source-augmenting stuff is now handled by vapour_vrt (plus some newer things I need).

I was happily surprised, I finally got to a place to be able to try this and it worked first time. Lots to check but it's very promising.

** fwiw, - this literally causes problems with stereographic, because when the code tries to match the target resolution to the source it can end up with enormous or infinite expanses that the data covers (it should fold back to match the dimension more or less rather than the resolution, I'm interested to see if GDAL could have that as a new feature)

[mdsumner]

the crux is I guess we need the output to carry its dimension, extent, crs with it - whereas before vapour_warp_raster just made you specify those upfront so there was no need for it. I can put that on attributes, and have helpers for wk, terra, stars I suppose - but also, it might be a file path as output but still have those attributes.

[h-a-graham]

Awesome, this sounds really useful - by the sounds of things it'll save a fair bit of code in this package too and allow for a ton of flexibility! Agree, the file path/vector with attributes would be super useful. re. the helpers - also would save a bunch of code in here; I had assumed you might want to keep that seperate from vapour but from my perspective it'd be great to have it all in one place!

In gdal, what happens if you specify crs + extent + res and the res does not allow for a grid to to exactly conform to the extent? I had assumed this would throw an error (only based on some very limited poking)?

Is this new functionality on the vapour GitHub?
Cheers!

[mdsumner]

this is a good question, there's also the -tap argument that interacts with -tr (but not -ts, I discussed with Even about a new option there). I need to get my head around these cases, I will put up an illustration so we can explore this more easily 🙏

[mdsumner]

not on GitHub but I'll get it soon