If Esri released a new SDK with a changed file format,
would the SDK driver automatically write it, allowing (QGIS)
users to write the new format before OpenFileGDB catches up ?
Hard to speculate about the future and black boxes :-)
Possibly yes, but that seems to be more about theory than p
On Tue, 14 Jan 2025, Even Rouault via gdal-dev wrote:
Hi,
You all know my ever appetite to remove useless code (especially when I have
to do painful exercices such as RFC 105 changes). This time I'd be very well
tempted to axe the write side of the FileGDB driver (the one based on the
Esri S
Actually thinking that there isn't just update, but also pure creation.
2 potential options for that one:
- either just completely remove the Create() implementation of FileGDB.
Slightly backwards incompatible as users will have to change in their
code their "FileGDB" string to "OpenFileGDB"
Hi,
You all know my ever appetite to remove useless code (especially when I
have to do painful exercices such as RFC 105 changes). This time I'd be
very well tempted to axe the write side of the FileGDB driver (the one
based on the Esri SDK). Unless I'm missing something, I don't think it
pro
conda-forge builds, and docker images are now ready:
ghcr.io/osgeo/gdal:alpine-small-3.10.1
ghcr.io/osgeo/gdal:alpine-normal-3.10.1
ghcr.io/osgeo/gdal:ubuntu-small-3.10.1
ghcr.io/osgeo/gdal:ubuntu-full-3.10.1
Even
Le 13/01/2025 à 16:40, Even Rouault via gdal-dev a écrit :
Hi,
O
Hi gdal-group!
Does GDAL_OF_READONLY / GDAL_OF_UPDATE have any impact on performance,
especially when reading common vector files (shp, gpkg, gml)? There is no
recommendation on this in docs.
Best regards,
Michał Kowalczuk
___
gdal-dev mailing list
gdal
Hi
I was able to build the PDFium lib in release mode in Windows from
https://github.com/rouault/pdfium_build_gdal_3_9. My requirement is to build
the PDFium lib in DEBUG mode as well. For that I updated below args in
args_release_win.gn with below argument
is_debug = true # Enable debugging
