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 <j...@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@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.e...@heavy.ai >> >> <http://www.heavy.ai> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
