Hi,
Follow-up release of 1.7.2 to address a regression with CMake builds
related to a typo in CMAKE_INSTALL_BINDIR install target that affects
location of geotiff.dll (#117)
Source packages can be found at:
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.3.tar.gz
Hi,
Source packages can be found at:
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2.tar.gz
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2.zip
News is:
* GTIFGetDatumInfoEx(): handle dynamic datums
* CMake: adopt GNUInstallDirs
* CMake: export TIFF as a public
Le 22/05/2024 à 16:59, Greg Troxel a écrit :
I got 3.5 to work, so I'm focusing on the 3.9 upgrade. It seems that
3.9, vs 3.5, has withdrawn the swig generated files from the distfile.
With 3.9, you could also do a more manual approach (not sure the
python_generated_files target is
Greg,
If the build requirements for the Python bindings are met (python + swig
available), then a "make && make install" cycle will build and install
libgdal and the python bindings, like it did in autoconf era. The CMake
build target "python_binding" has libgdal as a dependency.
The idea
oops. Here are the corrected URLs:
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.tar.gz
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.zip
Le 21/05/2024 à 15:44, Greg Troxel via Geotiff a écrit :
Even Rouault via Geotiff writes:
do you mean
https
Hi,
I've prepared a libgeotiff 1.7.2 release candidate.
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.tar.gz
https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.zip
I'll promote it to final later this week if nothing serious is reported
on it before.
News
As suggested in the comment of #939, attempting
https://github.com/rouault/gdal/commit/1000cfaa950a18bd14b0c72109439cad58c789d5
That fixed it. Merged into master
--
http://www.spatialys.com
My software is free, but my time generally not.
___
It looks like the numpy 2.0 update was pushed to the gdal-feedstock
https://github.com/conda-forge/gdal-feedstock/pull/939 (looking like
GDAL must also build and test clean against Numpy 2.0 at this point too).
The error is the Conda builder complaining that it can't find Numpy
2.0 because
Andrew,
Data type conversion is done by GDALCopyWords[64]:
https://gdal.org/api/raster_c_api.html#_CPPv415GDALCopyWords64PKv12GDALDataTypeiPv12GDALDataTypei10GPtrDiff_t
The doc was a bit outdated, regarding conversion from floating point
data types to integer data types. I've just adjusted
Le 14/05/2024 à 17:30, Matteo Ghetta via gdal-dev a écrit :
Hi all,
I've a geopackage with many layers (in the following example let's
pretend just 2) that I want to import in a single transaction
(important!) into a PG database.
GPKG and PG table names are the same, but it can happen that
Le 14/05/2024 à 18:08, Liyuneh Gebre a écrit :
hi,
thanks for your kind commitment. I tried the docker version and
unfortunately it shows the same result.
That's expected. The fix has been done post 3.9.0. This will be
available in 3.9.1
On Sun, May 12, 2024 at 4:02 PM Even Rouault
Hi,
The GDAL 3.9.0 Docker images are available:
* ghcr.io/osgeo/gdal:alpine-small-3.9.0
* ghcr.io/osgeo/gdal:alpine-normal-3.9.0
* ghcr.io/osgeo/gdal:ubuntu-small-3.9.0
* ghcr.io/osgeo/gdal:ubuntu-full-3.9.0
Even
Le 10/05/2024 à 16:10, Even Rouault via gdal-dev a écrit :
Hi,
On behalf
Hi,
fix in https://github.com/OSGeo/gdal/pull/9909
Le 12/05/2024 à 12:06, Javier Jimenez Shaw via gdal-dev a écrit :
I do not know if there is any documentation from esri about that
specific format for LAMBERT_AZIMUTHAL. It would be great.
And also I am surprised that in 13 years nobody
Hi,
On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 3.9.0. GDAL/OGR is a C++ geospatial data
access library for raster and vector file formats, databases and web
services.
It includes bindings for several languages, and a variety of
Motion passed with +1 from PSC members EvenR, JukkaR and JavierJS
Le 08/05/2024 à 13:13, Even Rouault via gdal-dev a écrit :
Hi,
Motion:
Adopt GDAL 3.9.0RC2 as final 3.9.0 release
Starting with my +1
Even
--
http://www.spatialys.com
My software is free, but my time generally
Andrew,
this is now fixed per
https://github.com/OSGeo/gdal/commit/393eee77b40ae16751e4d2c0ad3e53386b22d025
. Doxygen apparently takes the function/method at declaration time, and
not definition time, and we had a number of unnamed parameters in
declarations. (I also struggled with weird
Jesse,
the answer lies in exploring available Spatialite SQL functions:
https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.html
ST_Centroid() returns a Point geometry. You may get its coordinates with
ST_X() and ST_Y(). I suppose you'd need to use a sub-select construct to
get things
Hi,
Motion:
Adopt GDAL 3.9.0RC2 as final 3.9.0 release
Starting with my +1
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
/gdal/3.9.0/gdal390rc2.zip
https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0rc2.tar.gz
https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0rc2.zip
Even
Le 06/05/2024 à 15:43, Even Rouault via gdal-dev a écrit :
Hi,
I have prepared a GDAL/OGR 3.9.0 release candidate.
NEWS
Hi Andrew,
no, there's no such support in GDAL itself. That could potentially be
done using VRT and pixel functions, but I'm not sure that would qualify
as "optimal", and that would require a bit of setup. You're probably
better instantiating your for(y: ...) for (x: ...) loop manually with
Hi,
I have prepared a GDAL/OGR 3.9.0 release candidate.
NEWS at:
https://github.com/OSGeo/gdal/blob/v3.9.0RC1/NEWS.md
Pick up an archive among the following ones (by ascending size):
https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0rc1.tar.xz
int and just the mid point between the extremes. If that
different is bigger than an certain threshold, keep subdividing
each side. With that you have a good approximation of the borders
of the image transformed, and then you can compute your bounding box.
The idea is not mine. Even Roua
/gdal:alpine-small-3.9.0beta2
Even
Le 29/04/2024 à 14:26, Even Rouault via gdal-dev a écrit :
Hi,
I've prepared a beta2 of GDAL 3.9.0 as there have been a few
non-trivial changes since beta1
The major ones are:
* pyproject.toml: use numpy>=2.0.0rc1 for python >=3.9 (#9751)
* Docker: update
ng extension .so links against the expected libgdal?
Even
Le 30/04/2024 à 17:41, Andrew Bell a écrit :
On Tue, Apr 30, 2024 at 9:18 AM Even Rouault
wrote:
Even,
Also try in a Python interpreter "from osgeo import gdal" to see
if the exception is more verbose. If y
ht the file _gdal.cpython-312-darwin.so
<http://gdal.cpython-312-darwin.so> would have been found and loaded,
but my expertise in this is limited. I tried tracing with
PYTHONVERBOSE set, but the only references to _gdal I saw were in the
same error message quoted above.
Thanks for any help,
Hi,
oh well, so this i actually a HDF5 file using netCDF conventions, but
likely created with the HDF5 API itself. Per se, this isn't the issue,
as you've figured it, we can convince the netCDF driver to open it. The
lack of CRS comes from the fact that the land_mask_map variable has this
ed in the link. yes, it's
geocentric and for further exploration the custom project
transformation file .gtf extension is also included.
https://u.pcloud.link/publink/show?code=kZj5wh0ZtFWXtI9UGjQiD6KXxn5A9hiWDpEX
On Mon, Apr 29, 2024 at 4:23 PM Even Rouault
wrote:
Hi,
it is
Andrew,
Perhaps you're running updated GDAL Python bindings against a libgdal
that hasn't been rebuilt recently? OSRIsDerivedProjected() has been
added recently both in libgdal and the bindings
Even
Le 29/04/2024 à 23:27, Andrew Bell via gdal-dev a écrit :
Hi,
I just merged master into my
Michael,
actually support for those products was already there at 95% since they
use the HDF5EOS GRID formalism which we support since 3.7. But that
particular type of products has an oddity. They have an empty
GROUP=Dimension within the GROUP=GridStructure in the HDF5EOS metadata,
which our
Hi,
Something like:
from osgeo import ogr
original_field_names = [ "toolongforshapefile1", "toolongforshapefile2"]
map_to_shp = {}
tmpfilename = "/vsimem/temp.shp"
ds = ogr.GetDriverByName("ESRI Shapefile").CreateDataSource(tmpfilename)
lyr = ds.CreateLayer("temp")
lyr_defn =
Hi,
it is difficult to help you with just the elements you've provided.
What could be helpful is:
- the output of gdalinfo on the input file
- the output of gdalinfo on the output file generate by ArcPy
- how you define the target projection in ArcPy
- the output of gdalinfo on the output
Hi,
I've prepared a beta2 of GDAL 3.9.0 as there have been a few non-trivial
changes since beta1
The major ones are:
* pyproject.toml: use numpy>=2.0.0rc1 for python >=3.9 (#9751)
* Docker: update ubuntu-small and ubuntu-full to 24.04
* TileDB: migrate away from deprecated APIs, and bump
Michael,
The Python doc got reorganized one month ago
(https://github.com/OSGeo/gdal/pull/9575), so perhaps Google hasn't
updated yet the new references
If you look for gdal.warp on gdal.org directly :
https://gdal.org/search.html?q=gdal.warp_keywords=yes=default
that leads to
yes, GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR is the trick to both disable
directory listing and preventing individual file probing.
Javier, do you have GDAL_DISABLE_READDIR_ON_OPEN=YES also set? Otherwise
if GDAL_DISABLE_READDIR_ON_OPEN is not set, GDAL will normally issue a
S3 directory
Hi,
you can try something kike ogrinfo /vsizip/your.kmz/your.kml
Even
Le 25/04/2024 à 14:32, Johannes Paul via gdal-dev a écrit :
Hello,
using GDAL 3.8.3 compiled with libkml, I'm unable to read a specific
KMZ file, using ogrinfo (error "unable to open datasource ...")
However if I extract
Le 25/04/2024 à 00:39, Andrew C Aitchison via gdal-dev a écrit :
On Wed, 24 Apr 2024, Even Rouault via gdal-dev wrote:
A future TileDB version will remove various deprecated API that the
GDAL TileDB driver currently uses.
https://github.com/OSGeo/gdal/pull/9725 migrates away from those
Hi,
A future TileDB version will remove various deprecated API that the GDAL
TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725
migrates away from those deprecated APIs, but that causes the minimum
requirement from TileDB to go from 2.7 to 2.15. It would probably be
wise
.
On Wed, Apr 24, 2024 at 8:51 PM Even Rouault via gdal-dev
wrote:
Hi,
I guess this discussion, and past similar ones, calls for an
enhancement. A new API function, like CPLErr
GDALRasterInterpolateAtPoint(GDALRasterBandH, double dfPixel,
double dfLocation, GDALRIOResamp
Hi,
I guess this discussion, and past similar ones, calls for an
enhancement. A new API function, like CPLErr
GDALRasterInterpolateAtPoint(GDALRasterBandH, double dfPixel, double
dfLocation, GDALRIOResampleAlg eInterpolation, double *pdfValue), that
could be used by a new mode of
The Docker images are now available:
ghcr.io/osgeo/gdal:alpine-small-3.9.0beta1
ghcr.io/osgeo/gdal:ubuntu-small-3.9.0beta1
ghcr.io/osgeo/gdal:alpine-normal-3.9.0beta1
ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1
Le 22/04/2024 à 14:12, Even Rouault via gdal-dev a écrit :
Hi,
I've prepared a beta1
er targets
Even
Le 22/04/2024 à 23:28, Holger Jaekel via gdal-dev a écrit :
Hi Even,
Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
I tried to build on Alpine Linux Edge and got the following error:
/buil
Even Rouault via
gdal-dev
Enviado el: dilluns, 22 d’abril de 2024 14:13
Para: gdal-dev@lists.osgeo.org
Asunto: [gdal-dev] GDAL 3.9.0beta1 available for testing
Hi,
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
The NEWS file is here:
https://github.com/OSGeo/gdal
Sean,
Rasterio's test suite has 4 errors with GDAL 3.9.0beta1.
Metadata output of gdalinfo has changed.
ok, I've run locally rasterio tests and I see gdalinfo now outputs:
Metadata:
a=1
b=2
AREA_OR_POINT=Area
whereas the test expects
Metadata:
a=1
AREA_OR_POINT=Area
b=2
Order
usually stick to LINUX OSes.
Or is at easy as following the notes here:
https://gdal.org/development/dev_environment.html
Ubuntu 22.x is the goto right now.
Any advice would be appreciated.
Rob
On Mon, Apr 22, 2024 at 5:12 AM Even Rouault via gdal-dev
wrote:
Hi,
I've prepared
Hi,
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
The NEWS file is here:
https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md
For packagers,
https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may
make it more attractive to build some drivers
based reading" ? I just meant that calling IRasterIO() on a
GDALDataset/GDALRasterBand doesn't necessarily cause the block cache to
trigger. This is dependent of the driver and the parameters of the
request. And this isn't specific to use it from a VRT.
On Fri, Apr 19, 2024 at 9:09 AM Ev
Sean,
Within a given GDALDataset opened on a VRT, if the VRT references
several times the same source, only one GDALDataset will be opened for
it, so you may benefit from the block cache mechanism (if it is
triggered. VRTSource::IRasterIO() calls IRasterIO() on the source band,
which doesn't
Hi,
I can't imagine this is a bug that was never noticed before.
Why? If everybody followed that reasoning nobody will report and hardly
any bug would be fixed. (and there are a number of known bugs that
nobody has had time to fix either)
So I assume I'm doing something wrong. But I can't
Le 19/04/2024 à 10:25, Matteo Ghetta via gdal-dev a écrit :
Hi all,
I'm trying to export a PG table with several foreign keys to a
geopackage.
What I tried so far are the native QGIS export and the QGIS Processing
algorithm "Package layer" with the "Export related layers
following..."
ok, I believe I've now a fix in https://github.com/OSGeo/gdal/pull/9700
. Probably a subtle multi-threading issue related to different memory
ordering between M1 and Intel CPUs (or just that it was easier to
trigger on M1)
Le 16/04/2024 à 21:01, Even Rouault via gdal-dev a écrit :
Hi,
I've
Le 18/04/2024 à 23:54, Andrew C Aitchison via gdal-dev a écrit :
On Thu, 18 Apr 2024, Even Rouault via gdal-dev wrote:
I'm proposing in https://github.com/OSGeo/gdal/pull/9693 that we add
a CI "stale" workflow for pull requests without activity. It is
mostly a copy from QGIS simila
Hi,
I'm proposing in https://github.com/OSGeo/gdal/pull/9693 that we add a
CI "stale" workflow for pull requests without activity. It is mostly a
copy from QGIS similar workflow with the following changes:
- restrict the scope to pull requests only and not tickets (although we
could
Hi,
I haven't done myself that exercice but I know that computing RPC values
that are stable enough might be challenging, so perhaps the issue is
related to that
A few other remarks:
- your gdalwarp command line refers to RPC_DEM_SRS and
RPC_DEM_MISSING_VALUE but doesn't include a
Hi,
This is described in https://gdal.org/development/rfc/rfc8_devguide.html
. I've submitted https://github.com/OSGeo/gdal/pull/9689 so it is going
to be linked to
https://gdal.org/development/dev_practices.html#making-changes-to-gdal
I'd probably agree that at my beginnings in GDAL, I
Hi,
I've investigated that today, and I can quite reliably trigger a similar
error with our existing tests on CI, but this is impossible to diagnose
further without direct access to a machine where the error triggers
(when simulating taking the the error code path on Linux, the fallback
code
Andrew,
some hints at
https://stackoverflow.com/questions/44382862/how-to-printf-a-size-t-without-warning-in-mingw-w64-gcc-7-1
Otherwise an alternative is to cast to uint64_t and use PRIu64
Even
Le 15/04/2024 à 19:49, Andrew C Aitchison via gdal-dev a écrit :
I am trying to print a size_t
The following fails if GDAL_DATA is incorrect:
srs = osr.SpatialReference()
srs.SetStatePlane(403, 1) # California III NAD83.
Le 15/04/2024 à 14:26, Paul Harwood via gdal-dev a écrit :
I have an interesting little problem.
I want to write (in the code using the API - not as a
Hi,
here's the updated proposed 3.9 release schedule
- Monday April 22: feature freeze, creation of release/3.9 branch and
issue a 3.9.0beta1
- Monday May 6th: issue of 3.9.0rc1
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
Hi Michael,
I can't think of a better way with the current API.
There has been some work in progress in
https://github.com/OSGeo/gdal/pull/8222 to make VSIFile accessible as a
regular Python file, but this isn't merged
Even
Le 15/04/2024 à 01:48, Michael Sumner via gdal-dev a écrit :
Hi,
Stephen,
there are 2 possiblities:
- you may reuse your modified /usr/share/proj/epsg file from PROJ.4. But
in this case, the EPSG entries of proj.db will not be used, so you will
use only legacy CRS and transformations
- or you add a custom entry in proj.db
For the later, the following
The corresponding Docker images are now available:
https://github.com/OSGeo/gdal/tree/master/docker#images-of-releases
Le 04/04/2024 à 19:58, Even Rouault via gdal-dev a écrit :
Hi,
On behalf of the GDAL/OGR development team, I am pleased to announce
the release of the GDAL/OGR 3.8.5 bug fix
Hi,
On behalf of the GDAL/OGR development team, I am pleased to announce the
release of the GDAL/OGR 3.8.5 bug fix version. This is the last one
planned in the 3.8.x series, with the forthcoming 3.9.0 released planned
for the beginning of May.
Consult the release notes for the list of
Hi,
motion passed with +1 from PSC members EvenR, JukkaR, HowardB and JavierJS
Even
Le 02/04/2024 à 12:16, Even Rouault via gdal-dev a écrit :
Hi,
I have prepared a GDAL/OGR 3.8.5 release candidate. This is likely to
be the
last bug fix release in the 3.8.x series, with 3.9.0 coming
Hi,
GDAL_HTTP_AUTH=BEARER support has been added in master / GDAL 3.9dev
only (I've just fixed an erroneous statement about it being in 3.8)
In earlier versions, you can try setting
GDAL_HTTP_HEADERS="Authentication: Bearer {your_token_here}"
Even
Le 04/04/2024 à 15:40, Michael Otto via
Hi,
Not that I've a strong opinion on what GeoZarr/XArray should do, but yes
1D coordinate arrays are a bit of a pain to deal with, when they
actually just encode a regularly spaced grid. This is something I've hit
in the bridge between the GDAL multidimensional API (roughly netCDF
based)
Hi,
I've given this a crack at https://github.com/OSGeo/gdal/pull/9609
The newly introduced LAUNDER option for GeoPackage is indeed quite
"extreme" compared to the existing ones, hence I've defaulted it to NO.
I've also added a LAUNDER_ASCII option to PG/PGDump to do something
similar to
Hi Jukka,
I've realized this behaviour was actually documented in
https://gdal.org/drivers/raster/gtiff.html#overviews-and-nodata-masks :
"Internal overviews, external nodata mask: when running BuildOverviews()
in update mode on the .tif file, only the overviews of the main bands
will be
Hi,
I have prepared a GDAL/OGR 3.8.5 release candidate. This is likely to be the
last bug fix release in the 3.8.x series, with 3.9.0 coming beginning of
May.
Pick up an archive among the following ones (by ascending size):
https://download.osgeo.org/gdal/3.8.5/gdal-3.8.5rc1.tar.xz
Michael,
Warning 1: The dataset has several variables that could be identified
as vector fields, but not all share the same primary dimension.
Consequently they will be ignored.
Yes, the driver is super conservative/picky when trying to recognize a
netCDF file as a vector layer, and its
Hi,
TLDR: no specific reason to worry.
My longer analysis:
Those following the recent security news have certainly come across
https://lwn.net/Articles/967180 or similar articles, and if you don't
have and have been running a cutting edge Linux distribution recently,
you *should* follow
This might be tricky, because JPEG2000 itself has a concept of a image
space origin which is not necessarily (0,0) with the (XOSiz, YOSiz)
fields of the SIZ marker, although most of the time it is 0,0. I don't
remember how the GDAL JPEG2000 drivers behave regarding that, if they
ignore it
Just added in
https://github.com/OSGeo/gdal/commit/a6c3b0450994028a60cef854fbe6304910c7e277
: "The content of the
file is not cached, and thus it is read again before issuing each HTTP
request."
Le 28/03/2024 à 10:26, Michael Otto via gdal-dev a écrit :
Hello,
I have an important question
Salut Thomas,
There's a tension between being clear to users, and also aiming at being
concise / not repeating us too much (we have already one thousand pages
of doc to maintain), and if we need to repeat, find the technical way of
doing it without actually having to copy the same text.
Yes, some versions ago the netCDF driver became much more stricter,
expecting a strict respect of the netCDF CF conventions for axis names &
attributes, to avoid false identification of non-georeferenced axis,
which could cause issues.
The below debug message gives a hint to use the
Hi,
It is very difficult to create manually the table & field structure that
will be generated by the GMLAS driver. It is likely that the attribute
name generated by the GMLAs driver is not the one you expect. First try
ogr2ogr to a not-yet-existing PotsgreSQL table to see if data is
t;
The three files there are the following:
1. A bad tiff (this is slightly smaller; they are all pretty big).
2. A GDAL info dump (survey feet is almost at the bottom)
3. A PDF with an explanation of the issue
thanks for your help.
Conrad
On Thursday, March 21, 2024 at 04:49:57 PM EDT
Le 21/03/2024 à 21:45, Conrad Bielski via gdal-dev a écrit :
Hello GDALers,
I have a question about reading USGS 3DEP (3D Elevation Program) data.
Inside of this data, a GEOTIFF tag 42114 is provided which is causing
problems with datum shifts.
There's no such thing as a GEOTIFF tag 42114.
hat sometimes I have to use GDAL code
that doesn’t take it in consideration (CPLRecode()for instance).
Perhaps it could be improves as well.
Thanks for noticing that.
*De:*gdal-dev *En nombre de *Javier
Jimenez Shaw via gdal-dev
*Enviado el:* dijous, 21 de març de 2024 8:27
*Para:* Even Rou
Philippe,
I guess, I did not initialize POPPLER_EXTRA_LIBRARIES:
* is its type STRING ?
Yes
* what separator should I use between library name ?
Semicolon ';'
I see this was added per
https://github.com/OSGeo/gdal/commit/95ee1f855cd and
Hi,
while investigating
https://github.com/OSGeo/gdal/issues/9510#issuecomment-2010950408, I've
come to the conclusion that the Windows heap allocation mechanism sucks.
Basically if you allocate a lot of heap regions of modest size with
malloc()/new[], the time spent when freeing them all
Le 21/03/2024 à 01:43, Michael Sumner a écrit :
> And, can index be *value* in any contexts?
If you use a raster with a signed data type, that could be negative
values (assuming I understand your question)
ah I see, arbitrary integer values map to a colour 0:(n-1) colours,
Le 20/03/2024 à 23:11, Fengting Chen a écrit :
After upgrading setuptools, the installation on windows worked. Just
curious that why “GDAL-3.8.4-py3.6.egg-info” is created under the
site-packages on windows, while I set up the PYTHON_ROOT to use python
3.12 and clean up the build directory
Michael,
Le 20/03/2024 à 21:38, Michael Sumner via gdal-dev a écrit :
Is the palette_file .txt format documented?
https://gdal.org/programs/gdalattachpct.html
It's mentioned in a few utilities, and created by tests but I couldn't
find an existing example or a description (I guessed,
Hi,
assuming you use a Unix shell, and using the fact that the content of
the VRT itself can be used as the datasource name, you can just do:
gdalinfo "$(sed 's/foo/bar/' my.vrt)"
Even
Le 20/03/2024 à 17:24, Scott via gdal-dev a écrit :
It would be nice to have an open option to substitute
Hi,
FYI, for those interested in GeoParquet,
https://github.com/OSGeo/gdal/pull/9185 has now been merged into master.
This is only effective on files generated with the updated driver that
adds a bounding box column, and maximum efficiency is reached when
sorting the features with the
engting Chen a écrit :
Thanks for the suggestion. I can upgrade the setuptools and try again.
Another question: is it possible to only build a specific driver
plugin without rebuilding the GDAL?
*From: *Even Rouault
*Date: *Tuesday, March 19, 2024 at 4:44 PM
*To: *Fengting Chen ,
gdal
Michael,
Hi, can we specify overview sizes exactly?
No, the BuildOverviews() interface onlys take an array of overview
factors. It is up to the driver implementation to decide how it computes
the overview size from the main raster size and overview factor.
The COG driver is a bit of a
Le 19/03/2024 à 22:56, Rahkonen Jukka via gdal-dev a écrit :
Hi,
I suppose that something similar than with gdalwarp
https://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSisbroken
happens but with gdal_rasterize I think there are no tricks that could
help.
Actually
Le 19/03/2024 à 21:38, Fengting Chen a écrit :
I copied out the command from install_python_Release.cmake and ran it
manually. Then it worked. Not sure why the command not invoked. I
don’t see error from “cmake –build . –target install –config Release”.
My setuptools is 40.6.2.
Not sure
Hi,
Le 19/03/2024 à 20:14, Fengting Chen via gdal-dev a écrit :
Hi, I was able to build the GDAL with python binding on without error
on windows. However, “cmake --build . --target install --config
Release” command doesn’t install the python site-packages etc to the
specified
Why not just trying?
Demo:
$ gdal_create -outsize 10 10 -burn 255 test.tif -a_srs EPSG:4326 -a_ullr
0 10 10 0
$ gdal_rasterize -burn 0
'{"type":"Polygon","coordinates":[[[2,2],[2,4],[4,4],[4,2],[2,2]]]}'
test.tif
$ gdal_translate test.tif /vsistdout/ -of aaigrid
ncols 10
nrows
Thomas,
Le 19/03/2024 à 08:26, thomas bonfort via gdal-dev a écrit :
I have a side-question concerning the update-in-place behavior of the
gtiff driver in this case: given that a compressed strile will nearly
always be smaller after this update (due to better compression ratios
on the uniform
Hi Luís,
it depends on your GDAL was built.
You can check it with "gdalinfo --format gtiff | grep LIBTIFF" and it
will return either LIBTIFF=INTERNAL or LIBTIFF=LIBTIFF, Version X.Y.Z
If it is with its internal libtiff copy, then it corresponds roughly to
the state of libtiff master at
07/03/2024 à 20:07, Even Rouault via gdal-dev a écrit :
Hi,
The flow of comments calming down, I motion to adopt RFC 99: Geometry
coordinate precision
https://github.com/OSGeo/gdal/pull/9300
Pre-rendered view at
https://github.com/rouault/gdal/blob/rfc99_text/doc/source/development/rfc
NK1169: one
or more multiply defined symbols found
[C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]
*From: *Even Rouault
*Date: *Thursday, March 14, 2024 at 11:52 AM
*To: *Fengting Chen ,
gdal-dev@lists.osgeo.org
*Subject: *Re: [gdal-dev] FW: [External] : GDAL 3.8.4 build on windows
failed at linking
H
(re-adding list)
Le 14/03/2024 à 18:58, Robin Wilson a écrit :
Hi Even,
Perfect - adding —config PG_USE_COPY YES solved it. I’ll write a blog
post about this that hopefully will be found by someone with the same
issue in future.
You may also suggest documentation enhancement to
Robin,
- output of "gdalinfo --version" ?
- try adding ``--config PG_USE_COPY YES`` to the command line where you
append to the existing table. Cf
https://gdal.org/drivers/vector/pg.html#configuration-options (copy mode
is enabled by default at table creation, but not in append scenarios)
hen/gdal-3.8.4/build/Debug/gdald.exp
C:\fechen\gdal-3.8.4\build\Debug\gdald.dll : fatal error LNK1169: one
or more multiply defined symbols found
[C:\fechen\gdal-3.8.4\build\GDAL.vcxproj]
I set “GDAL_USE_JPEG_INTERNAL” with “ON”. Any suggestions?
Thanks!
*From: *Even Rouault
*Date: *Tue
-4'
2478
<https://github.com/AbelPau/gdal/actions/runs/8277097153/job/22646788426#step:6:2479>42:
2479
<https://github.com/AbelPau/gdal/actions/runs/8277097153/job/22646788426#step:6:2480>42:
/Users/runner/work/gdal/gdal/build/autotest/ogr/ogr_basic_test.py:454:
AssertionError
try rebasing on top of latest master. It looks like the errors are only
those fixed per
https://github.com/OSGeo/gdal/commit/6703d3071de7155d320a39a580f27230428dcaca
--
http://www.spatialys.com
My software is free, but my time generally not.
___
1 - 100 of 7538 matches
Mail list logo
