Re: [gdal-dev] Potential geopackage rtree problem on MacOS ARM64
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 works, whereas it doesn't on OSX Arm64, so there's something quite subtle happening here). So if someone has a OSX Arm64 and is willing to give me ssh access to it, that would be welcome. In the meantime, I've submitted https://github.com/OSGeo/gdal/pull/9685 which is just a workaround to disable (by default) the threaded RTree creation on that platform. It can be explicitly enabled by setting OGR_GPKG_ALLOW_THREADED_RTREE to YES Even Le 16/04/2024 à 08:13, Rahkonen Jukka via gdal-dev a écrit : Hi, It seems that at least two MacOS ARM64 users have faced a problem with the new, faster rtree creation method so maybe it is worth having a look. Obviously a big dataset and right hardware is needed for testing https://gis.stackexchange.com/questions/479958/how-to-fix-failed-to-prepare-sql-error-when-creating-gpkg-file-from-osm-extrac/479964#479964 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://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
Re: [gdal-dev] advice on python style - get file/dataset as bytes
If using Numpy ReadAsArray maybe your friendOn Apr 14, 2024, at 7:48 PM, Michael Sumner via gdal-dev wrote:Hi, I'm getting some pushback on my code style. I just want the raw bytes in-memory of a file in Python, for a manageable tiny dataset. Is there anything especially wrong with the following? It's essentially the same as the answer here: https://lists.osgeo.org/pipermail/gdal-dev/2016-August/045030.html (I know it needs error checks, I just mean the bare style of how to get the task done). temp_name = "/vsimem/some.tif"from osgeo import gdalgdal.UseExceptions()## we do something with vrtdsn = "vrt:///vsicurl/https://github.com/cran/rgl/raw/master/inst/textures/worldsmall.png?a_ullr=-180,90,180,-90=rgb"ds = gdal.Open(dsn)## write to tif format, but using MEMgdal.Translate(temp_name, ds)## now obtain those bytes from the GDAL virtual filef = gdal.VSIFOpenL(temp_name, 'rb')gdal.VSIFSeekL(f, 0, 2) # endsize = gdal.VSIFTellL(f)gdal.VSIFSeekL(f, 0, 0) # begin## the desired result is thisdata = "" size, f)## and clean upgdal.VSIFCloseL(f)gdal.Unlink(temp_name)Cheers, Mike-- Michael SumnerSoftware and Database EngineerAustralian Antarctic DivisionHobart, Australiae-mail: mdsum...@gmail.com___gdal-dev mailing listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Potential geopackage rtree problem on MacOS ARM64
Hi, It seems that at least two MacOS ARM64 users have faced a problem with the new, faster rtree creation method so maybe it is worth having a look. Obviously a big dataset and right hardware is needed for testing https://gis.stackexchange.com/questions/479958/how-to-fix-failed-to-prepare-sql-error-when-creating-gpkg-file-from-osm-extrac/479964#479964 -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
