<div dir="ltr">I don't have a real example to hand, but consider satellite imagery which has not been processed but the file just has a GCP-based transformation which warps it to something like this in flat (lon/lat or mercator) space.<br><div><br></div><div><a href="https://drive.google.com/file/d/1Yzxy3zTUiU2OIyN0EiZFMeYIDwWj4AqG/view?usp=sharing">https://drive.google.com/file/d/1Yzxy3zTUiU2OIyN0EiZFMeYIDwWj4AqG/view?usp=sharing</a><br></div><div><br></div><div><div>Just transforming the four corners does NOT give the overall bounding box for ALL the final pixels because the top edge (in this case) bulges upwards.</div><div><br></div><div>Right now we are transforming every pixel coordinate along each of the four edges in order to find the true min/max, if we know the transform could be non-linear, which you presumably MUST assume it IS in the GCP case, but are there NON-GCP (just an OGRCT) transforms where you can still make assumptions about the true bounding box based on just the transforms of the corners. I doubt it, but I'm asking anyway.</div><div><br></div><div>Obviously we could choose to approximate by just testing say 100 equally-spaced pixels along each edge, then that's probably good enough, as the transformation is unlikely to have any local deviations in the bits that we skip over, but it still seems risky.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 1:41 PM Scott via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The bbox is created using the xmin,ymin,xmax,ymax found in the geometry. <br>
Assuming every pixel can be represented as a geometry, that's your bbox.<br>
<br>
On 5/3/24 13:18, Simon Eves via gdal-dev wrote:<br>
> Yes, but that's just the corners.<br>
> <br>
> Consider, say, a raster that contains a satellite sweep which is not <br>
> axis-aligned but forms a "windshield wiper" shape in lon/lat space. The <br>
> bounding box of ALL the pixels is not just the bounding box of the corners.<br>
> <br>
> On Fri, May 3, 2024 at 1:09 PM Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</a> <br>
> <mailto:<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</a>>> wrote:<br>
> <br>
> Maybe I don't understand your question, but in gdalinfo you have the<br>
> four corners as lat-lon<br>
> <br>
> On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev,<br>
> <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a> <mailto:<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>>> wrote:<br>
> <br>
> So we are trying to optimize our raster import process, and<br>
> particularly the steps to derive the final WGS84/4326 bounding<br>
> box for a raster file or tile thereof.<br>
> <br>
> Obviously in the general case, the transform is from integer<br>
> pixel coordinate through the Affine Transformation matrix and<br>
> then whatever OGRCoordinateTransformation is required to get to<br>
> WGS84/4326, and perhaps a GCP-based mesh transformation too.<br>
> <br>
> Currently we are deriving the bounding box by passing all pixels<br>
> of the four edges of the file/tile through the full transform,<br>
> except in the simple Affine-only case where we just transform<br>
> the four corners.<br>
> <br>
> Is there any shortcut API provided by GDAL or PROJ to allow the<br>
> bounding box to be computed (or at least safely over-estimated)<br>
> in the general case? I'm assuming that even a non-GCP <br>
> OGRCT could still be non-linear such that just transforming the<br>
> corners is insufficient.<br>
> <br>
> Thanks in advance,<br>
> <br>
> Simon<br>
> <br>
> -- <br>
> Simon Eves<br>
> Senior Rendering Engineer<br>
> +1 (415) 902-1996<br>
> <a href="mailto:simon.eves@heavy.ai" target="_blank">simon.eves@heavy.ai</a> <mailto:<a href="mailto:simon.eves@heavy.ai" target="_blank">simon.eves@heavy.ai</a>><br>
> <br>
> <<a href="http://www.heavy.ai" rel="noreferrer" target="_blank">http://www.heavy.ai</a>><br>
> <br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a> <mailto:<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> <<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>