Re: [gdal-dev] Python bindings: enabling exceptions by default?

Hi, https://github.com/OSGeo/gdal/pull/7475 has now been merged into master. The UseExceptions()/DontUseExceptions() methods when invoked from one module also affect all other gdal, ogr, osr, gnm modules at once (that is now gdal.UseExceptions() is equivalent to gdal.UseExceptions() +

Re: [gdal-dev] Python bindings: enabling exceptions by default?

Hi, Given the feedback received, I've amended the pull request with an extra commit to disable exceptions by default, except in autotest/ and scripts. And emit a FutureWarning if exceptions have not been explicitly enabled or disabled. So this will test the exceptions-by-default mode in the

Re: [gdal-dev] Python bindings: enabling exceptions by default?

Does whether we call it 3.7 or 4.0 affect how long 3.6 is supported ? I don't think Alan's comment would suggest that the next feature version planned for may would be called other than 3.7.0. IMHO there should be more substantial breaking changes to call it 4.0 than just what is discussed

Re: [gdal-dev] Python bindings: enabling exceptions by default?

On Mon, 20 Mar 2023, Alan Snow wrote: I think that this is a good change. However, I recommend making this change associated with the GDAL 4.0 release as it is likely going to break existing codebases. Does whether we call it 3.7 or 4.0 affect how long 3.6 is supported ? -- Andrew C.

Re: [gdal-dev] Python bindings: enabling exceptions by default?

Folks, As long as there is a clear path to disabling python exception handling fairly cleanly I can live with it. Like Kurt, we have a large code base using GDAL mostly without exceptions enabled for GDAL. If there is going to be a change, I also agree 4.0 is the time to do it. Best regards,

Re: [gdal-dev] Python bindings: enabling exceptions by default?

We are heavy users of the swig bindings. We have some Fiona users and are only just now in the process of starting to use rasterio. We have only 3 instances of calling UseExceptions. Turning on UseExceptions immediately blew up a bunch of my tests that were making incorrect assumptions. Nothing

Re: [gdal-dev] Python bindings: enabling exceptions by default?

I think that this is a good change. However, I recommend making this change associated with the GDAL 4.0 release as it is likely going to break existing codebases. On Mon, Mar 20, 2023, 12:58 PM Howard Butler wrote: > > > > On Mar 19, 2023, at 7:34 AM, Even Rouault > wrote: > > > > Hi, > > > >

Re: [gdal-dev] Python bindings: enabling exceptions by default?

> On Mar 19, 2023, at 7:34 AM, Even Rouault wrote: > > Hi, > > I've prepared a pull request that does the above, but this raises a number of > questions. See my longish comment at > https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852. Thoughts > appreciated First off, thank

[gdal-dev] Python bindings: enabling exceptions by default?

Hi, I've prepared a pull request that does the above, but this raises a number of questions. See my longish comment at https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852. Thoughts appreciated Even -- http://www.spatialys.com My software is free, but my time generally not.

Re: [gdal-dev] Python bindings for a GDAL dependent library

Hi, Thanks for your reply! Say I am implementing some raster processing algorithm in c++ (thus using gdal c api to load the input and to create an output ds) and want to write python code that takes the result and post process it (say use gdal_calc.py to combine some results of that function). I

Re: [gdal-dev] Python bindings for a GDAL dependent library

On Thu, Jun 25, 2020 at 2:40 PM Idan Miara wrote: > Hi all, > > I am writing a C++ library with a C API that links to GDAL dynamically > with LoadLibrary. > I would like to access the C API via Python and I have a few questions. > > Currently the library compiled with MSVC and I was able to

[gdal-dev] Python bindings for a GDAL dependent library

Hi all, I am writing a C++ library with a C API that links to GDAL dynamically with LoadLibrary. I would like to access the C API via Python and I have a few questions. Currently the library compiled with MSVC and I was able to access some functions from python via SWIG but I didn't try to pass

Re: [gdal-dev] [Python bindings] BuildOverviews() not supported for VRT dataset

just edited the previous post (again, wrong copy and paste, shame on me) -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [Python bindings] BuildOverviews() not supported for VRT dataset

Yeah you're totally right obviously :) i forgot to copy and paste ds = gdal.BuildVRT(out_vrt, rasters, options=vrt_options) in between... out_vrt = os.path.join(out_dir, 'mosaic.vrt') ds = gdal.BuildVRT(out_vrt, [raster1.tif, raster2.tif]) ds = None # this did the trick! ds =

Re: [gdal-dev] [Python bindings] BuildOverviews() not supported for VRT dataset

On vendredi 7 février 2020 03:58:02 CET umbertofilippo wrote: > Solved by looking at this answer > dvrt/299218> > > > out_vrt = os.path.join(out_dir, 'mosaic.vrt') > ds = gdal.BuildVRT(out_vrt, [raster1.tif,

Re: [gdal-dev] [Python bindings] BuildOverviews() not supported for VRT dataset

Solved by looking at this answer : out_vrt = os.path.join(out_dir, 'mosaic.vrt') ds = gdal.BuildVRT(out_vrt, [raster1.tif, raster2.tif]) ds = None # this did the trick! factors = [128, 256, 512]

[gdal-dev] [Python bindings] BuildOverviews() not supported for VRT dataset

Hello everybody, I am trying to build overviews in a VRT dataset with python GDAL. I try this code: out_vrt = os.path.join(out_dir, 'mosaic.vrt') ds = gdal.BuildVRT(out_vrt, [raster1.tif, raster2.tif]) factors = [128, 256, 512] gdal.SetConfigOption('COMPRESS_OVERVIEW', 'DEFLATE')

Re: [gdal-dev] Python Bindings and Closed Datasets

Patrick, with your updated script, the good & bad news is that I can reproduce it quite reliably, including with GDAL master on a debug build. I strongly suspect a subtle race issue in the global GDAL block cache or in the way the GTiff driver interacts with it, rather than something Python

Re: [gdal-dev] Python Bindings and Closed Datasets

After some more investigation, I've managed to put together the script below that manifests the issue on my machine (8 core, Ubuntu 19.04, GDAL 2.4.0, Python 3.7). Where I first observed this was in using 8 band WV2 imagery, so that's what the complicated input image is modeled after. Here's an

Re: [gdal-dev] Python Bindings and Closed Datasets

I've, unsuccessfully, tried to reproduce your issue with the following script: - from osgeo import gdal import concurrent.futures def worker(in_f, out_f): gdal.Unlink(out_f) gdal.Warp(out_f, in_f, options = '-co COMPRESS=DEFLATE -co TILED=YES -ts 2048 2048') jobs = [] for i in

Re: [gdal-dev] Python Bindings and Closed Datasets

On mercredi 30 octobre 2019 12:05:01 CET Patrick Young wrote: > Hi all, > > I've been experiencing some behavior using the GDAL python bindings where I > am occasionally seeing what appears to be random blocks of the tiff being > unwritten in geotiffs I've pushed to S3. a small block(s) in one

[gdal-dev] Python Bindings and Closed Datasets

Hi all, I've been experiencing some behavior using the GDAL python bindings where I am occasionally seeing what appears to be random blocks of the tiff being unwritten in geotiffs I've pushed to S3. a small block(s) in one of the bands will be all zeros while everywhere else is good. My setup

[gdal-dev] Python bindings: more multithreading friendly

Hi, In the recent discussion about the VRT Python new capability, I realized that the Python global interpreter lock wasn't released in the osgeo.gdal bindings when going from Python to GDAL native code, thus making threaded Python code inefficient. I've committed a change to improve that.

[gdal-dev] Python bindings in PyPi updated to 1.11

Hi, I've just updated the Python bindings registered in PyPi to 1.11.0 : https://pypi.python.org/pypi/GDAL/ The procedure to do the update is now documented in HOWTO-RELEASE. Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html

[gdal-dev] Python Bindings ReadAsArray and ReadRaster Errors

List, I am attempting to open a multi-band image using the PDS driver. I have a working, GDAL readable label that I can run gdalinfo and gdal_translate on without error. I am attempting to access a number of bands and operate on them using NumPy. band.ReadAsArray() is failing silently in

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

Chris, Thanks for the link / info. My issue is not working with the ctypes array, but the fact that, I believe, GDAL returns a numpy array using gdal.ReadAsArray(). Perhaps it is possible to use the GDAL python bindings ReadAsArray() to go directly into a ctypes array (as opposed to the

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

One more, likely, foolish question. Where is libgdal.dylib living on OSX? I have used the Kyngchaos binary installer and it looks like it renames libgdal.dylib to simply GDAL. Should I be soft linking that libgdal.dylib? Also, evan's test [1] looks like it is using simply libgdal.dylib. Is

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

Selon Jay L. jzl5...@psu.edu: One more, likely, foolish question. Where is libgdal.dylib living on OSX? I have used the Kyngchaos binary installer and it looks like it renames libgdal.dylib to simply GDAL. Should I be soft linking that libgdal.dylib? Also, evan's test [1] looks like it

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

On Mon, Jul 30, 2012 at 8:19 AM, Jay L. jzl5...@psu.edu wrote: Chris, Thanks for the link / info. My issue is not working with the ctypes array, but the fact that, I believe, GDAL returns a numpy array using gdal.ReadAsArray(). Perhaps it is possible to use the GDAL python bindings

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

On Fri, Jul 27, 2012 at 8:40 PM, Jay L. jzl5...@psu.edu wrote: Currently the workflow is to open the dataset and grab the first band, as usual. I then read in the array, create an empty ctype array, and use memmove to move the numpy array to my ctypes array. numpy comes with some utilities

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

Le samedi 28 juillet 2012 05:40:57, Jay L. a écrit : List, I am working on a python script using the multiprocessing module with shared memory ctype arrays. Currently the workflow is to open the dataset and grab the first band, as usual. I then read in the array, create an empty ctype

Re: [gdal-dev] Python Bindings - ReadArray direct to ctypes array?

Even, Thanks so much! I will give this a try and get it implemented into my code. This is also a wonderful primer on ctypes integration with existing Python scripts. Thanks, Jay On Sat, Jul 28, 2012 at 2:17 AM, Even Rouault even.roua...@mines-paris.orgwrote: Le samedi 28 juillet 2012

[gdal-dev] Python Bindings - ReadArray direct to ctypes array?

List, I am working on a python script using the multiprocessing module with shared memory ctype arrays. Currently the workflow is to open the dataset and grab the first band, as usual. I then read in the array, create an empty ctype array, and use memmove to move the numpy array to my ctypes

[gdal-dev] python bindings: 2x ds.WriteRaster?

Hi list, Remembering a recent message mentioning the existence of both 'ReadArray' and 'WriteArray' on the dataset level of the python swig bindings, I opened up my gdal.py (svn rev. 23438), and found this: There is a ds.ReadAsArray() There is no ds.WriteArray() There are *2* defined

Re: [gdal-dev] python bindings: 2x ds.WriteRaster?

Selon Vincent Schut sc...@sarvision.nl: Hi list, Remembering a recent message mentioning the existence of both 'ReadArray' and 'WriteArray' on the dataset level of the python swig bindings, I opened up my gdal.py (svn rev. 23438), and found this: There is a ds.ReadAsArray() line 730

Re: [gdal-dev] python bindings: 2x ds.WriteRaster?

On 11/29/2011 11:57 AM, Even Rouault wrote: Selon Vincent Schutsc...@sarvision.nl: Hi list, Remembering a recent message mentioning the existence of both 'ReadArray' and 'WriteArray' on the dataset level of the python swig bindings, I opened up my gdal.py (svn rev. 23438), and found this:

Re: [gdal-dev] python bindings: 2x ds.WriteRaster?

Le mardi 29 novembre 2011 12:03:26, Vincent Schut a écrit : On 11/29/2011 11:57 AM, Even Rouault wrote: Selon Vincent Schutsc...@sarvision.nl: Hi list, Remembering a recent message mentioning the existence of both 'ReadArray' and 'WriteArray' on the dataset level of the python swig

Re: [gdal-dev] Python bindings: How to merge two geometries

On Wed, Sep 7, 2011 at 9:59 AM, vasile vasile.cotov...@webgis.ro wrote: Hello all, I have a Shapefile layer and try to merge some features from it using OGR Python bindings. Basically there are simple polylines that are connected each-other, so the result should be a simple polyline as well

[gdal-dev] Python bindings to force geometry collections to mulitpoint, multipolygon, multiline

All, I am currently running gdal 1.7.3, and it appears that in this version the geometry factory methods to force a geometry collection to multipoint, etc. aren't exposed to Python. Am I wrong? If not, are they exposed in gdal 1.8? Dan ___

Re: [gdal-dev] Python Bindings

I couldn't think of anything at first, but now I wonder if it's an arch problem. Usually errors say if there is a missing architecture in the binaries. On OS X Snow Leopard python normally runs 64bit, unless you have one of the first Intel Macs with Core solo/duo processors. You are compiling

[gdal-dev] Python Bindings

I've built GDAL/OGR (1.7.2) with the following ./configure options $ ./configure \ CC=gcc -arch i386 \ CXX=g++ -arch i386 \ OBJC=gcc -arch i386 \ F77=gfortran -arch i386 \ FC=gfortran -arch i386 \ --with-pg=/usr/local/pgsql/bin/pg_config \ --without-macosx-framework \

Re: [gdal-dev] python bindings: strange behavior with layer

...@environment.gov.au To: Python Gis pygis2...@yahoo.com Cc: gdal-dev@lists.osgeo.org Sent: Thu, July 22, 2010 1:21:23 AM Subject: RE: [gdal-dev] python bindings: strange behavior with layer The datasource ds is still going out of scope as it is local to your getLayer2 function. Lots of ways to avoid this. Try

Re: [gdal-dev] python bindings: strange behavior with layer

drv_shp and shp_ds are going out of scope.  Use ogr.Open, which will take care of all of this for you. Thanks Howard I am using now ogr.Open but there is still the same problem. Looks like I need to reopen the layer in each method, as far as it seems it cannot exist the layer without its

RE: [gdal-dev] python bindings: strange behavior with layer

The datasource ds is still going out of scope as it is local to your getLayer2 function. Lots of ways to avoid this. Try not wrapping it up in a function, or return a tuple of datasource and layer e.g. def getDSandLayer(shape_fullname): ds = ogr.Open(shape_fullname, 0) layer =

[gdal-dev] python bindings: strange behavior with layer

Hi this is my code: from osgeo import ogr def OpenLayer(shape_path, shape_name): drv_shp = ogr.GetDriverByName('ESRI Shapefile') shp_ds = drv_shp.Open(shape_path, 1) layer = shp_ds.GetLayerByName(shape_name) print 'Name from method: %s' % layer.GetName() return layer; layer

Re: [gdal-dev] python bindings: strange behavior with layer

On Jul 20, 2010, at 12:51 PM, Python Gis wrote: Hi this is my code: from osgeo import ogr def OpenLayer(shape_path, shape_name): drv_shp = ogr.GetDriverByName('ESRI Shapefile') shp_ds = drv_shp.Open(shape_path, 1) layer = shp_ds.GetLayerByName(shape_name) print 'Name from

Re: [gdal-dev] python bindings: strange behavior with layer

Is there an FAQ somewhere we can put this? It bit me when I was starting with GDAL and Python too. Cheers, Francis On 21 July 2010 04:00, Howard Butler hobu@gmail.com wrote: On Jul 20, 2010, at 12:51 PM, Python Gis wrote: Hi this is my code: from osgeo import ogr def

[gdal-dev] Python Bindings

Hello, My autotest is failing in the trunk on a some tests and I can't seem to pinpoint the issue. One of the tests that is failing is tiff_write_80. I checked my bindings in idle and I don't have access to band.SetScale() and band.SetOffset() which is where the test is failing. Am I doing

Re: [gdal-dev] Python Bindings

Kyle, It isn't related to your python version. Those methods SetScale() / SetOffset() have been added just a few days ago to the SWIG interface .i files. But the .cpp files haven't yet been regenerated (we normally do this only at release time) to take into account those additions. Provided

Re: [Gdal-dev] python bindings, no netcdf support

I'm also not sure if GDAL supports NetCDF4 directly. It looks like the NetCDF driver is for NetCDF3. If you're lucky, NetCDF4 files might be accessible in GDAL using the HDF5 driver... I will try to write files directly with the netcdf4-python module instead of through gdal. Building from

[gdal-dev] python bindings, no netcdf support

Dear all, Recently I've started working with the python bindings of gdal on my windows XP box at work. I have managed to install them and they work like a charm, except one thing. I have bee trying to generate some maps in different formats. I have tried Ascii/Arc grids, Geotiff, erdas imagine,

Re: [gdal-dev] python bindings, no netcdf support

2009/11/9 Hessel Winsemius h.c.winsem...@gmail.com: Does anyone know how to let the python bindings know that it should work with the NetCDF driver as well? I have netcdf4-python installed by the way. The installation of netcdf4-python doesn't interact with GDAL. You'll need to build GDAL

Re: [gdal-dev] Python bindings

Had a similar problem in the past that I resolved like this: $ gdalinfo --formats gdalinfo: error while loading shared libraries: libgdal.so.1: cannot open shared object file: No such file or directory -- Is the lib acessible outside of gdal? $ /sbin/ldconfig -p | grep gdal --nuffin... Let's

[gdal-dev] Python bindings

Hi, I am having trouble running GDAL's Python bindings. I compiled the trunk with the option --with-python. Below is some output from my command line. I am running this on a newly installed system. It has only 2.6 version of Python and python-setuptools. --

Re: [gdal-dev] Python bindings on RedHat cluster (was: AttributeError: 'MaskedArray' object has no attribute 'typecode' -- when writing GeoTiff)

Hi Greg, It's always a good idea to communicate via the list, there are more eyes and skills there. The conversations are also publicly archived, making it easier for others having similar problems to search for help. In this case, the mistake is mine, I see that this list behaves differently to

[gdal-dev] Python bindings for 1.6.0

First of all, many thanks and congratulations to the GDAL team for getting the 1.6.0 release out the door. A special thanks to those of you who fixed the OGR bugs I opened recently. I am eager to try out the final release Python bindings for win32 for Python 2.4, 2.5, and 2.6. Do you know when