2011/3/28 Kirk McKelvey
> Tamas,
>
>
>
> I believe this was happening because of a known issue allocating DLL
> objects on the heap. I have made the stream objects into member variables
> to work around this problem on the trunk (r22052). Let me know if your
> tests continue to fail.
>
>
Kirk,
Dear GDAL heroes,
I have encountered a very strange behaviour of the python bindings. I am using
version 1.7.3 with Python 2.6 on a OpenSuse 11 64bits.
We developped an in-house C++ python accessor and I get a segmentation fault
at a very bizarre place.
I am launching following minimal python
On Mon, Mar 28, 2011 at 6:02 PM, katrin eggert
wrote:
> Greetings
> I saw that a new GDAL18 was launched and it's available for windows. I would
> like to know if it's already available a GDAL binary that I can run without
> need of OSGEO or anything like that (just like you have done for GDAL15).
Hi all,
Sorry for the unnecessary mail to the already very full contribution list...
It also crashes after a second call to any other module...
So somehow, my accessor let any python module run 2 commands and crash at the
third... o_O
Still very strange, but on my side, no problem with GDAL here
Greetings
I saw that a new GDAL18 was launched and it's available for windows. I would
like to know if it's already available a GDAL binary that I can run without
need of OSGEO or anything like that (just like you have done for GDAL15).
Thanks
Kat
___
gd
Tamas,
I believe this was happening because of a known issue allocating DLL objects on
the heap. I have made the stream objects into member variables to work around
this problem on the trunk (r22052). Let me know if your tests continue to fail.
Kirk.
From: Tamas Szekeres [mailto:szeker...@gm
Hello
I got a reply to my message stating that " GDAL ignores a flag in the
GEOTIF specification that says whether the coordinates are for the center or
the lower-left of each pixel. "
Is this true? It's exacly what I am obtaining and what Markus Neteler
explained me (about the useage of NN metho
