On Wed, Jul 24, 2024 at 8:37 AM Michael Sumner wrote:
> Hi, is there any effort or thought into something like Python's kerchunk
> in GDAL? (my summary of kerchunk is below)
>
> https://github.com/fsspec/kerchunk
>
> I'll be exploring the python outputs in detail and looking for hooks into
> wh
Thanks Joe, will check this out
On Wed, Jul 24, 2024 at 12:30 PM Joe Lee wrote:
> Hi, Michael!
>
> It's an interesting idea since Kerchunk can't handle HDF4 yet [1].
> OPeNDAP DMR++ now can handle HDF4
> so I think Kerchunk can do, too.
>
> For GDAL, is there C++ binding for Kerchunk?
> I think
Hi, Michael!
It's an interesting idea since Kerchunk can't handle HDF4 yet [1].
OPeNDAP DMR++ now can handle HDF4
so I think Kerchunk can do, too.
For GDAL, is there C++ binding for Kerchunk?
I think that will be the main blocker for GDAL driver development.
[1] https://github.com/hyoklee/kerch
Hi, is there any effort or thought into something like Python's kerchunk in
GDAL? (my summary of kerchunk is below)
https://github.com/fsspec/kerchunk
I'll be exploring the python outputs in detail and looking for hooks into
where we might bring some of this tighter into GDAL. This would work
Le 23/07/2024 à 21:08, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
APPLICATIONS INC] a écrit :
Excellent, thanks Even! Do you recall what the runtime was before
these changes on your test system?
I killed the process at about half an hour. Don't recall the progress it
reached, maybe
Excellent, thanks Even! Do you recall what the runtime was before these
changes on your test system?
From: Even Rouault
Date: Tuesday, July 23, 2024 at 3:00 PM
To: Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]
, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
APPLICATION
Hi,
I've got a chance to have a look at your test dataset. In
https://github.com/OSGeo/gdal/pull/10477, I've reduced the runtime to 8
minutes (with GeoParquet output, without spatial sorting), by optimizing
some implementation details. I believe this could be further reduced as
most of the ti
> Could a random user easily check
> out the docs repo and (with 100% open source tooling) generate the
> docs?
Yes, we are currently and would continue to use Sphinx for the
documentation build.
Dan
On Tue, Jul 23, 2024 at 1:18 PM Greg Troxel via gdal-dev
wrote:
>
> Daniel Baston via gdal-de
Le 23/07/2024 à 19:18, Greg Troxel via gdal-dev a écrit :
Daniel Baston via gdal-dev writes:
Hello,
I've put together a configuration to build GDAL's documentation using
ReadTheDocs. As far as I know, this is the simplest way of publishing
version-specific documentation and rending documenta
This is wildly important for systems without internet access.
On 7/23/24 10:18, Greg Troxel via gdal-dev wrote:
In my view, docs should be part of a package build and installed so they
are available on the computer with the software.
___
gdal-dev mail
Daniel Baston via gdal-dev writes:
> Hello,
>
> I've put together a configuration to build GDAL's documentation using
> ReadTheDocs. As far as I know, this is the simplest way of publishing
> version-specific documentation and rending documentation for pull
> requests. A current build of the docu
Hello,
I've put together a configuration to build GDAL's documentation using
ReadTheDocs. As far as I know, this is the simplest way of publishing
version-specific documentation and rending documentation for pull
requests. A current build of the documentation can be viewed at
https://gdal.readthed
Javier,
I've just advertized bilinear.
For average_mp vs average_magphase, they are indeed different code paths.
My understanding of the code is that:
- average_magphase is only available for the complex data types
- for the complex data types, average_magphase makes sure that the norm
of th
Reading carefully https://gdal.org/programs/gdaladdo.html
I saw that the summary mentions
[-r
{nearest|average|rms|gauss|cubic|cubicspline|lanczos|average_mp|average_magphase|mode}]
but later in the options "bilinear" is included. Either it should be in
both or in none.
In addition to that, in t
I found the problem.
As always I has an environment variable pointing to a folder with a release
popler.lib (this environment variable has nothing to do with the GDAL driver I
was trying to compile).
So, all right, thanks!
De: gdal-dev En nombre de Abel Pau via
gdal-dev
Enviado el: divendres,
15 matches
Mail list logo
