[gdal-dev] Efficient raster bounding box transformation?

[Simon Eves]

Wow. Can't believe I missed the middle one, at least. Thank you, Even, as
always!

Simon

On Fri, May 3, 2024 at 3:03 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> ==> GDALCreateApproxTransformer():
> https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd
>
> Otherwise there's OGRCoordinateTransformation::TransformBounds(), but
> this works from a rectangle in the source CRS
>
> Most simple would be to use GDALAutoCreateWarpedVRT() (
> https://gdal.org/api/gdalwarp_cpp.html#_CPPv423GDALAutoCreateWarpedVRT12GDALDatasetHPKcPKc15GDALResampleAlgdPK15GDALWarpOptions)
> to EPSG:4326 and just take the extent of the warped VRT.
> Le 03/05/2024 à 23:25, Simon Eves via gdal-dev a écrit :
>
> I like it.
>
> On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw <j1 at jimenezshaw.com>
> wrote:
>
>> 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
>>>>>
>>>>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240503/a19f21b5/attachment.htm>