Even Rouault

> Or expose as a separate gdal_translate/gdalwarp flag That should reasonably fit in gdal_translate architecture (controlled by an option), by using underneath a VRT assembling 2 sources.. gdalwarp -t_srs "+proj=longlat...

> Is there support for this transformation in VRT already? no, I gave above the hint how that could possibly be implemented, but work needed

Packaging GDAL is a significant effort. For Python'ers, While this is not equivalent to the pip experience, Conda is probably the best way to go that provides PROJ and GDAL...

> Clearly, Fiona and rasterio have already solved some of the problem of packaging libgdal for python-pip installations, so this feature request is only about providing a common denominator for...

> to avoid library conflicts if libgdal-foo.so and libgdal-bar.so are loaded in the same process, this is going to crash at runtime due to -foo using some symbols of -bar,...

> but requires someone stepping up to do the work ("a champion to lead the effort"). a champion for bootstrapping, and then an automated process. The process of manually building...

- The IUpsertFeature() proposal is a reasonable one. We'd want to add a OLCUpsertFeature capability for layers to advise its availability - I was wondering if a default implementation that...

superseded per #6199

Building against external shapelib is not recommended. Cf https://github.com/OSGeo/gdal/blob/c4355a360384812db4df180d1ee1a73e864ada9d/cmake/helpers/CheckDependentLibraries.cmake#L420 ``` # Disable by default the use of external shapelib, as currently the SAOffset member that holds file offsets in it...

> But this is something else then _fails to build_ a good way to enforce the recommendation :-) I don't have much desire to fix building against external shapelib, knowing...