Even Rouault
Even Rouault
you may potentially work around the problem by having SWIG installed so that the https://github.com/OSGeo/gdal/blob/dbf2ae50d0b43496c70328ccc4450c5ded90cc46/swig/python/CMakeLists.txt#L14 code path is taken
@zklaus can you check if https://github.com/OSGeo/gdal/pull/5833 fixes your issue ? I assume you use Ninja as the build tool ? I couldn't reproduce the issue with Visual Studio projects in...
@zklaus did PR #5833 help ?
> Would that be ok? fine to me
@zklaus Congrats for https://github.com/conda-forge/gdal-feedstock/pull/629 being now merge. Would be great if you could push upstream the patches you had to make
I tried to pick up patch https://github.com/zklaus/gdal-feedstock/blob/2972fd6abec521ed6f01f153207b8b90b6fc0636/recipe/0002-Use-cmake-path-instead-of-native-path.patch but it was causing regressions on installation of the Python bindings on one of our Windows config where paths such as "d:a/gdal/..." where...
I doubt this is a GDAL bug. This might rather be a lack of PROJ grids (like the ones in https://github.com/OSGeo/PROJ-data/tree/master/us_noaa but they are only for NAD83 to NAD83(HARN)), or...
> I assume that gdal2tiles.py always converts to 4326, is that not the case? not necessarily, but in the default mode that uses WebMercator, yes, it is WGS 84. >...
> So does this mean there is a shift in the proj database for all HARN and whenever that exists I should use the NSRS2007 instead? Sorry, didn't entirely follow...
> is it better to discuss via mailing list or in issues? things that have backward compatibility challenges and affect a presumable significant portion of the users are best discussed...