[gdal-dev] Efficient raster bounding box transformation?

[Simon Eves]

I don't have a real example to hand, but consider satellite imagery which
has not been processed but the file just has a GCP-based transformation
which warps it to something like this in flat (lon/lat or mercator) space.

https://drive.google.com/file/d/1Yzxy3zTUiU2OIyN0EiZFMeYIDwWj4AqG/view?usp=sharing

Just transforming the four corners does NOT give the overall bounding box
for ALL the final pixels because the top edge (in this case) bulges upwards.

Right now we are transforming every pixel coordinate along each of the four
edges in order to find the true min/max, if we know the transform could be
non-linear, which you presumably MUST assume it IS in the GCP case, but are
there NON-GCP (just an OGRCT) transforms where you can still make
assumptions about the true bounding box based on just the transforms of the
corners. I doubt it, but I'm asking anyway.

Obviously we could choose to approximate by just testing say 100
equally-spaced pixels along each edge, then that's probably good enough, as
the transformation is unlikely to have any local deviations in the bits
that we skip over, but it still seems risky.

On Fri, May 3, 2024 at 1:41 PM Scott via gdal-dev <gdal-dev at lists.osgeo.org>
wrote:

> The bbox is created using the xmin,ymin,xmax,ymax found in the geometry.
> Assuming every pixel can be represented as a geometry, that's your bbox.
>
> On 5/3/24 13:18, Simon Eves via gdal-dev wrote:
> > Yes, but that's just the corners.
> >
> > Consider, say, a raster that contains a satellite sweep which is not
> > axis-aligned but forms a "windshield wiper" shape in lon/lat space. The
> > bounding box of ALL the pixels is not just the bounding box of the
> corners.
> >
> > On Fri, May 3, 2024 at 1:09 PM Javier Jimenez Shaw <j1 at jimenezshaw.com
> > <mailto:j1 at jimenezshaw.com>> wrote:
> >
> >     Maybe I don't understand your question, but in gdalinfo you have the
> >     four corners as lat-lon
> >
> >     On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev,
> >     <gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>> wrote:
> >
> >         So we are trying to optimize our raster import process, and
> >         particularly the steps to derive the final WGS84/4326 bounding
> >         box for a raster file or tile thereof.
> >
> >         Obviously in the general case, the transform is from integer
> >         pixel coordinate through the Affine Transformation matrix and
> >         then whatever OGRCoordinateTransformation is required to get to
> >         WGS84/4326, and perhaps a GCP-based mesh transformation too.
> >
> >         Currently we are deriving the bounding box by passing all pixels
> >         of the four edges of the file/tile through the full transform,
> >         except in the simple Affine-only case where we just transform
> >         the four corners.
> >
> >         Is there any shortcut API provided by GDAL or PROJ to allow the
> >         bounding box to be computed (or at least safely over-estimated)
> >         in the general case? I'm assuming that even a non-GCP
> >         OGRCT could still be non-linear such that just transforming the
> >         corners is insufficient.
> >
> >         Thanks in advance,
> >
> >         Simon
> >
> >         --
> >         Simon Eves
> >         Senior Rendering Engineer
> >         +1 (415) 902-1996
> >         simon.eves at heavy.ai <mailto:simon.eves at heavy.ai>
> >
> >         <http://www.heavy.ai>
> >
> >         _______________________________________________
> >         gdal-dev mailing list
> >         gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> >         https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >         <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240503/585a14af/attachment-0001.htm>