Re: [gdal-dev] Problem encountered in stitching/merging the raster files

2014-08-31 Thread Jukka Rahkonen
user_name gmail.com> writes: > > > > I tried adding -dstnodata 0 to gdalwarp(I just add one 0 because it has only 1 band.Am I doing the right thing?) I have attached here the output. It really didn't stitch/mosaic well. The output is still the same. I'm really confused? > > Hi, I am confus

Re: [gdal-dev] Problem encountered in stitching/merging the raster files

2014-08-31 Thread user_name
I tried adding -dstnodata 0 to gdalwarp(I just add one 0 because it has only 1 band.Am I doing the right thing?) I have attached here the output. It really didn't stitch/mosaic well. The output is still the same. I'm really confused? On Sat, Aug 30, 2014 at 12:31 AM, Rahkonen Jukka (Tike) [via

Re: [gdal-dev] OGR C API Spy

2014-08-31 Thread Even Rouault
Le dimanche 31 août 2014 22:44:00, Robert Coup a écrit : > Excellent :) > > There's obviously no nice run-time solution using the C++ API, Yes, that could be possible if the C++ public API had redirection to driver implementation methods. In GDAL, we have that with some methods like RasterIO()

Re: [gdal-dev] OGR C API Spy

2014-08-31 Thread Robert Coup
Excellent :) There's obviously no nice run-time solution using the C++ API, though I guess callgrind/linux-perf can do it - do you have any experience worth sharing there? Rob. On Mon, Sep 1, 2014 at 7:14 AM, Even Rouault wrote: > Le dimanche 31 août 2014 20:50:41, Robert Coup a écrit : > > T

[gdal-dev] Appveyor Windows Continuous Integration

2014-08-31 Thread Even Rouault
Hi, I've just experimented with Appveyor, a hosted continuous integration solution for Windows to do Windows GDAL builds. This is not completely convincing, since a optimized build of GDAL, without any optional dependency, takes more than 30 minutes, and then gets killed since this is the limit

Re: [gdal-dev] OGR C API Spy

2014-08-31 Thread Even Rouault
Le dimanche 31 août 2014 20:50:41, Robert Coup a écrit : > That's cool :) Is there any particular performance penalty to compiling > *with* OGRAPISPY_ENABLED and then running *without* > OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH > set? Hi Robert, Hopefully no, see for example : OGRFeatureH OGR_

Re: [gdal-dev] OGR C API Spy

2014-08-31 Thread Robert Coup
That's cool :) Is there any particular performance penalty to compiling *with* OGRAPISPY_ENABLED and then running *without* OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH set? Rob :) On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault wrote: > Hi, > > This will not be of interest for the crowds, but ma

[gdal-dev] OGR C API Spy

2014-08-31 Thread Even Rouault
Hi, This will not be of interest for the crowds, but mainly for OGR driver developers (and potentially also to get precise bug reports from users). I'm currently adding update capabilities to the MITAB driver, and while playing with QGIS, there are sometimes sequences of OGR calls that trigger