<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Hello,<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">
<br>I've decided to attached here the five hdf files which I used in stitching. I just converted into GTiff and warped. Definitely, the two blocks doesn't meet but I'm just not sure if these covers the middle area as what you've said. You could give it a try if you can stitch these well.<br>
<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks!<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 1:40 PM, <span dir="ltr"><<a href="mailto:gdal-dev-request@lists.osgeo.org" target="_blank">gdal-dev-request@lists.osgeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send gdal-dev mailing list submissions to<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gdal-dev-request@lists.osgeo.org">gdal-dev-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:gdal-dev-owner@lists.osgeo.org">gdal-dev-owner@lists.osgeo.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gdal-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: OGR C API Spy (Even Rouault)<br>
2. Appveyor Windows Continuous Integration (Even Rouault)<br>
3. Re: OGR C API Spy (Robert Coup)<br>
4. Re: OGR C API Spy (Even Rouault)<br>
5. Re: Problem encountered in stitching/merging the raster files<br>
(user_name)<br>
6. Re: Problem encountered in stitching/merging the raster files<br>
(Jukka Rahkonen)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 31 Aug 2014 21:14:15 +0200<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
To: Robert Coup <<a href="mailto:robert.coup@koordinates.com">robert.coup@koordinates.com</a>><br>
Cc: GDAL List <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
Subject: Re: [gdal-dev] OGR C API Spy<br>
Message-ID: <<a href="mailto:201408312114.15354.even.rouault@spatialys.com">201408312114.15354.even.rouault@spatialys.com</a>><br>
Content-Type: Text/Plain; charset="utf-8"<br>
<br>
Le dimanche 31 ao?t 2014 20:50:41, Robert Coup a ?crit :<br>
> That's cool :) Is there any particular performance penalty to compiling<br>
> *with* OGRAPISPY_ENABLED and then running *without*<br>
> OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH<br>
> set?<br>
<br>
Hi Robert,<br>
<br>
Hopefully no, see for example :<br>
<br>
OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer )<br>
<br>
{<br>
VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL );<br>
<br>
#ifdef OGRAPISPY_ENABLED<br>
if( bOGRAPISpyEnabled )<br>
OGRAPISpy_L_GetNextFeature(hLayer);<br>
#endif<br>
<br>
return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature();<br>
}<br>
<br>
I cannot imagine something with less overhead. (if you exclude dynamic binary<br>
patching techniques ;-) )<br>
<br>
OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that tests if<br>
the env. variable is set, and if so set the boolean bOGRAPISpyEnabled.<br>
<br>
Even<br>
<br>
><br>
> Rob :)<br>
><br>
><br>
> On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > Hi,<br>
> ><br>
> > This will not be of interest for the crowds, but mainly for OGR driver<br>
> > developers (and potentially also to get precise bug reports from users).<br>
> > I'm<br>
> > currently adding update capabilities to the MITAB driver, and while<br>
> > playing with QGIS, there are sometimes sequences of OGR calls that<br>
> > trigger bugs, but<br>
> > that I had issues to replicate afterwards. This spy mechanism enables to<br>
> > have<br>
> > recording of all relevant calls to be able to replicate them exactly<br>
> > afterwards.<br>
> ><br>
> > Doc to use it : <a href="http://www.gdal.org/ograpispy_8h.html" target="_blank">http://www.gdal.org/ograpispy_8h.html</a><br>
> ><br>
> > Related autotest script :<br>
> > <a href="http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py" target="_blank">http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py</a><br>
> ><br>
> > Even<br>
> ><br>
> > --<br>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 31 Aug 2014 21:38:10 +0200<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
To: GDAL List <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
Subject: [gdal-dev] Appveyor Windows Continuous Integration<br>
Message-ID: <<a href="mailto:201408312138.10607.even.rouault@spatialys.com">201408312138.10607.even.rouault@spatialys.com</a>><br>
Content-Type: Text/Plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
I've just experimented with Appveyor, a hosted continuous integration solution<br>
for Windows to do Windows GDAL builds. This is not completely convincing,<br>
since a optimized build of GDAL, without any optional dependency, takes more<br>
than 30 minutes, and then gets killed since this is the limit for the free (as<br>
in free beer) profile... I've managed to make it work with debug builds that<br>
run in 25 minutes. So no time to run tests. Results can be seen at<br>
<a href="https://ci.appveyor.com/project/rouault/gdal-coverage" target="_blank">https://ci.appveyor.com/project/rouault/gdal-coverage</a> .<br>
This is still interesting since it uses Visual Studio 2013 (a.k.a VC12 / MSVC<br>
1800), which Tamas doesn't yet use on <a href="http://www.gisinternals.com/sdk/" target="_blank">http://www.gisinternals.com/sdk/</a><br>
Contrary to Travis-CI, there's no IRC notification yet in Appveyor<br>
unfortunately, so you have to watch the previous mentionned URL. I could<br>
perhaps enable email notices to <a href="mailto:gdal-commits@lists.osgeo.org">gdal-commits@lists.osgeo.org</a>, but did not do<br>
it for know.<br>
A new build will be launched everytime my cron job runs (i.e. every 15<br>
minutes) *and* something has been committed in SVN.<br>
<br>
I've also updated <a href="http://trac.osgeo.org/gdal/wiki/Buildbot" target="_blank">http://trac.osgeo.org/gdal/wiki/Buildbot</a> (which is badly<br>
named now...) with all the various C.I. setups that currently exist.<br>
<br>
Note: some time ago I also experimented with Visual Studio Express 2005 and<br>
2008 under Wine. <a href="https://travis-ci.org/rouault/vcexpress2005" target="_blank">https://travis-ci.org/rouault/vcexpress2005</a> and<br>
<a href="https://travis-ci.org/rouault/vcexpress2008" target="_blank">https://travis-ci.org/rouault/vcexpress2008</a>. I didn't enable them on each<br>
commit, since I'm not sure downloading the compiler and sdk from MS each time<br>
is a good idea... The builds were faster than with Appveyor (quite ironical<br>
!). And for some reason I couldn't manage to install Python under Wine once VS<br>
is installed. So no autotest too.<br>
<br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 1 Sep 2014 08:44:00 +1200<br>
From: Robert Coup <<a href="mailto:robert.coup@koordinates.com">robert.coup@koordinates.com</a>><br>
To: Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
Cc: GDAL List <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
Subject: Re: [gdal-dev] OGR C API Spy<br>
Message-ID:<br>
<<a href="mailto:CAFLLRpLW5ngjroRUGGwz%2BKf5K0eUYtdoACrypB8xMJ5vSF1vkA@mail.gmail.com">CAFLLRpLW5ngjroRUGGwz+Kf5K0eUYtdoACrypB8xMJ5vSF1vkA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Excellent :)<br>
<br>
There's obviously no nice run-time solution using the C++ API, though I<br>
guess callgrind/linux-perf can do it - do you have any experience worth<br>
sharing there?<br>
<br>
Rob.<br>
<br>
<br>
On Mon, Sep 1, 2014 at 7:14 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
wrote:<br>
<br>
> Le dimanche 31 ao?t 2014 20:50:41, Robert Coup a ?crit :<br>
> > That's cool :) Is there any particular performance penalty to compiling<br>
> > *with* OGRAPISPY_ENABLED and then running *without*<br>
> > OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH<br>
> > set?<br>
><br>
> Hi Robert,<br>
><br>
> Hopefully no, see for example :<br>
><br>
> OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer )<br>
><br>
> {<br>
> VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL );<br>
><br>
> #ifdef OGRAPISPY_ENABLED<br>
> if( bOGRAPISpyEnabled )<br>
> OGRAPISpy_L_GetNextFeature(hLayer);<br>
> #endif<br>
><br>
> return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature();<br>
> }<br>
><br>
> I cannot imagine something with less overhead. (if you exclude dynamic<br>
> binary<br>
> patching techniques ;-) )<br>
><br>
> OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that tests<br>
> if<br>
> the env. variable is set, and if so set the boolean bOGRAPISpyEnabled.<br>
><br>
> Even<br>
><br>
> ><br>
> > Rob :)<br>
> ><br>
> ><br>
> > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault <<br>
> <a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
> ><br>
> > wrote:<br>
> > > Hi,<br>
> > ><br>
> > > This will not be of interest for the crowds, but mainly for OGR driver<br>
> > > developers (and potentially also to get precise bug reports from<br>
> users).<br>
> > > I'm<br>
> > > currently adding update capabilities to the MITAB driver, and while<br>
> > > playing with QGIS, there are sometimes sequences of OGR calls that<br>
> > > trigger bugs, but<br>
> > > that I had issues to replicate afterwards. This spy mechanism enables<br>
> to<br>
> > > have<br>
> > > recording of all relevant calls to be able to replicate them exactly<br>
> > > afterwards.<br>
> > ><br>
> > > Doc to use it : <a href="http://www.gdal.org/ograpispy_8h.html" target="_blank">http://www.gdal.org/ograpispy_8h.html</a><br>
> > ><br>
> > > Related autotest script :<br>
> > > <a href="http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py" target="_blank">http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py</a><br>
> > ><br>
> > > Even<br>
> > ><br>
> > > --<br>
> > > Spatialys - Geospatial professional services<br>
> > > <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
> > > _______________________________________________<br>
> > > gdal-dev mailing list<br>
> > > <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
> --<br>
> Spatialys - Geospatial professional services<br>
> <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
><br>
<br>
<br>
<br>
--<br>
<br>
*Koordinates*PO Box 1604, Shortland St, Auckland 1140, New Zealand<br>
Phone <a href="tel:%2B64-9-966%200433" value="+6499660433">+64-9-966 0433</a> <a href="http://koordinates.com" target="_blank">koordinates.com</a> <<a href="https://koordinates.com/about" target="_blank">https://koordinates.com/about</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140901/e7014a88/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140901/e7014a88/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sun, 31 Aug 2014 22:52:50 +0200<br>
From: Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
To: Robert Coup <<a href="mailto:robert.coup@koordinates.com">robert.coup@koordinates.com</a>><br>
Cc: GDAL List <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>><br>
Subject: Re: [gdal-dev] OGR C API Spy<br>
Message-ID: <<a href="mailto:201408312252.50664.even.rouault@spatialys.com">201408312252.50664.even.rouault@spatialys.com</a>><br>
Content-Type: Text/Plain; charset="utf-8"<br>
<br>
Le dimanche 31 ao?t 2014 22:44:00, Robert Coup a ?crit :<br>
> Excellent :)<br>
><br>
> There's obviously no nice run-time solution using the C++ API,<br>
<br>
Yes, that could be possible if the C++ public API had redirection to driver<br>
implementation methods. In GDAL, we have that with some methods like<br>
RasterIO() vs IRasterIO(). In OGR, that only exists now with CreateLayer() /<br>
ICreateLayer() (change done during RFC46)<br>
<br>
> though I<br>
> guess callgrind/linux-perf can do it - do you have any experience worth<br>
> sharing there?<br>
<br>
Hum, my OGR API Spy hasn't been design to do performance profiling. That would<br>
require a pre- and post- calls.<br>
Long time ago, I had use callgrind, but not with GDAL. Works, slowly, and<br>
AFAIR can only measure CPU time, whereas GDAL does typically lots of I/O, so<br>
CPU time isn't always very significant. A more lightweight and faster solution<br>
that I've sometimes used is sysprof (not sure this is really maintained). Only<br>
sees CPU activity too.<br>
<br>
><br>
> Rob.<br>
><br>
><br>
> On Mon, Sep 1, 2014 at 7:14 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > Le dimanche 31 ao?t 2014 20:50:41, Robert Coup a ?crit :<br>
> > > That's cool :) Is there any particular performance penalty to compiling<br>
> > > *with* OGRAPISPY_ENABLED and then running *without*<br>
> > > OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH<br>
> > > set?<br>
> ><br>
> > Hi Robert,<br>
> ><br>
> > Hopefully no, see for example :<br>
> ><br>
> > OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer )<br>
> ><br>
> > {<br>
> ><br>
> > VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL );<br>
> ><br>
> > #ifdef OGRAPISPY_ENABLED<br>
> ><br>
> > if( bOGRAPISpyEnabled )<br>
> ><br>
> > OGRAPISpy_L_GetNextFeature(hLayer);<br>
> ><br>
> > #endif<br>
> ><br>
> > return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature();<br>
> ><br>
> > }<br>
> ><br>
> > I cannot imagine something with less overhead. (if you exclude dynamic<br>
> > binary<br>
> > patching techniques ;-) )<br>
> ><br>
> > OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that<br>
> > tests if<br>
> > the env. variable is set, and if so set the boolean bOGRAPISpyEnabled.<br>
> ><br>
> > Even<br>
> ><br>
> > > Rob :)<br>
> > ><br>
> > ><br>
> > > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault <<br>
> ><br>
> > <a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
> ><br>
> > > wrote:<br>
> > > > Hi,<br>
> > > ><br>
> > > > This will not be of interest for the crowds, but mainly for OGR<br>
> > > > driver developers (and potentially also to get precise bug reports<br>
> > > > from<br>
> ><br>
> > users).<br>
> ><br>
> > > > I'm<br>
> > > > currently adding update capabilities to the MITAB driver, and while<br>
> > > > playing with QGIS, there are sometimes sequences of OGR calls that<br>
> > > > trigger bugs, but<br>
> > > > that I had issues to replicate afterwards. This spy mechanism enables<br>
> ><br>
> > to<br>
> ><br>
> > > > have<br>
> > > > recording of all relevant calls to be able to replicate them exactly<br>
> > > > afterwards.<br>
> > > ><br>
> > > > Doc to use it : <a href="http://www.gdal.org/ograpispy_8h.html" target="_blank">http://www.gdal.org/ograpispy_8h.html</a><br>
> > > ><br>
> > > > Related autotest script :<br>
> > > > <a href="http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py" target="_blank">http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py</a><br>
> > > ><br>
> > > > Even<br>
> > > ><br>
> > > > --<br>
> > > > Spatialys - Geospatial professional services<br>
> > > > <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
> > > > _______________________________________________<br>
> > > > gdal-dev mailing list<br>
> > > > <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > > > <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> ><br>
> > --<br>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sun, 31 Aug 2014 21:03:50 -0700 (PDT)<br>
From: user_name <<a href="mailto:ljvillarin30@gmail.com">ljvillarin30@gmail.com</a>><br>
To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
Subject: Re: [gdal-dev] Problem encountered in stitching/merging the<br>
raster files<br>
Message-ID:<br>
<<a href="mailto:CAMZEyL5sv5FnVrPbK8MLU6Tp4XvMND-5ndRbwZ7J0Qe9S7iaVA@mail.gmail.com">CAMZEyL5sv5FnVrPbK8MLU6Tp4XvMND-5ndRbwZ7J0Qe9S7iaVA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I tried adding -dstnodata 0 to gdalwarp(I just add one 0 because it has<br>
only 1 band.Am I doing the right thing?) I have attached here the output.<br>
It really didn't stitch/mosaic well. The output is still the same. I'm<br>
really confused?<br>
<br>
<br>
<br>
<br>
On Sat, Aug 30, 2014 at 12:31 AM, Rahkonen Jukka (Tike) [via OSGeo.org] <<br>
<a href="mailto:ml-node%2Bs1560n5159142h49@n6.nabble.com">ml-node+s1560n5159142h49@n6.nabble.com</a>> wrote:<br>
<br>
> user_name <ljvillarin30 <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
><br>
> ><br>
> > I've tried your suggestion but then the result was this:<br>
> > Note: I used OpenEV to open the file.<br>
> ><br>
> > <<a href="http://osgeo-org.1560.x6.nabble.com/file/n5158992/openev.gif" target="_blank">http://osgeo-org.1560.x6.nabble.com/file/n5158992/openev.gif</a>><br>
><br>
> Hi,<br>
><br>
> Result looks like it is because the black slivers which are created by<br>
> warping are not made transparent. Have a try by adding -dstnodata 0 0 0 to<br>
> the gdalwarp command.<br>
><br>
> -Jukka Rahkonen-<br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> [hidden email] <<a href="http://user/SendEmail.jtp?type=node&node=5159142&i=0" target="_blank">http://user/SendEmail.jtp?type=node&node=5159142&i=0</a>><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
> ------------------------------<br>
> If you reply to this email, your message will be added to the discussion<br>
> below:<br>
><br>
> <a href="http://osgeo-org.1560.x6.nabble.com/Problem-encountered-in-stitching-merging-the-raster-files-tp5158957p5159142.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/Problem-encountered-in-stitching-merging-the-raster-files-tp5158957p5159142.html</a><br>
> To unsubscribe from Problem encountered in stitching/merging the raster<br>
> files, click here<br>
> <<a href="http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5158957&code=bGp2aWxsYXJpbjMwQGdtYWlsLmNvbXw1MTU4OTU3fC03MDA3NDA3OTM=" target="_blank">http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5158957&code=bGp2aWxsYXJpbjMwQGdtYWlsLmNvbXw1MTU4OTU3fC03MDA3NDA3OTM=</a>><br>
> .<br>
> NAML<br>
> <<a href="http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" target="_blank">http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml</a>><br>
><br>
<br>
<br>
transparent.tif (77K) <<a href="http://osgeo-org.1560.x6.nabble.com/attachment/5159338/0/transparent.tif" target="_blank">http://osgeo-org.1560.x6.nabble.com/attachment/5159338/0/transparent.tif</a>><br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://osgeo-org.1560.x6.nabble.com/Re-Problem-encountered-in-stitching-merging-the-raster-files-tp5159338.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/Re-Problem-encountered-in-stitching-merging-the-raster-files-tp5159338.html</a><br>
Sent from the GDAL - Dev mailing list archive at Nabble.com.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140831/701cb8f4/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140831/701cb8f4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 1 Sep 2014 05:39:51 +0000 (UTC)<br>
From: Jukka Rahkonen <<a href="mailto:jukka.rahkonen@mmmtike.fi">jukka.rahkonen@mmmtike.fi</a>><br>
To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
Subject: Re: [gdal-dev] Problem encountered in stitching/merging the<br>
raster files<br>
Message-ID: <<a href="mailto:loom.20140901T063843-87@post.gmane.org">loom.20140901T063843-87@post.gmane.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
user_name <ljvillarin30 <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
<br>
><br>
><br>
><br>
> I tried adding -dstnodata 0 to gdalwarp(I just add one 0 because it has<br>
only 1 band.Am I doing the right thing?) I have attached here the output. It<br>
really didn't stitch/mosaic well. The output is still the same. I'm really<br>
confused?<br>
><br>
><br>
<br>
Hi,<br>
<br>
I am confused too. You get two blocks, western one combined from two images<br>
and eastern one combined from three images. For me it looks that the blocks<br>
do not meet simply because your original satellite images do not cover that<br>
internal area and the image which you attached to your firs mail shows all<br>
the image data that you have. For total coverage you should acquire more<br>
images into your mosaic. Correct me if you are sure that your originals<br>
cover also the middle area.<br>
<br>
-Jukka Rahkonen-<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
End of gdal-dev Digest, Vol 123, Issue 64<br>
*****************************************<br>
</blockquote></div><br></div>