[gdal-dev] Efficient raster bounding box transformation?

Scott public at postholer.com
Fri May 3 13:41:43 PDT 2024


The bbox is created using the xmin,ymin,xmax,ymax found in the geometry. 
Assuming every pixel can be represented as a geometry, that's your bbox.

On 5/3/24 13:18, Simon Eves via gdal-dev 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 
> <mailto: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 <mailto: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 <mailto:simon.eves at heavy.ai>
> 
>         <http://www.heavy.ai>
> 
>         _______________________________________________
>         gdal-dev mailing list
>         gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>         https://lists.osgeo.org/mailman/listinfo/gdal-dev
>         <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


More information about the gdal-dev mailing list