Currently, net2cog does not support downscaling imagery (technically this is reprojection), specifically via the height and width API parameters, but this also applies to scaleSize.
In the context of net2cog running as a variable subsetter, this ticket is not relevant since a request to generate a TIFF with height and width specified will go to the harmony-gdal-adapter, at least in UAT https://github.com/nasa/harmony/blob/main/config/services-uat.yml#L776-L806
This matters when net2cog runs as a step in the imagenator service chain, and would primarily serve as an optimization. Let me give a specific example, say we're processing MUR data which has a source granule resolution of 36000x18000. When processed in Imagenator-L3, this goes through the following services:
- harmony-filtering-service: input is a full-resolution netcdf, output is a filtered (reduced number of variables) full-resolution netcdf
- net2cog: input is a full resolution netcdf, output is a full-resolution tiff
- HyBIG: input is a full-resolution tiff, output is a PNG/JPG (or tiled set) at the requested resolution
If the API call requests output images at 2560x1280 for example, there are two copies of the data stored at full resolution that never get used by the requestor.
This is a medium priority item requiring maybe 1-2 work days of effort to implement depending on how thorough we want our OGC API parameter support to be. Not blocking any functionality, but offers some performance gains and cost savings for opex of our Harmony services.
Currently, net2cog does not support downscaling imagery (technically this is reprojection), specifically via the
heightandwidthAPI parameters, but this also applies toscaleSize.In the context of net2cog running as a variable subsetter, this ticket is not relevant since a request to generate a TIFF with
heightandwidthspecified will go to theharmony-gdal-adapter, at least in UAT https://github.com/nasa/harmony/blob/main/config/services-uat.yml#L776-L806This matters when net2cog runs as a step in the imagenator service chain, and would primarily serve as an optimization. Let me give a specific example, say we're processing MUR data which has a source granule resolution of 36000x18000. When processed in Imagenator-L3, this goes through the following services:
If the API call requests output images at 2560x1280 for example, there are two copies of the data stored at full resolution that never get used by the requestor.
This is a medium priority item requiring maybe 1-2 work days of effort to implement depending on how thorough we want our OGC API parameter support to be. Not blocking any functionality, but offers some performance gains and cost savings for opex of our Harmony services.