Hi,
Depending on what you need, I've found using VCPKG (https://vcpkg.io/en/)
can make it straightforward to address the dependencies *of* GDAL, and it's
all driven by CMake underneath, like GDAL's builds. Importantly, it is well
tested and supported on Windows. That means you end up spending your
On Mon, 18 Nov 2024 at 23:20, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> Le 19/11/2024 à 00:15, Scott via gdal-dev a écrit :
> > Question,
> >
> > Is there any plan to incorporate the python utilities, such as,
> > gdal_calc?
>
> Cf
>
> https://gdal--11216.org.readthedocs.bui
Hi,
On Mon, 14 Oct 2024 at 15:27, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> So probably the most sane solution would be
> to have a dynamic library libgdal.so that statically links its
> dependencies, but with all GDAL public symbols renamed. Quite an
> adventure...
It woul
Hi Michał,
In addition to Jukka's key point:
nBufXSize=1,
nBufYSize=691,
appears to be backwards wrt:
-outsize 691 1
Rob :)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
On Wed, 24 Jul 2024 at 12:27, Even Rouault
wrote:
>
>
> Le 24/07/2024 à 12:33, Javier Jimenez Shaw via gdal-dev a écrit :
>
>> I see the point, and I agree... but I don't know if it will work
>> RTD redirects to whatever we configure. In proj.org it is going directly
to 9.4 (current latest release
Hi Dan,
On Tue, 23 Jul 2024 at 17:16, Daniel Baston via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> If anyone has feedback about using ReadTheDocs for this project, or
> the specifics of the proposed configuration, please share it here or
> as a comment on the pull request.
>
My only suggest
Hi,
On Tue, 25 Jun 2024 at 21:11, Michał Kowalczuk via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> First of all, the dwg format is only available in gdal if you buy ODA SDK
> which is very expensive.
>
There is also an in-house-use license available for ODA
https://www.opendesign.com/pricing/i
Hi,
On Wed, 28 Feb 2024 at 09:51, Michael Otto
wrote:
> Under all distributions there were problems with the certificates when
> using ogrinfo.
>
> ERROR 1: error setting certificate file: /etc/ssl/certs/ca-certificates.crt
> ERROR 1: Error returned by server : error setting certificate file:
>
Hi Michael,
On Tue, 27 Feb 2024 at 11:40, Michael Otto via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> with a lot of effort and support from this group I created a first static
> version of GDAL (incl. the apps) under Linux x64 using vcpkg.
Yay
> For testing I copied the built apps and th
Hi,
On Wed, 21 Feb 2024 at 11:18, Michael Otto
wrote:
>
> I've also tried the problem with libtiff, but couldn't solve it. Thanks
> for the tip!
With "gdal[core,tools]" the apps are now static.
Excellent.
> BUT I want to use exactly what is still causing problems: SQLite for the
> creatio
Hi,
On Tue, 20 Feb 2024 at 21:44, Robert Coup
wrote:
> Hi Simon,
>
> On Tue, 20 Feb 2024 at 21:11, Simon Eves wrote:
>
>> Here's the stack trace for the original assert. Something is stepping on
>> scratch_ to make it 0x10 instead of null, which it starts out as
>> when the flatbuffer o
Hi Simon,
On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> We still have one VERY strange issue whereby FlatGeoBuf export fails in a
> very consistent and reproducible form down in the flatbuffer code, but only
> in the static build, and only in the full
Hi,
On Tue, 20 Feb 2024 at 12:50, Michael Otto
wrote:
>
> I have now tried it with 'vcpkg install gdal[tools]'. The tools/apps are
> there, but they are not statically linked!
>
> See for example gdalinfo:
>
> root@vmuser-VirtualBox:/home/vmuser/Git/vcpkg/installed/x64-linux/tools/gdal#
> ldd gd
Hi Michael,
On Tue, 20 Feb 2024 at 11:22, Michael Otto
wrote:
> The directory './vcpkg/packages/_x64-linux' now contains the
> compiled static versions of the libraries. But where can I find the GDAL
> apps? These are not contained in this directory.
Great! So if you change your vcpkg installa
Hi Michael,
On Tue, 13 Feb 2024 at 07:18, Michael Otto
wrote:
> at the moment it's only about the Linux platform. And yes, it should be a
> static compilation with all the necessary dependencies (including libtiff
> and all the others).
>
> I currently use an Ubuntu VM and use an Alpine-Linux Do
Hi Michael,
On Mon, 12 Feb 2024 at 12:02, Michael Otto via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> The goal is to cast GDAL and all its dependencies (PROJ / GEOS / all
> dependencies to system libraries / ...) into a static library and to create
> the GDAL apps as static executable progra
On Wed, 24 Jan 2024 at 02:27, Even Rouault wrote:
>
> https://github.com/OSGeo/gdal/pull/9128 should do what you wish. As
> usual, the hardest part is the naming of options...
Wow! I'll try and review it in the next few days.
Rob :)
___
gdal-dev mailin
Hi Even,
Thanks for your reply!
On Fri, 19 Jan 2024 at 17:32, Even Rouault
wrote:
> I can't think an easy way of doing what you want.
>
Is there a functional gap? *Conceptually* it feels to me like
VRTRasterBand.ComplexSource.UseMaskBand should "mark" a pixel to be
nodata-equivalent (NaN?), an
Maybe it's just Friday, but I could use a pointer here :-)
My input raster is a RGBA byte image, where the alpha channel value is 0 or
255 (ie: effectively a mask). The output is ideally a VRT file, RGB with
Int16 data type, using nodata=-1.
So I want to convert the alpha channel to a nodata valu
Hi Sean
On Thu, 16 Nov 2023 at 12:10, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> >
> > I think this makes great sense for the project. I don't yet understand
> > what it means for an enterprise like Rasterio's PyPI wheels.
>
> I'd say it probably changes nothing. The RFC just
Hi Even,
On Thu, 2 Nov 2023 at 11:59, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
>
> I'm seeking for feedback and review on a new RFC (RFC 96: Deferred
> in-tree C++ plugin loading), detailed in
> https://github.com/OSGeo/gdal/pull/8648, whose summary is:
>
> This RFC adds a mec
Hi Joaquim,
There have been other similar changes... for example, GDAL added an
aspatial extension[1] to GeoPackage v1.0 to support non-geo tables... the
GeoPackage standard added support for such tables in v1.2; so our extension
is no longer needed: GDAL still reads it, but no longer writes it [2
22 matches
Mail list logo
