[gdal-dev] Efficient raster bounding box transformation?

[Even Rouault]

==> 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 list
> gdal-dev at lists.osgeo.org
> https://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/20240504/58efeffe/attachment-0001.htm>