[gdal-dev] Efficient raster bounding box transformation?

[Javier Jimenez Shaw]

Now I think I understand what you mean.
One effective way is to convert the four sides of the image. To avoid the
conversion of every pixel, you can start a partition process. Then compare
the difference between the transformed central point and just the mid point
between the extremes. If that different is bigger than an certain
threshold, keep subdividing each side. With that you have a good
approximation of the borders of the image transformed, and then you can
compute your bounding box.
The idea is not mine. Even Rouault mentioned it last year in FOSS4G. IIRC,
it is used by gdalwarp to not reproject every single point; once the
subdivision is enough, then it does linear interpolation.

On Fri, 3 May 2024 at 22:18, Simon Eves <simon.eves at heavy.ai> 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>
> 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/5904de6d/attachment.htm>