Re: [gdal-dev] GDAL & CAD Files
https://gdal.org/drivers/vector/dwg.html says: > DWG files are considered to have no georeferencing information through OGR >From https://gdal.org/programs/ogr2ogr.html, you will need to specify the spatial reference system / projection with "-s_srs" -Kurt On Tue, Jun 25, 2024 at 12:55 PM Ashlyn Powell via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hello GDAL Devs, > > I am new to using GDAL, and I just don't know enough about it yet. I am > working with thousands of CAD files (DWG) to extract a project boundary > line then export it out as a KML. I would love to automate this process. > Does GDAL have the capability to work with DWG files? Has anyone attempted > this?A problem I could see happening is the projection not being set up > correctly, and all of them exported boundary lines showing up in the ocean. > > Any pointers are much appreciated! I thank you all for your time. > > Thank you, > -- > Ashlyn Powell > GIS Analyst | GIS > ashlyn.pow...@blewinc.com > 888-933-2111 <8889332111> > www.blewinc.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Hungarian Notation
My personal take: I slightly Hungarian notation and it seems to me like needing that extra notation points to other coding style issues. However, I think moving away from it would be a chaotic mess for GDAL. It would be a massive change to switch it all. Consistency is critical. On Wed, Apr 17, 2024 at 9:10 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > 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 might have felt > unfamiliar with the Hungarian notation, but now I've fully internalized it, > so I hardly notice it. It would be interesting to have opinions of other > developers if they find it inconvenient/a hurdle, are neutral or like it. > The thing is that if we decide to no longer use it, the inconsistency of > mixing free style naming and Hungarian notation might be problematic and > make code confusing. We should probably aim at being consistent at least at > the scope of a given function or file. > > Even > Le 17/04/2024 à 15:48, Andrew Bell via gdal-dev a écrit : > > Hi, > > I was going to make some changes to some GDAL code and I generally want to > follow along. I see that most of the code is still using Hungarian notation > for identifier names. I haven't seen this anywhere else in like 20 years. > > Is it OK to submit code without this naming convention or do we still > think it's important. I didn't see an RFC or documentation that covers > this, but there's lots so I may have missed it. > > Thanks, > > -- > Andrew Bell > andrew.bell...@gmail.com > > ___ > gdal-dev mailing > listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 99: Geometry coordinate precision
+0 KurtS. It seems like a good idea, but I worry about unintended consequences, but can't come up with any. On Thu, Mar 7, 2024 at 11:07 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > 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 +1, > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Official dataset for benchmarking GDAL I/O?
As Even said, this is a really tough topic. I have tried some micro benchmarking for small bits and for short term dev this is sort of ok. The biggest problem is getting a stable test env for benchmarking. Even a single user machine doing only benchmarking is all over the place. And if you are benchmarking on a fleet, the difference in other tasks and exact specs of the machines makes the data crazy noisy. Even with binary sizes and ram usage I saw large run to run variance because of slight changes in dependencies changing how the compiler's optimizers work. For timing, if I end up with different hardware it's bad, but even within a hardware config, bus contention, how hot the caches stay, ssd perf, network, and other systems can be highly variable. On Sun, Feb 25, 2024, 5:27 AM Adam Stewart via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Thanks Even, > > I think what I'm envisioning is more of an integration test than a unit > test. We don't intend to use this in TorchGeo CI on every commit, only on > PRs that we know may impact I/O (much less frequent than in GDAL). We would > also run it before each release and publish performance metrics to prevent > regressions. Since it's run infrequently and manually, we wouldn't suffer > from the same issues of 20% buffering and could actually run multiple times > and average. > > For TorchGeo, we definitely want to consider full-sized tiles/scenes, not > small synthetic patches. Many of our sampling strategies and design > decisions require multiple large scenes to accurately validate. > > Unless someone chimes in with different opinions, it sounds like there is > room for a research paper on this topic. Would love to include some GDAL > developers on such a paper if anyone has interest. Will talk this over with > my own research group. > > P.S. We've also been thinking about how to improve GPU support in GDAL. > The lowest hanging fruit is anything that can be formulated as matrix > multiplication, such as affine transformations in gdalwarp. Unfortunately, > I don't know anything about CUDA/ROCm. If we were to do this in TorchGeo, > we would just use PyTorch, which has a lot of overhead you won't need in > GDAL. But let's discuss this in a different thread, don't want to derail > this conversation. > > *Dr. Adam J. Stewart* > Technical University of Munich > School of Engineering and Design > Data Science in Earth Observation > > On Feb 25, 2024, at 13:25, Even Rouault > wrote: > > Adam, > > Automated performance regression testing is probably one of the aspect of > testing that could be enhanced. While the GDAL autotest suite is quite > comprehensive functionally wise, performance testing has traditionally been > a bit lagging. That said, this is an aspect we have improved lately with > the addition of a benchmark component to the autotest suite > https://github.com/OSGeo/gdal/tree/master/autotest/benchmark . This is > admitedly quite minimalistic for now, but testing some scenarios involving > the GTiff driver and gdalwarp. > > To test non-regression for a pull request, we have a CI benchmark > configuration ( > https://github.com/OSGeo/gdal/blob/master/.github/workflows/linux_build.yml#L111 > + https://github.com/OSGeo/gdal/tree/master/.github/workflows/benchmarks) > that runs the benchmarks first against master, and then with the pull > request (during the same run of the same worker). But we need to allow a > quite large tolerance threshold (up to +20%) to take into account that > accurate timing measurements are extremely hard to get on CI infrastructure > (even locally, on microbenchmarks this is very challenging). So this will > mostly catch up big regressions, not subtle ones. > > One of the difficulty with benchmark testing is that we don't want the > tests to run for hours, especially for pull requests, so they need to be > written in a careful way to still trigger the relevant code paths & > mechanisms of the code base that are exercised by real-world large datasets > while running in a few seconds each at most. Typically those tests > autogenerate their test data too, to avoid the test suite depending on too > large datasets and keep the repository size as small as possible. > > As you mention GPUs, we have had private contacts from a couple GPU makers > in recent years about potential GPU'ification of GDAL, but this has lead to > nowhere for now. Some mentioned that moving data acquisition to the GPU > could be interesting performance wise, but that seems to be a huge > undertaking, basically moving the GTiff driver, libtiff and its codecs as > GPU code. And even if done, how to manage the resulting code duplication... > We aren't even able to properly keep up the OpenCL warper contributing many > years ago in sync with the CPU warping code. We also lack GPU expertise in > the current team to do that. > > Even > Le 25/02/2024 à 12:58, Adam Stewart via gdal-dev a écrit : > > Hi, > > *Background*: I'm the developer of the TorchGeo >
Re: [gdal-dev] opening images via a URI
See vsicurl and the other network drivers for things more specific like /vsis3/, /vsigs/, /vsiaz/, /vsioss/ or /vsiswift/ https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access On Sat, Jan 13, 2024 at 2:59 PM Barry DeZonia via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hey all, > > I am in a position where a library I am developing would benefit if gdal > could open an image that lives on the web. I guess maybe it's a VSI thing? > Anyhow I am wondering how I could extend the Java API to open things given > a Java URI. It could delegate to the C/C++ VSI code after manipulating the > URI as needed. Does anyone think this is feasible? Are there good examples > of how the VSI stuff works that I could refer to? > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Un-vendoring a number of third-party libraries?
+1 for un-vendoring. Long term, I think that will be a big win. Looks like others have covered all of the issues that I can think of. On Fri, Dec 15, 2023 at 4:45 PM Greg Troxel via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Even Rouault via gdal-dev writes: > > > I'm considering removing from the source tree a number of third-party > > libraries that we have vendored over the years: zlib, libpng, libjpeg, > > giflib, liblerc > > I'm basically strongly in favor of un-vendoring. I view vendoring as a > bug, even if it is a workaround for other bugs. > > > I believe the main reason for having them vendored is now mostly > > historical, dating back to times where there was no packaging system > > on Windows. Now we have Conda-Forge or vcpkg, it is easy to have those > > dependencies installed. > > From the pkgrsc viewpoint, I don't see any reasons why vendoring helps. > It looks to me like the build is using normal dependencies, including > zlib, jpeg, tiff, geotiff. But apparently not shapelib and json-c. > > $ ldd /usr/pkg/lib/libgdal.so > /usr/pkg/lib/libgdal.so: > -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1 > -lgeos.3.12.1 => /usr/pkg/lib/libgeos.so.3.12.1 > -lstdc++.9 => /usr/lib/libstdc++.so.9 > -lm.0 => /usr/lib/libm.so.0 > -lc.12 => /usr/lib/libc.so.12 > -lgcc_s.1 => /usr/lib/libgcc_s.so.1 > -lwebp.7 => /usr/pkg/lib/libwebp.so.7 > -lsharpyuv.0 => /usr/pkg/lib/libsharpyuv.so.0 > -lpthread.1 => /usr/lib/libpthread.so.1 > -lexpat.2 => /usr/lib/libexpat.so.2 > -lxerces-c-3.2 => /usr/pkg/lib/libxerces-c-3.2.so > -lopenjp2.7 => /usr/pkg/lib/libopenjp2.so.7 > -lnetcdf.19 => /usr/pkg/lib/libnetcdf.so.19 > -lexecinfo.0 => /usr/lib/libexecinfo.so.0 > -lelf.2 => /usr/lib/libelf.so.2 > -lhdf5_hl.200 => /usr/pkg/lib/libhdf5_hl.so.200 > -lhdf5.200 => /usr/pkg/lib/libhdf5.so.200 > -lsz.2 => /usr/pkg/lib/libsz.so.2 > -laec.0 => /usr/pkg/lib/libaec.so.0 > -lz.1 => /usr/lib/libz.so.1 > -lbz2.1 => /usr/lib/libbz2.so.1 > -lxml2.2 => /usr/pkg/lib/libxml2.so.2 > -llzma.2 => /usr/lib/liblzma.so.2 > -lcurl.4 => /usr/pkg/lib/libcurl.so.4 > -lnghttp2.14 => /usr/pkg/lib/libnghttp2.so.14 > -lidn2.0 => /usr/pkg/lib/libidn2.so.0 > -lunistring.5 => /usr/pkg/lib/libunistring.so.5 > -lintl.1 => /usr/lib/libintl.so.1 > -lssl.15 => /usr/lib/libssl.so.15 > -lcrypto.15 => /usr/lib/libcrypto.so.15 > -lcrypt.1 => /lib/libcrypt.so.1 > -lgssapi.12 => /usr/lib/libgssapi.so.12 > -lkrb5.28 => /usr/lib/libkrb5.so.28 > -lhx509.7 => /usr/lib/libhx509.so.7 > -lasn1.10 => /usr/lib/libasn1.so.10 > -lcom_err.8 => /usr/lib/libcom_err.so.8 > -lroken.20 => /usr/lib/libroken.so.20 > -lutil.7 => /usr/lib/libutil.so.7 > -lwind.1 => /usr/lib/libwind.so.1 > -lheimbase.2 => /usr/lib/libheimbase.so.2 > -lheimntlm.6 => /usr/lib/libheimntlm.so.6 > -lgif.7 => /usr/pkg/lib/libgif.so.7 > -lgeotiff.5 => /usr/pkg/lib/libgeotiff.so.5 > -lproj.19 => /usr/pkg/lib/libproj.so.19 > -lsqlite3.1 => /usr/lib/libsqlite3.so.1 > -ltiff.6 => /usr/pkg/lib/libtiff.so.6 > -ljbig.2 => /usr/pkg/lib/libjbig.so.2 > -ljpeg.8 => /usr/pkg/lib/libjpeg.so.8 > -lpng16.16 => /usr/pkg/lib/libpng16.so.16 > -lrt.1 => /usr/lib/librt.so.1 > -lpcre.1 => /usr/pkg/lib/libpcre.so.1 > -lqhull_r.8.0 => /usr/pkg/lib/libqhull_r.so.8.0 > > > For libjpeg, there was a particular history related to 12-bit JPEG > > So documentation of prereqs will say "you need jpeg, and you really > should use jpeg-turbo so you have 12-bit support"? If so, sounds good. > > > Benefits of un-vendoring those libraries: > > > > - currently, we must take care of updating them regularly, in > > particular to make sure they integrate the latest fixes for their > > vulnerabilities. > > And not just that, but to have a gdal point release within days of any > vendored upstream release that has a security fix, documented as such or > not. That's a tall order, and ~nobody achieves it. This point is > strongly in favor of unvendoring. > > Also, if there is a portablity or other bug fix, that needs to be > imported and apoint release, so people can get those fixes. > > > Looking a bit around in different open source build recipees of GDAL > > (Debian, Conda-Forge, vcpkg, OSGeo4W, gisinternals, rasterio-wheels), > > those proposed changes should have modest impact, as they already > > mostly use external libraries. What I've identified (I may have missed > > things) to require changes from the maintainers of those distributions > > to keep the same level of functionality: > > > > - gisinternals doesn't seem to have a liblerc build > > > > - rasterio-wheels doesn't seem to have libpng and giflib builds > > I am pretty
Re: [gdal-dev] Requiring numpy for the Python bindings
I lean towards just requiring numpy. It's super common and once a system brings in gdal python, it can't be a super constrained env where keeping things really small is critical. Just requiring numpy simplifies a number of aspects. I think the setup.py topic as a whole is somewhat separate.l. So whichever way the numpy dep goes (required or optional), switching to pyproject.toml seems important. I'm fairly new to pyproject.toml, so I might be missing something. -Kurt On Mon, Dec 4, 2023 at 10:38 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > The current situation where numpy is an optional dependency of the GDAL > Python bindings is quite cumbersome to deal with our setup.py's > setuptools . All details (a bit tricky) in > https://github.com/OSGeo/gdal/issues/8069 . It seems it would be simpler > if the bindings just required numpy, which is the confugration most > people using the bindings likely actually end up using anyway. > > Any opposition to that? > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 98: Build requirements for GDAL 3.9
+1 KurtS On Fri, Dec 1, 2023, 7:34 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: adopt RFC 98: Build requirements for GDAL 3.9 > > https://github.com/OSGeo/gdal/pull/8802 > > 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 > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] "RFC 98: Build requirements for GDAL 3.9" available for review
Woohoo! I look forward to the cleanups that this will enable. Thank you Even for working on this! I am hoping that the hdf4 will get some similar improvements in 2024. I haven't looked to see if any of the hdf4 cleanup in 2023 could allow GDAL cleanup. My guess is that there isn't anything yet as most of the changes have been internal only. On Fri, Nov 24, 2023 at 3:15 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Please find "RFC 98: Build requirements for GDAL 3.9" in > https://github.com/OSGeo/gdal/pull/8802 for review & comments > > Summary: > > The document updates RFC68 with the new build requirements for GDAL 3.9: > >- C++ >= 17 >- CMake >= 3.16 >- PROJ >= 6.3.1 > > The minimum version for the following optional dependencies is also > updated: > >- Python >= 3.8 >- GEOS >= 3.8 >- Poppler >= 0.86 >- libtiff >= 4.1 >- libcurl >= 7.68 >- libpng >= 1.6.0 >- libsqlite3 >= 3.31 >- libopenjp2 >= 2.3.1 >- libnetcdf >= 4.7 and built with NC4 enabled >- libhdf5 >= 1.10 > > Even > > -- http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading
+1 KurtS One minor comment... I use pfnOpen in a few of my local fuzzers, but I build statically without plugins, so I think my use won't be impacted. But even if I am impacted, that's my problem and not a responsibility of the GDAL project as I'm using internal GDAL details. > Another potential issue is that if external code would directly use the pfnOpen, pfnCreate, pfnCreateCopy, etc. function pointers of a GDALDriver instance, it would see them null before the actual driver is loading, but direct access to those function pointers has never been documented (instead users should use GDALOpen(), GDALCreate(), GDALCreateCopy() etc), and is not expected to be done by code external to libgdal core. On Wed, Nov 15, 2023 at 1:52 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: adopt RFC 96: Deferred C++ plugin loading > > https://github.com/OSGeo/gdal/pull/8648 > > Pre-rendered view: > > > https://github.com/rouault/gdal/blob/rfc96_text/doc/source/development/rfc/rfc96_deferred_plugin_loading.rst > > > 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 > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Show isBigTIFF in image metadata
Jukka, What's the exact use case for needing to know if a tiff is traditional or BigTIFF? Is there a key tool that doesn't understand BigTIFF? The only one I know of is Autodesk Civil3D. Thanks, -Kurt On Thu, Nov 2, 2023 at 2:49 PM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Jukka, > > > Does it feel reasonable? I know that overviews may be standard TIFFs while > the main image is BigTIFF but maybe the information from the header would > be enough. Or have I missed some existing tool? I thought that tiffinfo at > least would report TIFF/BigTIFF but it doesn’t. > > tiffdump does: > > $ tiffdump byte.tif > byte.tif: > Magic: 0x4949 Version: 0x2a > > vs > > $ tiffdump bigtiff.tif > bigtiff.tif: > Magic: 0x4949 Version: 0x2b > > Even > > -- http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for review and discussion on RFC96: Deferred in-tree C++ plugin loading
Thanks Even for the RFC! After a quick read, this seems reasonable. I was mostly concerned about the impact on folks who statically build everything (my biggest use case), but that is completely addressed in the doc. On Thu, Nov 2, 2023 at 5:00 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I'm seeking for feedback and review on a new RFC (RFC 96: Deferred > in-tree C++ plugin loading), > detailed in https://github.com/OSGeo/gdal/pull/8648, whose summary is: > > This RFC adds a mechanism to defer the loading of in-tree C++ plugin > drivers to > the point where their executable code is actually needed, and converts a > number > of relevant drivers to use that mechanism. The aim is to allow for more > modular > GDAL builds, while improving the performance of plugin loading. > > (This is material only for GDAL 3.9 of course) > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: OSGeo Community Sprint Financial Support
+1 Kurt S On Tue, Oct 31, 2023 at 10:02 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Dear PSC, > > Sorry for the short notice, but I would like to motion that the GDAL > Sponsorship Program financially support GDAL PSC members who wish to attend > the OSGeo Community Sprint in Vienna [1] next week. Support level is capped > at 1000€ for European attendees and 1500€ for others. > > Howard > > [1] https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2023 > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Notice: issue about multi-threaded GTiff compression+decompression
> 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. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Notice: issue about multi-threaded GTiff compression+decompression
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 for > example in a "gdalwarp -co COMPRESS=... -co NUM_THREADS=..." workflow > can lead to deadlocks (process stalled forever) and/or data corruption > (sometimes without errors at generation). Cf > https://github.com/OSGeo/gdal/issues/8470 for a reproducer. The fix is > in https://github.com/OSGeo/gdal/pull/8561 > > The issue is particularly visible on Windows, or more generally any > operating system (or file system where the output file is located) which > has no VSIVirtualHandle::PRead() implementation, but it can also be > occasionally reproduced on Linux (at least as a deadlock). > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Annual Contracts for Maintainers
+1 KurtS On Wed, Oct 11, 2023 at 9:17 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> 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. > * Authorize Even Rouault for up to 90 hrs/month with a rate increase of 10 > $/hr until 30 JUL 2024 > > Howard > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL version in pip requirements file
I am not sure if there is anything in this, but take a look at https://packaging.python.org/en/latest/guides/ Also, I might suggest avoiding command line solutions. You can get the version from the python module On Mon, Sep 25, 2023, 11:55 PM Luca Delucchi via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi everyone, > > I would like to know if it is possible to set GDAL version in the pip > requirements file using gdal-config of the machine running the > installation, I tried some different ways but I was not able to do it, > also leaving GDAL without any specified version doesn't work because > it takes the last python GDAL version available in that system. > > Do you have any advice? > > > -- > ciao > Luca > > www.lucadelu.org > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
