ENH: Add TransformBounds to OSR Coordinate Transformation

[snowman2]

Related:

• https://lists.osgeo.org/pipermail/gdal-dev/2021-July/054450.html
• PROPOSAL: proj_transform_bounds PROJ#2779
• ENH: Add proj_trans_bounds PROJ#2882

Proposing to expose the proj_trans_bounds method in GDAL with PROJ 8.2+:

• C Bindings: OCTTransformBounds (potentially useful for rasterio transform_bounds)
• Python Bindings: def TransformBounds

I would be willing to work on adding this if this addition is approved.

[rouault]

why not ?
There are a few subtleties to take into account:

• a PJ* object isn't necessarily constructed:
  • when going from webmercator to WGS84:

    gdal/gdal/ogr/ogrct.cpp

    Line 1238 in b9d097b

    // Detect webmercator to WGS84

  • if the source and target CRS are the same:

    gdal/gdal/ogr/ogrct.cpp

    Line 1513 in b9d097b

    if( options.d->osCoordOperation.empty() && poSRSSource && poSRSTarget )

• the data axis to SRS axis mapping concept should be taken into account before and after running proj_trans_bounds. See

  gdal/gdal/ogr/ogrct.cpp

  Line 2055 in b9d097b

  if( poSRSSource )

  and

  gdal/gdal/ogr/ogrct.cpp

  Line 2564 in b9d097b

  if( poSRSTarget )

• you'll have to add a dummy implementation for a number of classes that derived from OGRCoordinateTransformation (in a few utilities, in the DXF driver, etc). None of them would call then TransformBounds() methods so this is not an issue. Likely add a "return false" as the default implementation in the base class, and have it only implemented in OGRCT

The 2 variations of GDALComputeAreaOfInterest() in alg/gdaltransformer.cpp could potentially use the new method, but probably not something to do in a first time, because we'll still need a working implementation for < 8.2, and this function isn't directly tested, so verifying that the new implementation works equivalently as the existing one would require some debug instrumentation