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.
Concerning the debugging: How can I find out if my gdal version comes
with the debugging symbols?
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
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
