Re: [gdal-dev] GPU support for GDAL

Some time ago I did stack the pyramids writing one level per file, naming them .ovr, .ovr.ovr, .ovr.ovr.ovr and so on. I don't know if it would still work On Fri, 8 Nov 2024, 05:53 Pradeep Mahato via gdal-dev, < gdal-dev@lists.osgeo.org> wrote: > HI, >This is my project requirement to use GPU

[gdal-dev] GPU support for GDAL

HI, This is my project requirement to use GPU for pyramid layer generation. I have through for some solution 1. Using GDAL with GPU support => Not possible 2. Used cuda based library to generate the different layers of pyramid and then stack it and make one ".ovr" as GDAL gives In second app

Re: [gdal-dev] Advice on deploying components that use GDAL

Hi Even, Maybe I should be more clear. My java project (built with Maven) has this dependency: org.gdal gdal 3.8.0 So if someone has installed gdal 3.8.x (including the java bindings) my code will work with it. But this seems to imply that if I want to support 3.4.x I need to change the

Re: [gdal-dev] Advice on deploying components that use GDAL

Barry, I'm not totally sure to have the full picture of what you deploy/distribute. I'd assume the main difficulty for the end users of your Java component is to get the GDAL native library, and probably even more tricky, the libgdaljni.so/dll/dylib. If you assume they have managed libgdal it

[gdal-dev] Advice on deploying components that use GDAL

Hey all, I hope this is the right place for this email. I am a developer that has written a java component that interfaces with the java bindings and allows my app users to access gdal data. The problem I have is that gdal seems to release somewhat often. I wrote my code initially for 3.7 but lat

Re: [gdal-dev] GDAL 3.10.0 is released

Docker images are currently cooking and should be ready in one day or so. Now ready: https://github.com/OSGeo/gdal/tree/master/docker#images-of-releases For conda-forge builds, they are suspended to solving a technicality. You can monitor progress at https://github.com/conda-forge/gdal-

Re: [gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

But more importantly... I should have started with saying thank you Erik for working on this RFC for GDAL! On Thu, Nov 7, 2024 at 10:30 AM Kurt Schwehr wrote: > My first pass questions are: > > 1) For folks compiling with C++23*, can they use std::float16_t >

Re: [gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

1) For folks compiling with C++23*, can they use std::float16_t ? Sadly, that's not me yet as my environment is C++20. Letting Erik to comment on this (and also underlying that I'm very satisfied with the quality of the big amount work

Re: [gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

My first pass questions are: 1) For folks compiling with C++23*, can they use std::float16_t ? Sadly, that's not me yet as my environment is C++20. 2) For when C++23 is the minimum language version for GDAL, what is the plan? (*) https://en

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

I vote -1 currently as there hasn't been enough discussion. I just added comments to the RFC PR. On Thu, Nov 7, 2024 at 6:40 AM Erik Schnetter via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > I move to adopt RFC 100 (adding support for the float16 data type). > > The pull request for RFC 100 is

[gdal-dev] lines when combining dems from different sources

I am trying to take several dem sources and merge them together using VRTs, then I am using rio rgbify to make terrainrgb tiles The script I am using looks like https://github.com/acalcutt/terrain_merged/blob/main/create_terrainrgb.sh Basically, I am trying to layer 3 sources -JAXA (full planet bu

[gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

I move to adopt RFC 100 (adding support for the float16 data type). The pull request for RFC 100 is here: https://github.com/OSGeo/gdal/pull/10146 . A candidate implementation is here: https://github.com/OSGeo/gdal/pull/11180 . I vote +1. -erik ___ g

Re: [gdal-dev] Would it be a good idea have a users list?

I would switch to a user's list in "two shakes of a lamb's tail" (I'm not British). The topics discussed in gdal-dev are mostly above my head. And the questions I have don't really fit here. A user's list would probably be a benefit for me. As

Re: [gdal-dev] Would it be a good idea have a users list?

My tuppence worth (yes - a Britishism) just as a user and not a stakeholder ... I would say that the real-life experience is likely to be that no one knows or agrees what message should be on what list, people will post "on the wrong list" and be asked to repost, everyone will end up on both lists