[gdal-dev] gdal-dev Digest, Vol 123, Issue 64
user_name
ljvillarin30 at gmail.com
Tue Sep 2 19:38:24 PDT 2014
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!
On Mon, Sep 1, 2014 at 1:40 PM, <gdal-dev-request at lists.osgeo.org> wrote:
> Send gdal-dev mailing list submissions to
> gdal-dev at lists.osgeo.org
>
> 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
> gdal-dev-request at lists.osgeo.org
>
> You can reach the person managing the list at
> gdal-dev-owner at lists.osgeo.org
>
> 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 <even.rouault at spatialys.com>
> To: Robert Coup <robert.coup at koordinates.com>
> Cc: GDAL List <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] OGR C API Spy
> Message-ID: <201408312114.15354.even.rouault at spatialys.com>
> 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 <
> even.rouault at spatialys.com>
> >
> > 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
> > > gdal-dev at lists.osgeo.org
> > > 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 <even.rouault at spatialys.com>
> To: GDAL List <gdal-dev at lists.osgeo.org>
> Subject: [gdal-dev] Appveyor Windows Continuous Integration
> Message-ID: <201408312138.10607.even.rouault at spatialys.com>
> 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 gdal-commits at lists.osgeo.org, 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 <robert.coup at koordinates.com>
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: GDAL List <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] OGR C API Spy
> Message-ID:
> <
> CAFLLRpLW5ngjroRUGGwz+Kf5K0eUYtdoACrypB8xMJ5vSF1vkA at 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 <even.rouault at spatialys.com>
> 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 <
> > even.rouault at spatialys.com>
> > >
> > > 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
> > > > gdal-dev at lists.osgeo.org
> > > > 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 <even.rouault at spatialys.com>
> To: Robert Coup <robert.coup at koordinates.com>
> Cc: GDAL List <gdal-dev at lists.osgeo.org>
> Subject: Re: [gdal-dev] OGR C API Spy
> Message-ID: <201408312252.50664.even.rouault at spatialys.com>
> 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 <even.rouault at spatialys.com
> >
> >
> > 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 <
> > >
> > > even.rouault at spatialys.com>
> > >
> > > > 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
> > > > > gdal-dev at lists.osgeo.org
> > > > > 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 <ljvillarin30 at gmail.com>
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Problem encountered in stitching/merging the
> raster files
> Message-ID:
> <
> CAMZEyL5sv5FnVrPbK8MLU6Tp4XvMND-5ndRbwZ7J0Qe9S7iaVA at 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] <
> ml-node+s1560n5159142h49 at n6.nabble.com> 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 <jukka.rahkonen at mmmtike.fi>
> To: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] Problem encountered in stitching/merging the
> raster files
> Message-ID: <loom.20140901T063843-87 at post.gmane.org>
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> End of gdal-dev Digest, Vol 123, Issue 64
> *****************************************
>
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-gdal-dev-Digest-Vol-123-Issue-64-tp5159766.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/20140902/216ae2f8/attachment-0001.html>
More information about the gdal-dev
mailing list