==> 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 list
gdal-dev@lists.osgeo.org
https://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
