For the record: Norman and Daniel also +1'd on October 11.
On 2023-10-16 15:59, Howard Butler via gdal-dev wrote:
On Oct 11, 2023, at 11:13 AM, Howard Butler wrote:
PSC,
I'm a little late but I would like to make the following motions in regards to
GDAL maintainers:
* Authorize
> On Oct 11, 2023, at 11:13 AM, Howard Butler wrote:
>
> PSC,
>
> I'm a little late but I would like to make the following motions in regards
> to GDAL maintainers:
>
> * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate increase of
> 10 euros/hr until 30 NOV 2024.
> *
> In short: multithreading is hard
So true! With the introduction of tsan things are a little less bad, but
tsan is still a tool with plenty of false positives and false negatives.
And that assumes that a particular issue is covered by the tests being run
under tsan.
Thanks for the announcement, Even! I wonder if we should track such issues
in a list? Or maybe give them a unique GitHub label?
We don't plan to release a 3.6.5, correct?
I'm going to make a Rasterio post release that patches 3.6.4 by tomorrow:
https://github.com/rasterio/rasterio/issues/2943.
Le 16/10/2023 à 17:14, Kurt Schwehr a écrit :
Thanks for the heads up!
Can you share that SHAs of the fix and cause?
master: d083af1ec9c38e79bfb0532885570de6e5b8a410
3.7 branch (should apply to 3.6 as well):
b5858ed5bc5004c97f7cd6000674015bdc70b33b
cause: a worker thread of the
Thanks for the heads up!
Can you share that SHAs of the fix and cause?
On Mon, Oct 16, 2023, 7:44 AM Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
>
> For GDAL 3.6.0 to 3.7.2, use of multi-threaded GTiff
> compression+decompression, in particular within the same file, as
Thanks Even for notifying this.
I see the fix will be included in the next releases 3.7.3 and 3.8.0, both
planned for November 1st (just in a couple of weeks)
https://github.com/OSGeo/gdal/milestones
On Mon, 16 Oct 2023 at 16:42, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi,
Hi,
For GDAL 3.6.0 to 3.7.2, use of multi-threaded GTiff
compression+decompression, in particular within the same file, as for
example in a "gdalwarp -co COMPRESS=... -co NUM_THREADS=..." workflow
can lead to deadlocks (process stalled forever) and/or data corruption
(sometimes without
Thanks a lot Javier. I'll test this and come back to you.
Here is a download link to the shapefile causing this issue for me:
https://filesender.renater.fr/?s=download=da2a7ff6-9755-4086-b1ed-71c6ebc72a0f
Le lun. 16 oct. 2023 à 15:21, Even Rouault a
écrit :
>
> Le 16/10/2023 à 15:15, Javier
Le 16/10/2023 à 15:15, Javier Jimenez Shaw via gdal-dev a écrit :
Do you mean a MultiLineString?
This piece of code is working for me (I hope without any bug).
if (wkbFlatten(poGeometry->getGeometryType()) == wkbMultiLineString)
multiLineStringGeometry(poGeometry);
...
Do you mean a MultiLineString?
This piece of code is working for me (I hope without any bug).
if (wkbFlatten(poGeometry->getGeometryType()) == wkbMultiLineString)
multiLineStringGeometry(poGeometry);
...
multiLineStringGeometry(OGRGeometry* poGeometry)
{
Hi all,
I hope this e-mel finds you well.
I am trying to read a shapefile layer from OGR from a C++ application
following the tutorial found here:
https://gdal.org/tutorials/vector_api_tut.html#reading-from-ogr
We have difficulties with a layer containing PolyLines with several parts.
The
12 matches
Mail list logo
