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.
___
nombre de *Abel
Pau via gdal-dev
*Enviado el:* dimecres, 13 de març de 2024 12:38
*Para:* Even Rouault ;
gdal-dev@lists.osgeo.org
*Asunto:* Re: [gdal-dev] There's something strange about two tests
that are very similar
Hi Even,
thanks for your effort on that.
I’ll spend some time analyzin
Hi,
I've checkout'ed your branch locally and I can reproduce the error when
running the Python tests. Some of the CI checks give an interesting hint
about this being related to a UTF8 issue, and I wondered why
But running "ogrinfo
Hi,
I declare this motion passed with +1 from PSC members HowardB and me,
and +0 from KurtS
Even
Le 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
Not the answer you'll probably want to hear, but:
- Use an up-to-date compiler
- Use package distributions like vcpkg or conda-forge that already
brings all the dependencies "for free"
- It seems you mix builds of different compilers (VS vs mingw). That's a
bit asking for troubles ;-)
Le
- Are sure all needed files have been committed and pushed for the
failing test?
- Perhaps an issue Windows CR-LF vs Unix LF end of line characters ? The
default settings of git on Windows may mess with binary files. cf
Le 12/03/2024 à 13:33, Pierre Chatelier a écrit :
But I can't figure out how to customize the , which is
Band1, Band2, Band3...
I tried GDALRasterBand::SetDescription(), but without success
Looking at netcdfdataset.cpp line 9625, the netCDF variable name for
a band is extracted from the
Pierre,
Le 12/03/2024 à 12:51, Pierre Chatelier a écrit :
Ok, I can confirm that
-creating a dataset with bands with the netCDF driver works
-saving the dataset will write the expected "SUBDATASETS" domain with
"SUBDATASET__NAME=NETCDF:"":""
But I can't figure out how to customize the ,
Hi,
I've had some success prototyping the below idea on a few utilities. See
https://github.com/OSGeo/gdal/pull/9445 for details
Even
Le 08/03/2024 à 16:40, Even Rouault via gdal-dev a écrit :
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means
that:
- the usage
Mike,
Yes, the STACIT driver requires either a filename or STACIT:filename,
and doesn't support passing the content of the file in the connection string
An easy workaround is to do:
gdal.FileFromMemBuffer("/vsimem/temp_stacit.json", stac_string)
myds=gdal.OpenEx("/vsimem/temp_stacit.json")
)
*Perhaps if the destination folder doesn’t exist I should NOT create
it and return a FAILURE?*
*De:*Abel Pau
*Enviado el:* dimecres, 6 de març de 2024 16:24
*Para:* Abel Pau ; Even Rouault
; gdal-dev@lists.osgeo.org
*Asunto:* RE: [gdal-dev] Testing the driver
Hi,
It seems nothing changes. I
Abel,
Hi,
I’m obtaining this error:
/__w/gdal/gdal/doc/source/drivers/vector/miramon.rst: WARNING:
document isn't included in any toctree
The file of the rst is miramon.rst but the name of the driver is
MiraMonVector (to make it different from MiraMonRaster, in a future).
So, this is a
Le 08/03/2024 à 18:34, Javier Jimenez Shaw a écrit :
I don't like that the behaviour of a command line depends on the
configuration of the user (that is usually not aware of). So a command
that works for me doesn't work for you. That is bad.
I was perhaps not clear. Let me clarify, but at
In principle the idea sounds good.
How is it parsing the numbers? is it locale agnostic? I think it is
not, because it is using "strtod". That means that if I have my locale
in Spanish, French, German, ... it will expect "," as the decimal
separator, right?
if running under a non-C
Some options have related environment variables, eg --debug /CPL_DEBUG.
Options are also passed through to several drivers.
I assume that the implications for these are not significant ?
This wouldn't change the general logic of GDAL and so the existing
(possibly confusing) set of various type
Thomas,
my number 1 requirement would be that the rewrite not cause any
backwards compatibility issues compared to today's argument handling.
I suspect many users are calling the gdal utilities through scripts
and it would be a pain to have to update those when upgrading gdal.
Yes,
Hi,
Our command line C++ utilities use ad-hoc manual parsing, which means that:
- the usage message must be manually composed,
- you must take care to check that there are enough remaining arguments
for the ones that take value to avoid out-of-bounds accesses (tests like
argc + 1 < argn)
Le 07/03/2024 à 20:44, Kurt Schwehr a écrit :
+0 KurtS. It seems like a good idea, but I worry about
unintended consequences, but can't come up with any.
I'm quite confident that as most new features (or sometimes even
bugfixes), it will cause issues in some scenarios. Hopefully it will
Hi,
Varying tile sizes: we definitely don't support that, and I don't think
any of the OGC tiling specifications do. I guess that could be
implemented (what can't?) but the WMS driver definitely doesn't
currently. The code you spotted is for tiles at the right and bottom
edges of the virtual
At #10 we can see the variable nNum set to a non-sense megabignumber.
Is it on a -DCMAKE_BUILD_TYPE=Debug build ? Otherwise stack traces and
variable content in the debugger might look like garbage because of
optimizations.
If it is a debug build, then there's likely some memory corruption
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/rfc99_geometry_coordinate_precision.rst
Starting with my
Richard,
Tried to google for this, but asking here: is it only possible to
rename one layer per ogr2ogr call? (while it is possible to load
several layers)
Not with ogr2ogr
If so I will make my scripts do the loading one by one, but just want
to check.
or using
1 - 100 of 7517 matches
Mail list logo
