<div dir="ltr">I like it.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com">j1@jimenezshaw.com</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"><div dir="ltr"><div>Now I think I understand what you mean.</div><div>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.</div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 3 May 2024 at 22:18, Simon Eves <<a href="mailto:simon.eves@heavy.ai" target="_blank">simon.eves@heavy.ai</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"><div dir="ltr">Yes, but that's just the corners.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 1:09 PM Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</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"><div dir="auto">Maybe I don't understand your question, but in gdalinfo you have the four corners as lat-lon</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">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"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><div><br></div><div>Thanks in advance,</div><div><br></div><div>Simon</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Simon Eves<div>Senior Rendering Engineer</div><div>+1 (415) 902-1996<br><a href="mailto:simon.eves@heavy.ai" rel="noreferrer" target="_blank">simon.eves@heavy.ai</a></div><div><span><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="http://www.heavy.ai" rel="noreferrer" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:medium;display:inline-block;overflow:hidden;width:156px;height:29px"><img width="156" height="29" style="margin-left: 0px; margin-top: 0px;"></span></span></a></p></span></div></div></div></div></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" rel="noreferrer" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>