Hello,
I stumbled across what appears to me as an typo in the gdal_translate
function implemented in QGIS 3.18.2.
I performed a translation from a geotiff to a surfer (non-binary) .grd
file without a specification of a NODATA-Value.
In the resulting .grd-file the NODATA value was 1.70141E+38.
Hello,
I'm debugging an artifact that I encountered while using geolocation arrays:
https://github.com/OSGeo/gdal/issues/4707
While searching I found this ticket mentioning that the backward map
implementation is broken and a new implementation is being considered:
https://trac.osgeo.org/gdal/tic
More specifically, I'm guessing the MOST efficient is to read whole blocks
from one band, which presumably avoids crossing compression boundaries etc.
A block may be a scanline, or it may be a tile, depending on the format.
On Mon, Nov 1, 2021 at 2:29 PM Simon Eves wrote:
> Band by band makes
Band by band makes sense. I shall do that instead. Thank you! :)
On Mon, Nov 1, 2021 at 2:05 PM Even Rouault
wrote:
> Yes regarding multithreading. Regarding GRIB and performance issues, you
> must be aware that the GRIB driver when accessing a single pixel of a band
> needs to decompress data f
Yes regarding multithreading. Regarding GRIB and performance issues, you
must be aware that the GRIB driver when accessing a single pixel of a
band needs to decompress data for the whole band. Hence there's a
per-dataset cache of band data which default to 100 MB (you can increase
it by setting
You can ignore this.
I have rather belatedly found the documentation that says that one must
open a GDALDataset per thread, even if it's on the same file.
The multi-threading now works just fine.
Interestingly, we're not actually doing that with our existing geo
importer. I guess it's OK because
> What about starting this archive?
> https://marc.info/?q=about#Add
Thanks Markus, I’ve asked MARC about adding gdal-dev.
I’ve done the same with Mail Archive[1] but the expected subscription
confirmation doesn’t show up[2], though there is one dating back to 2008[3].
Maybe the old one is get
I am in favor of that (and the same for PROJ please:
https://lists.osgeo.org/mailman/listinfo/proj). Currently it is very
complicated to find anything using a search engine.
.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos i
Hi, would you please consider adding Gdal-dev to the MARC archives?
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I'm not an administrator, just someone who relies on the community and is
having difficulties consulting historical data now that Nabble has discontinued
it's archive.
Thank yo
Hi,
I have prepared a GDAL/OGR 3.4.0 release candidate.
Pick up an archive among the following ones (by ascending size):
https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0rc1.tar.xz
https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0rc1.tar.gz
https://download.osgeo.org/gdal/3.4.0/gdal340rc1.z
Andrew,
this was discussed in https://github.com/OSGeo/gdal/pull/3945 . I also
find the current situation not super satisfactory.
Even
Le 01/11/2021 à 09:59, Andrew C Aitchison a écrit :
On Fri, 29 Oct 2021, Even Rouault wrote:
if you feel bored this week end, you can review and submit twea
On Fri, 29 Oct 2021, Even Rouault wrote:
if you feel bored this week end, you can review and submit tweaks for the
NEWS file:
https://github.com/OSGeo/gdal/blob/release/3.4/gdal/NEWS
New optional dependencies
* libjxl (master) when using internal libtiff for JPEG-XL support
12 matches
Mail list logo
