&gt; What about an approach where the out-of-bound values are assigned the last<br>
&gt; value only if reprojection is used (and if the layer does not have a null<br>
&gt; value)?<br><br>My two cents, from a user perspective.<br>We&#39;re facing this dilemma with Geotools, where reprojected color mapped rasters (thorugh SLD) result with borders having the lower color from the SLD rastersymbolizer. This is a big problem for many users, and we have to reproject the raster before serving it.<br>
It would be very important to be able to manage nodata values for out-of-border pixels, to be able to manage transparency and avoid those ugly borders...<br><br>giovanni<br><br><div class="gmail_quote">2011/1/18 Marco Hugentobler <span dir="ltr">&lt;<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">&gt; Agreed, int to double conversion could be optimal.<br>
<br>
</div>oops, that should be &#39;Agreed, int to double conversion could be problematic&#39;<br>
<br>
Am Dienstag, 18. Januar 2011, um 09.19:23 schrieb Marco Hugentobler:<br>
<div><div></div><div class="h5">&gt; &gt; I thought that if data type of the source is integer the provider<br>
&gt; &gt; could represent them as floating point. Byte can be represented as<br>
&gt; &gt; integer. Bad solution however.<br>
&gt;<br>
&gt; Agreed, int to double conversion could be optimal.<br>
&gt;<br>
<br>
&gt;<br>
&gt; This would be quite similar to your current approach, except that people<br>
&gt; will have the appropriate raster appearance if they don&#39;t use reproj. And<br>
&gt; if they do, they have an undesired border, but still the right colors in<br>
&gt; the raster area.<br>
&gt;<br>
&gt; Regards,<br>
&gt; Marco<br>
&gt;<br>
&gt; Am Montag, 17. Januar 2011, um 17.34:22 schrieb Radim Blazek:<br>
&gt; &gt; On Mon, Jan 17, 2011 at 10:06 AM, Marco Hugentobler<br>
&gt; &gt; &lt;<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a>&gt; &gt; Using NaN sounds like a good idea<br>
&gt; &gt; and Qt has platform independent support for<br>
&gt; &gt;<br>
&gt; &gt; &gt; it (qIsNan &amp; co.).<br>
&gt; &gt; &gt; All other solutions I can think of seem to be more complicated (e.g.<br>
&gt; &gt; &gt; force a transparency value only if raster is reprojected).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt;float + NaN for byte/int?<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; This is not clear to me. Could you explain your approach for byte/int?<br>
&gt; &gt;<br>
&gt; &gt; I thought that if data type of the source is integer the provider<br>
&gt; &gt; could represent them as floating point. Byte can be represented as<br>
&gt; &gt; integer. Bad solution however.<br>
&gt; &gt;<br>
&gt; &gt; Radim<br>
<br>
<br>
--<br>
Dr. Marco Hugentobler<br>
Sourcepole -  Linux &amp; Open Source Solutions<br>
Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland<br>
<a href="mailto:marco.hugentobler@sourcepole.ch">marco.hugentobler@sourcepole.ch</a> <a href="http://www.sourcepole.ch" target="_blank">http://www.sourcepole.ch</a><br>
Technical Advisor QGIS Project Steering Committee<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br>