[gdal-dev] [python] CopyDataSource question

[Even Rouault]

Le mardi 20 décembre 2011 14:33:26, Frank Broniewski a écrit :
> I am sorry that I was not precise enough in my previous email. On my
> development system (Debian 6, Python 2.6, gdal 1.7.3) my scripts work as
> expected. My server (Ubuntu 8.04, Python 2.5, gdal 1.8.0) has the
> problems running the test. On both systems I am using package
> repositories, though on Ubuntu it is the non official UbuntuGIS repo.
> 
> Using the OGR API directly, that means without my wrapper functions and
> classes, I can successfully use CopyDataSource() on both systems.
> So the issue lies within the manner how I use the OGR API. I will need
> to find out the differences between the OGR-only approach and mine but
> that will probably take a while. After that I can hopefully provide a
> not working test code with data.

Hum, perhaps you are  running into one of the gotchas listed (non exhaustive 
list) in : http://trac.osgeo.org/gdal/wiki/PythonGotchas

But I'd be surprised that you don't see the same behaviour with 1.7.3 or 
1.8.0. The objet lifecycle management hasn't evolved that much during the last 
decade ;-)

> 
> Concerning the debugging: How can I find out if my gdal version comes
> with the debugging symbols?

Distro versions generally don't go with debugging symbols. There might be 
additional packages with debug symbols, but I'm not sure on Debian based 
systems. Otherwise, you'd better compile a version by yourself. Trying GDAL 
1.9.0beta1 might be a usefull exercice ;-)

> 
> Many thanks
> 
> Frank
> 
> Am 20.12.2011 13:16, schrieb Even Rouault:
> > Frank,
> > 
> >> Hi,
> >> 
> >> I have (again) a question concerning the Driver.CopyDataSource() method
> >> using OGR Python bindings
> >> 
> >> I've written some code that copies a datasource to another format, using
> >> a target driver and its CopyDataSource() method. This works fine for
> >> GDAL version 1.7.3, but fails under 1.8.0. Failing means that the
> >> CopyDataSource call is made but never finishes. It just sits there and
> >> does nothing. This is however related to *my code*, and *not* an OGR
> >> error.
> > 
> > Reading your further explanations, it is difficult to know if it's a
> > problem in your code, or in OGR.
> > 
> >> Doing the task with OGR classes directly works.
> > 
> > What do you mean by "with OGR classes" ? Do you mean when not using
> > CopyDataSource() ?
> > 
> >> But I wonder why
> >> my script runs fine on one system but not on the other.
> > 
> > One system with 1.7.3 and the other with 1.8.0 ?
> > 
> >> I have some sample test data with which I test my code. The sample is a
> >> point shapefile and I copy it to GeoJSON, GML and KML formats. The
> >> GeoJSON still works, but the GML test fails, and KML also.
> >> 
> >> So my question (at last ;-)): What could make the CopyDataSource fail
> >> with GML and KML, but succeed with GeoJSON? And make it completely
> >> succeed under GDAL 1.7.3?
> > 
> > That stalling in CopyDataSource() doesn't sound good. I've no ready-made
> > explanation for this. Would you be able to create a minimalistic
> > standalone python script of just a few lines of code (not your entire
> > python code), with associated test data, that can be used to replicate
> > the issue ?
> > 
> > Which OS do you use ? Did you compile GDAL by yourself or do you use a
> > binary distribution ?
> > 
> > Provided you have a version of the GDAL librairy with debugging symbols,
> > you could try attaching a debugger to the process and observe what
> > happens step by step in CopyDataSource().
> > 
> >> Looking at ogr2ogr.py, CopyDataSource is never used there.
> > 
> > Yes, ogr2ogr offer more options and can do more advanced transformations
> > than CopyDataSource() can do, so it needs control at the layer and
> > feature level.
> > 
> >> Am I abusing
> >> CopyDataSource? Is it the right tool to copy a datasource to a new
> >> format?
> > 
> > CopyDataSource() is very basic, but it should work for what it is
> > supposed to do, and not block forever.
> > 
> > Best ragards,
> > 
> > Even