Hi Uwe,
<br><br>I have been trying to use gdal_merge.py to merge a few 8 bit colored .tif tiles together. Having tried all sorts of options for this command, I always ended up with a merged 8-bit grayscale picture. I did a search on the internet and found a couple of posts related to this, however it seemed to me that the gdal_merge.py just does not have the ability to preserve the color. Did I get the wrong idea about this? Do you have any suggestion to solve this problem?
<br><br>Not sure if I should post a separate message for this gdal_merge.py issue. &nbsp;I just thought this would be the quickest way to get the help :)
<br><br>Thanks,
<br>Heng
<br>________________________________
<br>From: Schmitz, Uwe [via OSGeo.org] [<a href="/user/SendEmail.jtp?type=node&node=5954287&i=0" target="_top" rel="nofollow">[hidden email]</a>]
<br>Sent: 17 January 2011 09:22
<br>To: Heng Feng
<br>Subject: AW: [gdal-dev] An issue about using GDALWARP to dotheNTv2transformation
<br><br>Heng,
<br><br>&gt; Hi Uwe,
<br>&gt;
<br>&gt; Hope you had a wonderful Christmas break.
<br><br>Yes, thank you (but I have the impression that mine has
<br>been shorter than yours ;-))
<br><div class='shrinkable-quote'><br>&gt; Regarding the issue about the NTv2 transformation,
<br>&gt; the map data provider has confirmed that the raster
<br>&gt; data do cover some areas which are outside the Germany
<br>&gt; map, hence the area of the grid shift file. &nbsp;I have
<br>&gt; taken your second suggestion and ignore the coordinates
<br>&gt; outside BeTA2007 grid. &nbsp;However, &nbsp;by running the suggested
<br>&gt; command on some raster data, this time I have got the
<br>&gt; &nbsp;message &quot;Inverse grid shift iteration failed, presumably
<br>&gt; at grid edge. Using first approximation.&quot; Do you know
<br>&gt; why I am having this message? Do I need to worry about it?
<br>&gt;
</div>No! NTv2 is based on a grid of shift values from System A
<br>to System B (DHDN -&gt; ETRS89 in your case). For the other
<br>direction (B-&gt;A, or ETRS89-&gt;DHDN) the shift value is
<br>calculated by an iterative approach. Near the grid edges it's
<br>possible that during the iteartion the coordinates fall
<br>outside the grid. I would imagine that this is the case
<br>for the message you see.
<br><br>Assuming you don't need precise transformation results
<br>outside the BeTA2007 grid, you can safely ignore this
<br>message.
<br><br>Regards
<br>Uwe
<br>_______________________________________________
<br>gdal-dev mailing list
<br>[hidden email]&lt;UrlBlockedError.aspx&gt;
<br><a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_top" rel="nofollow" link="external">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br><br><br>________________________________
<br>View message @ <a href="http://osgeo-org.1803224.n2.nabble.com/An-issue-about-using-GDALWARP-to-do-the-NTv2-transformation-tp5838904p5931200.html?by-user=t" target="_top" rel="nofollow" link="external">http://osgeo-org.1803224.n2.nabble.com/An-issue-about-using-GDALWARP-to-do-the-NTv2-transformation-tp5838904p5931200.html</a><br>To unsubscribe from An issue about using GDALWARP to do the NTv2 transformation, click here&lt;<a href="http://osgeo-org.1803224.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5838904&code=aGVuZy5mZW5nQGFpcmNvbWludGVybmF0aW9uYWwuY29tfDU4Mzg5MDR8MTI3MzEwMjEw&by-user=t" target="_top" rel="nofollow" link="external">http://osgeo-org.1803224.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5838904&code=aGVuZy5mZW5nQGFpcmNvbWludGVybmF0aW9uYWwuY29tfDU4Mzg5MDR8MTI3MzEwMjEw</a>&gt;.
<br><br>AIRCOM International
<br>Mobile World Congress 2011, 14-17 February
<br>Stand 1B14, Barcelona, Spain
<br>Click mailto:<a href="/user/SendEmail.jtp?type=node&node=5954287&i=1" target="_top" rel="nofollow">[hidden email]</a>?subject=Mobile%20World%20Congress%20'11%20meeting%20-%20%Appointement%20%Booking to book a meeting
<br><br>Disclaimer: 
<br>This e-mail message is confidential and should not be used by, or disclosed to, anyone except the addressee. If you receive this message in error, please advise us immediately on +44 (0) 1932 442000. Since e-mail transmission is not secure or error free, we do not accept responsibility for changes to any e-mail which occur after it has been sent. Attachments to this e-mail may contain software viruses which could damage your systems. You should therefore virus-check all attachments before opening. AIRCOM may monitor incoming and outgoing emails through its networks and by responding to this email, you consent to such monitoring. The views and opinions expressed in this e-mail are those of the author only and not of AIRCOM. We do not intend to enter into any legal commitments or contracts by e-mail. Registered Office: Cassini Court, Randalls Research Park, Randalls Way, Leatherhead, Surrey, KT22 7TW, UK. AIRCOM International Ltd registered in England No. 3052022. VAT number 811 5323 68.
<br>&nbsp;Save a tree. Don't print this e-mail unless it's really necessary
<br>
<br><hr align="left" width="300">
View this message in context: <a href="http://osgeo-org.1803224.n2.nabble.com/An-issue-about-using-GDALWARP-to-do-the-NTv2-transformation-tp5838904p5954287.html">RE: [gdal-dev] An issue about using GDALWARP to dotheNTv2transformation</a><br>
Sent from the <a href="http://osgeo-org.1803224.n2.nabble.com/GDAL-Dev-f2022644.html">GDAL - Dev mailing list archive</a> at Nabble.com.<br>