[gdal-dev] Efficient raster bounding box transformation?

[Simon Eves]

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>
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> 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
>>
>> <http://www.heavy.ai>
>> _______________________________________________
>> 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/43b23e9b/attachment.htm>