Hello again,
This is just a quick note to follow up on my many questions over the past few
days.
I have successfully built GDAL 3.5 for iOS, and I have fully documented the
procedure I used at:
https://gis.stackexchange.com/questions/434514/build-gdal-3-x-for-ios/435316#435316
Note t
Thanks Even,
After applying the patch and then running the ‘cmake' and 'cmake —build' again,
it stops at the same point but produces much fewer errors (and I have found a
dodgy work-around those - see below). Only two errors this time, both for the
same file:
==
[ 6%] Building CXX ob
Luisa,
the answer is a mixed yes/no
The implementation of the CreateDimension() method in the netCDF
supports a UNLIMITED creation option. Cf
https://github.com/OSGeo/gdal/blob/664fae6ed14d77501c4f0a796f0fb371bae3bf3e/autotest/gdrivers/netcdf_multidim.py#L586
to instruct it to be created as s
Hi,
i am interested in using GDAL for writing a multi-dimensional array in a NetCDF file.
Is it possible in GDAL to create a dimension (time in my case) without knowing/ restricting the size of it at the beginning?
I would like to create a MDArray with first only one timestep and then expand this
On Tue, Jul 5, 2022 at 1:30 AM Javier Jimenez Shaw
wrote:
> Hi
>
> Do you know if there is any performance comparison between gdal2tiles and
> COG?
>
> To display our geotiffs we are currently running gdal2tiles and storing
> the (gazillion) tiles in Amazon S3. Then a webpage with openlayers is
>
Even Rouault writes:
> That's what we do already what we do for a few functions (like fopen64
> vs fopen): cf
> https://github.com/OSGeo/gdal/blob/1e3cc18e298e81c1f42162b10ef7beb0dd94d3cf/cmake/helpers/configure.cmake#L230
>
> But for some reason, in that circumstance, it seems it detects symbol
have viewed "large file support" as a linux and solaris thing only.
This is probably a bigger rototill than anyone has appetite for, but I
wonder if there should basically be a configure test to look for foo64
(by the equivalent of AC_TRY_COMPILE) and if so use it,a nd if not just
use the norm
Even Rouault writes:
> Can you try the following patch which basically forces to remap all
> "foo64" functions to "foo". I assume that iOS Unix I/O is 64-bit
> enabled by default...
I would expect it is. The BSD world changed the ttype of size_t, off_t
to 64 bits a really long time ago and in
Hi Even,
Thanks again for your advice. The debug message did produce what I believe
was the expected output as follows:
CMake Warning at cmake/helpers/configure.cmake:175 (message):
CMAKE_SYSTEM_NAME=iOS
Making the suggested change to the configure.cmake file (line 175 in the
version 3.5 d
(re-adding the list)
ok, it's a bit weird CMake detects symbols that are not available at
build time, but there might be some subtelties in iOS SDK
Can you try the following patch which basically forces to remap all
"foo64" functions to "foo". I assume that iOS Unix I/O is 64-bit enabled
by
Hi
Do you know if there is any performance comparison between gdal2tiles and
COG?
To display our geotiffs we are currently running gdal2tiles and storing the
(gazillion) tiles in Amazon S3. Then a webpage with openlayers is showing
them in WebMercator.
We are considering moving to make a COG file
Nik,
in cmake/helpers/configure.cmake, there's a special case of Darwin at
line 183 in master
if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
Can you test if replacing it with
if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR ${CMAKE_SYSTEM_NAME}
MATCHES "iOS")
works better? (I assume CMAKE_SYS
12 matches
Mail list logo
