Re: [gdal-dev] Python code with gdal_calc

https://gdal.org/programs/gdal_calc.html see the examples at the bottom. There are a number of numpy.* statements. On 6/6/24 21:48, lefsky--- via gdal-dev wrote: I know gdal_calc calculates using "python syntax" but I've never seen documentation for using numpy functions within the calc stateme

[gdal-dev] Python code with gdal_calc

I know gdal_calc calculates using "python syntax" but I've never seen documentation for using numpy functions within the calc statement. From my simplistic perspective, allowing numpy functions would make gdal_calc much more powerful without too much additional coding. Or is there something I'm mi

Re: [gdal-dev] get_cli_utility_path_internal

Andrew, obviously this code having essentially passed through the ages since 2008, I don't remember all the details :-) I assume this was an attempt to pick up a binary that could be run and was part of the build tree, instead of a system gdalinfo/etc. binary, but this could likely be simplif

[gdal-dev] get_cli_utility_path_internal

The function in the subject returns a path to a utility on which to run a test. But in the process, it tries to run the utility itself. This seems strange. In my case, the test itself failed, but the code reported "Could not find {file}", which is incorrect. It also causes the actual tests to get s

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

On 6/6/24 8:21 PM, Greg Troxel via gdal-dev wrote: also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 # check compiler and set preferences. if (NOT CMAKE_CXX_STANDARD) set(CMAKE_CXX_STANDARD 17)

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

Le 06/06/2024 à 20:21, Greg Troxel a écrit : also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 set(CMAKE_CXX_STANDARD 17) at https://github.com/OSGeo/gdal/blob/399a0f55d20755120fa49dec36054d2fa8531fbc/CM

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 - fail the build if that does not work with a message that makes it clear that the compiler doesn't work --std=c++17 - if it works, add --std=c++17 to

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

Even Rouault writes: >> which is misplaced, because people are who merely intending to compile >> gdal but not contribute to it, still need to know. I almost didn't even >> look at it before writing that it wasn't documented which C++ flavor is >> needed, because it was obviously not about what

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

which is misplaced, because people are who merely intending to compile gdal but not contribute to it, still need to know. I almost didn't even look at it before writing that it wasn't documented which C++ flavor is needed, because it was obviously not about what I needed to know. Attempt to im

[gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

1) README.md points to build hints (my fault if that's wrong..): https://gdal.org/development/building_from_source.html but really there is crucial information (like that a C++ compiler is required!) at https://gdal.org/development/dev_environment.html which is misplaced, because people are

[gdal-dev] Adding float16 support to GDAL

I am interested in GDAL supporting float16 values (i.e. IEEE 16-bit floating point values) natively. If this suggestion succeeds I will most likely be able to provide such an implementation. I have prepared a draft RFC for this, available as a pull request at