Hello, 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.
Thanks! A2014197040000.L2_LAC.SeAHABS.hdf <https://docs.google.com/file/d/0B3MWv8orIhBnbElMVzFTRVktRGc/edit?usp=drive_web> A2014197040500.L2_LAC.SeAHABS.hdf <https://docs.google.com/file/d/0B3MWv8orIhBnWTB5SXF6Skc5djQ/edit?usp=drive_web> A2014197041000.L2_LAC.SeAHABS.hdf <https://docs.google.com/file/d/0B3MWv8orIhBnNko3UWp3ekZHYXc/edit?usp=drive_web> A2014197054000.L2_LAC.SeAHABS.hdf <https://docs.google.com/file/d/0B3MWv8orIhBnd0pqZ0NoblBiLXM/edit?usp=drive_web> A2014197054500.L2_LAC.SeAHABS.hdf <https://docs.google.com/file/d/0B3MWv8orIhBndzdGb1VGZHBta00/edit?usp=drive_web> On Mon, Sep 1, 2014 at 1:40 PM, <[email protected]> wrote: > Send gdal-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. Re: OGR C API Spy (Even Rouault) > 2. Appveyor Windows Continuous Integration (Even Rouault) > 3. Re: OGR C API Spy (Robert Coup) > 4. Re: OGR C API Spy (Even Rouault) > 5. Re: Problem encountered in stitching/merging the raster files > (user_name) > 6. Re: Problem encountered in stitching/merging the raster files > (Jukka Rahkonen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 31 Aug 2014 21:14:15 +0200 > From: Even Rouault <[email protected]> > To: Robert Coup <[email protected]> > Cc: GDAL List <[email protected]> > Subject: Re: [gdal-dev] OGR C API Spy > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="utf-8" > > 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_L_GetNextFeature( OGRLayerH hLayer ) > > { > VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL ); > > #ifdef OGRAPISPY_ENABLED > if( bOGRAPISpyEnabled ) > OGRAPISpy_L_GetNextFeature(hLayer); > #endif > > return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature(); > } > > I cannot imagine something with less overhead. (if you exclude dynamic > binary > patching techniques ;-) ) > > OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that tests > if > the env. variable is set, and if so set the boolean bOGRAPISpyEnabled. > > Even > > > > > Rob :) > > > > > > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault < > [email protected]> > > > > wrote: > > > 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 bugs, but > > > that I had issues to replicate afterwards. This spy mechanism enables > to > > > have > > > recording of all relevant calls to be able to replicate them exactly > > > afterwards. > > > > > > Doc to use it : http://www.gdal.org/ograpispy_8h.html > > > > > > Related autotest script : > > > http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py > > > > > > Even > > > > > > -- > > > Spatialys - Geospatial professional services > > > http://www.spatialys.com > > > _______________________________________________ > > > gdal-dev mailing list > > > [email protected] > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > > > ------------------------------ > > Message: 2 > Date: Sun, 31 Aug 2014 21:38:10 +0200 > From: Even Rouault <[email protected]> > To: GDAL List <[email protected]> > Subject: [gdal-dev] Appveyor Windows Continuous Integration > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="us-ascii" > > 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 for the free > (as > in free beer) profile... I've managed to make it work with debug builds > that > run in 25 minutes. So no time to run tests. Results can be seen at > https://ci.appveyor.com/project/rouault/gdal-coverage . > This is still interesting since it uses Visual Studio 2013 (a.k.a VC12 / > MSVC > 1800), which Tamas doesn't yet use on http://www.gisinternals.com/sdk/ > Contrary to Travis-CI, there's no IRC notification yet in Appveyor > unfortunately, so you have to watch the previous mentionned URL. I could > perhaps enable email notices to [email protected], but did not > do > it for know. > A new build will be launched everytime my cron job runs (i.e. every 15 > minutes) *and* something has been committed in SVN. > > I've also updated http://trac.osgeo.org/gdal/wiki/Buildbot (which is badly > named now...) with all the various C.I. setups that currently exist. > > Note: some time ago I also experimented with Visual Studio Express 2005 and > 2008 under Wine. https://travis-ci.org/rouault/vcexpress2005 and > https://travis-ci.org/rouault/vcexpress2008. I didn't enable them on each > commit, since I'm not sure downloading the compiler and sdk from MS each > time > is a good idea... The builds were faster than with Appveyor (quite ironical > !). And for some reason I couldn't manage to install Python under Wine > once VS > is installed. So no autotest too. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > > > ------------------------------ > > Message: 3 > Date: Mon, 1 Sep 2014 08:44:00 +1200 > From: Robert Coup <[email protected]> > To: Even Rouault <[email protected]> > Cc: GDAL List <[email protected]> > Subject: Re: [gdal-dev] OGR C API Spy > Message-ID: > < > cafllrplw5ngjroruggwz+kf5k0euytdoacrypb8xmj5vsf1...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> > wrote: > > > 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_L_GetNextFeature( OGRLayerH hLayer ) > > > > { > > VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL ); > > > > #ifdef OGRAPISPY_ENABLED > > if( bOGRAPISpyEnabled ) > > OGRAPISpy_L_GetNextFeature(hLayer); > > #endif > > > > return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature(); > > } > > > > I cannot imagine something with less overhead. (if you exclude dynamic > > binary > > patching techniques ;-) ) > > > > OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that > tests > > if > > the env. variable is set, and if so set the boolean bOGRAPISpyEnabled. > > > > Even > > > > > > > > Rob :) > > > > > > > > > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault < > > [email protected]> > > > > > > wrote: > > > > 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 bugs, but > > > > that I had issues to replicate afterwards. This spy mechanism enables > > to > > > > have > > > > recording of all relevant calls to be able to replicate them exactly > > > > afterwards. > > > > > > > > Doc to use it : http://www.gdal.org/ograpispy_8h.html > > > > > > > > Related autotest script : > > > > http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py > > > > > > > > Even > > > > > > > > -- > > > > Spatialys - Geospatial professional services > > > > http://www.spatialys.com > > > > _______________________________________________ > > > > gdal-dev mailing list > > > > [email protected] > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > > > > > -- > > *Koordinates*PO Box 1604, Shortland St, Auckland 1140, New Zealand > Phone +64-9-966 0433 koordinates.com <https://koordinates.com/about> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140901/e7014a88/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Sun, 31 Aug 2014 22:52:50 +0200 > From: Even Rouault <[email protected]> > To: Robert Coup <[email protected]> > Cc: GDAL List <[email protected]> > Subject: Re: [gdal-dev] OGR C API Spy > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="utf-8" > > 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() vs IRasterIO(). In OGR, that only exists now with CreateLayer() > / > ICreateLayer() (change done during RFC46) > > > though I > > guess callgrind/linux-perf can do it - do you have any experience worth > > sharing there? > > Hum, my OGR API Spy hasn't been design to do performance profiling. That > would > require a pre- and post- calls. > Long time ago, I had use callgrind, but not with GDAL. Works, slowly, and > AFAIR can only measure CPU time, whereas GDAL does typically lots of I/O, > so > CPU time isn't always very significant. A more lightweight and faster > solution > that I've sometimes used is sysprof (not sure this is really maintained). > Only > sees CPU activity too. > > > > > Rob. > > > > > > On Mon, Sep 1, 2014 at 7:14 AM, Even Rouault <[email protected] > > > > > > wrote: > > > 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_L_GetNextFeature( OGRLayerH hLayer ) > > > > > > { > > > > > > VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL ); > > > > > > #ifdef OGRAPISPY_ENABLED > > > > > > if( bOGRAPISpyEnabled ) > > > > > > OGRAPISpy_L_GetNextFeature(hLayer); > > > > > > #endif > > > > > > return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature(); > > > > > > } > > > > > > I cannot imagine something with less overhead. (if you exclude dynamic > > > binary > > > patching techniques ;-) ) > > > > > > OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that > > > tests if > > > the env. variable is set, and if so set the boolean bOGRAPISpyEnabled. > > > > > > Even > > > > > > > Rob :) > > > > > > > > > > > > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault < > > > > > > [email protected]> > > > > > > > wrote: > > > > > 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 bugs, but > > > > > that I had issues to replicate afterwards. This spy mechanism > enables > > > > > > to > > > > > > > > have > > > > > recording of all relevant calls to be able to replicate them > exactly > > > > > afterwards. > > > > > > > > > > Doc to use it : http://www.gdal.org/ograpispy_8h.html > > > > > > > > > > Related autotest script : > > > > > http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py > > > > > > > > > > Even > > > > > > > > > > -- > > > > > Spatialys - Geospatial professional services > > > > > http://www.spatialys.com > > > > > _______________________________________________ > > > > > gdal-dev mailing list > > > > > [email protected] > > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > > > Spatialys - Geospatial professional services > > > http://www.spatialys.com > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > > > ------------------------------ > > Message: 5 > Date: Sun, 31 Aug 2014 21:03:50 -0700 (PDT) > From: user_name <[email protected]> > To: [email protected] > Subject: Re: [gdal-dev] Problem encountered in stitching/merging the > raster files > Message-ID: > < > camzeyl5sv5fnvrpbk8mlu6tp4xvmnd-5ndrbwz7j0qe9s7i...@mail.gmail.com> > Content-Type: text/plain; charset="us-ascii" > > 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 OSGeo.org] < > [email protected]> wrote: > > > user_name <ljvillarin30 <at> gmail.com> writes: > > > > > > > > I've tried your suggestion but then the result was this: > > > Note: I used OpenEV to open the file. > > > > > > <http://osgeo-org.1560.x6.nabble.com/file/n5158992/openev.gif> > > > > Hi, > > > > Result looks like it is because the black slivers which are created by > > warping are not made transparent. Have a try by adding -dstnodata 0 0 0 > to > > the gdalwarp command. > > > > -Jukka Rahkonen- > > > > _______________________________________________ > > gdal-dev mailing list > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5159142&i=0> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > ------------------------------ > > If you reply to this email, your message will be added to the discussion > > below: > > > > > http://osgeo-org.1560.x6.nabble.com/Problem-encountered-in-stitching-merging-the-raster-files-tp5158957p5159142.html > > To unsubscribe from Problem encountered in stitching/merging the raster > > files, click here > > < > http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5158957&code=bGp2aWxsYXJpbjMwQGdtYWlsLmNvbXw1MTU4OTU3fC03MDA3NDA3OTM= > > > > . > > NAML > > < > 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 > > > > > > > transparent.tif (77K) < > http://osgeo-org.1560.x6.nabble.com/attachment/5159338/0/transparent.tif> > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Re-Problem-encountered-in-stitching-merging-the-raster-files-tp5159338.html > Sent from the GDAL - Dev mailing list archive at Nabble.com. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140831/701cb8f4/attachment-0001.html > > > > ------------------------------ > > Message: 6 > Date: Mon, 1 Sep 2014 05:39:51 +0000 (UTC) > From: Jukka Rahkonen <[email protected]> > To: [email protected] > Subject: Re: [gdal-dev] Problem encountered in stitching/merging the > raster files > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > user_name <ljvillarin30 <at> 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 confused too. You get two blocks, western one combined from two images > and eastern one combined from three images. For me it looks that the blocks > do not meet simply because your original satellite images do not cover that > internal area and the image which you attached to your firs mail shows all > the image data that you have. For total coverage you should acquire more > images into your mosaic. Correct me if you are sure that your originals > cover also the middle area. > > -Jukka Rahkonen- > > > > ------------------------------ > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > End of gdal-dev Digest, Vol 123, Issue 64 > ***************************************** >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
