Hello folks,
I recently tried to use the GDAL 1.9.0 API from multiple threads. However, they
may arise a deadlock situation
where one thread hangs in the cpl_multithread.cpp CPLAcquireMutex function and
others hang in the pj_acquire_lock() function of the proj.4 4.7.0 API blocking
each other.
Hello,
I develop an application using Gdal dlls (to read grib file and DTED
and VMAP shape...).
This application is developed with Visual Studio 2008 in C# .NET 3.5.
I want to port this appli in a linux CentOS 5.5 but I have an error
when I execute this .exe with mono.
I have just deplace
Selon Roger Phillips heid...@hotmail.com:
You didn't mention which OS you are using, but if it is Windows, I believe you
are running into this proj4 bug : http://trac.osgeo.org/proj/ticket/63
It is now fixed, but no 4.7.1 or 4.8.0 release has been made since the fix has
been applied, so you have
Hi,
I think, OGR (and therefore MapServer too), is not taking care about
axis orientation of incomming data, acting as WFS 1.1 client. Result is
flipped data and I do not know, how the software recognizes, that axes
order is different (apperently, it does not).
We have setuped generic WFS 1.1
Le jeudi 09 février 2012 20:00:03, Jachym Cepicky a écrit :
Hi,
I think, OGR (and therefore MapServer too), is not taking care about
axis orientation of incomming data, acting as WFS 1.1 client. Result is
flipped data and I do not know, how the software recognizes, that axes
order is
Is the problematic case you cite rather common or the exceptional?
Perhaps the -wm option is a good place to set a lower memory limit in
this case, with the default being higher (instead of the other way
around)?
Unless we install a spy in gdalwarp that sends reports to a server, nobody
so I have created a config file for gdalenhance
color.config:
1:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120
120:0.429:190 190:0.231:255
2:Band -100:ScaleMin 11000:ScaleMax 0:3.667:30 30:1.667:60 60:0.833:120
120:0.429:190 190:0.231:255
3:Band -100:ScaleMin
