Hi GDAL devs,
As per my earlier emails, I’m attempting to build GDAL 3.5 for iOS. The
complete process (so far) for this is below, at the end of this email.
A quick summary of some relevant points is:
• Using a 3rd party cmake toolchain file which caters for iOS, macOS (as well
as other Apple
Nik,
In another message you indicated that your ultimate goal was an iOS build. You
also said this a few days ago, but I missed it:
On Jul 1, 2022, at 3:58 AM, Nik Sands wrote:
My ultimate aim is to build GDAL 3.6 (not yet released) for iOS on ARM (as well
as for macOS on Intel). I can then c
Without comment on whether any way is correct - I believe this is the
definitive source for how CMAKE approaches the subject :
https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling
On Mon, 4 Jul 2022 at 13:47, Greg Troxel wrote:
>
> Even Rouault writes:
>
> > Le 04/07/202
You are right, Even
Sorry for the confusion !
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Even Rouault writes:
> Le 04/07/2022 à 07:32, Brad Hards a écrit :
>> On Monday, 4 July 2022 3:19:55 PM AEST Nik Sands wrote:
>>> Is it expected that these GDAL utilities (such as gdalinfo) would look for
>>> GDAL in /usr/lib instead of the location in which it was actually built?
>> No.
>>
>> I
Christophe,
CPL_MULTIPROC_WIN32 is automatically set on Windows by
https://github.com/OSGeo/gdal/blob/104e1747748d204e8aff1945464a24b1f8c94c90/port/cpl_multiproc.h#L43
Even
Le 04/07/2022 à 11:57, DELEPINE Christophe a écrit :
Hi Even
I have looked at cpl_multiproc.cpp implementation and I b
Hi Even
I have looked at cpl_multiproc.cpp implementation and I believe that I cannot
use multithreading for the mbtiles conversion (even if I define
GDAL_NUM_THREADS)
The compilation of cpl_multiproc.cpp depends on several compilation flags :
·CPL_MULTIPROC_STUB
·CPL_MULT
That seems to be something wrong in the algorithm or configuration, as it
is not "ignoring" the pixels with nodata value.
Could you dump the output of "gdalinfo" of the original file, and the exact
command line you are using with gdalwarp ?
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._
Le 04/07/2022 à 07:32, Brad Hards a écrit :
On Monday, 4 July 2022 3:19:55 PM AEST Nik Sands wrote:
Is it expected that these GDAL utilities (such as gdalinfo) would look for
GDAL in /usr/lib instead of the location in which it was actually built?
No.
I think your conceptual problem is expect
Hi All,
Thanks for your comments. I replaced the no data value (which previously was
-200) with zero and then it all seemed to work!
Best wishes,
Ainslie
> On 1 Jul 2022, at 20:39, Andrew C Aitchison wrote:
>
> On Fri, 1 Jul 2022, Ainslie Johnstone wrote:
>
>> Hi there,
>>
>> I am trying
Hi,
When I use gdalinfo get info of a hdf file downloaded from MODIS on mac, it
returns:
% gdalinfo MOD17A2H.A2020001.h29v11.006.2020010231909.hdf
ERROR 4: `MOD17A2H.A2020001.h29v11.006.2020010231909.hdf' not recognized as
a supported file format.
gdalinfo failed - unable to open
'MOD17A2H.A202
11 matches
Mail list logo
