I like it. On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw <j...@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.e...@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 <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
