Wow. Can't believe I missed the middle one, at least. Thank you, Even, as always!
Simon On Fri, May 3, 2024 at 3:03 PM Even Rouault <even.roua...@spatialys.com> wrote: > ==> 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 <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 > listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
