> This is because the svn versioning information for shared libraries is
> not normally "set" until release time (ie. 1.6.0) so it is basically just
> a clone of what it was for 1.5.0 release time.
>
> I could bump the version now in svn but I will almost certainly forget
> I did so at 1.6.0 releas
Andreas Neumann wrote:
Thank you very much - problem solved. There was an indeed an old version
of libgdal around (gdal1.5.2 - also self-compiled under /usr/local/lib)
The strange thing is that the svn trunk version reports as older
(libgdal.so.1.12.0) even if it is newer than gdal1.5.2, which r
Thank you very much - problem solved. There was an indeed an old version
of libgdal around (gdal1.5.2 - also self-compiled under /usr/local/lib)
The strange thing is that the svn trunk version reports as older
(libgdal.so.1.12.0) even if it is newer than gdal1.5.2, which reports as
libgdal.so.1.12
Andreas Neumann wrote:
Hi,
I was compiling gdal with python support from svn-trunk and ran into the
same problem as described at
http://www.nabble.com/Problem-with-gdal_polygonize.py-td19839558.html
When I start a python script I get the following error message:
--
gdal_merge.
Hi,
I was compiling gdal with python support from svn-trunk and ran into the
same problem as described at
http://www.nabble.com/Problem-with-gdal_polygonize.py-td19839558.html
When I start a python script I get the following error message:
--
gdal_merge.py -o orthofoto_2008.tif
