gdal reproject: add "size" to match gdalwarp '-ts', and allow (one) value to be 0

[mdsumner]

Feature description

I want to be able to set the target size, '-te' and '-ts' is my normal preference, and being able to have one of the sizes set to 0 is a real benefit.

Certainly interested to help implement this, though I guess if the trad apps and library versions remain there's no afaic. I wasn't much able to be active when the RFC was discussed.

Additional context

(I wonder if I'm missing something, because there doesn't seem to be the equivalent of '-outsize' for 'translate' conversion either?)

[rouault]

(I wonder if I'm missing something, because there doesn't seem to be the equivalent of '-outsize' for 'translate' conversion either?)

no, you're not missing anything. Fully replacing existing utilities is going to be a year-long process. I'm not sure to which command(s) resizing would belong. It definitely makes sense for reproject. For convert, maybe? There is alwyas this ambiguity of what belongs to translate vs warp.

[rouault]

For the sake of brainstorming: or should we have a dedicated resize subcommand ? "gdal raster resize -r cubic --size=1024,0 in.tif out.tif"
I'm a bit hesitant compared to have it in convert itself.
For warping, we definitely want to have it in reproject itself for efficiency purposes

[hobu]

gdal raster resize would mean NO WARPING, right? gdalwarp vs gdal_translate is very confusing right now for many users because it is hard to know which to use when. IMO, resize is a clear directive. Maybe this could provide antipode meaning to gdal raster reproject.

[rouault]

gdal raster resize would mean NO WARPING, right?

yes

Maybe this could provide antipode meaning to gdal raster reproject.

I don't understand what you mean. Even if we have a dedicated resize, we'll definitely need a resize capability directly in reproject (which ultimately goes to the GDALWarp() logic), because doing a resizing after warping would have consequences on the quality and speed.

[mdsumner]

I can't see my way through the ambiguities yet. I think of gdalwarp as an insanely general translate, able to take any input/s and paint them onto an arbitrary canvas, clip, resize, calculate, cutline, create, update .. it does everything and when inputs and/or output can be defined by non-regular geolocation arrays .. I have no idea what to call that!

I'm prepared to put a lot of effort into these applications to get the right mix, but I haven't got a strong vision yet. I wish we could reframe reproject as maybe "remodel" or "cast" (interpolate?) but maybe that's folly. I think having slightly limiting subcommands is good, so long as the full Godzilla is still available for experts.

I never liked how -r allowed translate to align to projwin rather than source pixels, I always thought that was a defining feature of gdalwarp vs translate, arbitrary output window alignment 🙏

[hobu]

I don't understand what you mean. Even if we have a dedicated resize, we'll definitely need a resize capability directly in reproject

What I meant is resize would never warp, but reproject might warp if it needs to. Users focused on performance or interpolation behavior could know to stay within the confines of resize.

Another question: could an optional output option of gdal raster reproject or gdal raster resize be the corresponding VRT? The thought is you build up a command line invocation with the options, configuration settings and data and such that you want and then emit the VRT. We do this in PDAL – pdal translate input.las output.las --pipeline-serialization mypipeline.json <-- the translate operation also outputs the pipeline that was constructed to complete the operation. In some PDAL data transformation scenarios, we then write this pipeline into metadata and such as a useful record of what happened to create the data. It also has value as a recipe for a user to replay the same scenario on their own data.

[rouault]

Another question: could an optional output option of gdal raster reproject or gdal raster resize be the corresponding VRT?

for those specific operations, as there's a VRT correspondance, yes. But for the more general problem of "sort'of'VRT'ifying" arbitrary (stream compatible) algorithms, see #11837 for which I'm awaiting for feedback.