Hi Radim > Why do you consider it problematic, because it occupies too much space? > Regarding precision, int to double is OK, I believe, but long to > double is not because double has only 52bits to store mantissa. GDAL > however does not define long, > the longest integer is GDT_Int32
My concern was because of precision. But maybe its safe. Anyway, your suggestion below seems good to me. >So I suggest: > > source_type -> qgis_type > byte -> byte (if null value is defined) / short (if null value is not > defined) short -> short (if null value is defined) / int (if null value > is not defined) int -> int, if null value is not defined use max value for > null > float -> float, use NaN for null values > double -> double, use NaN for null values +1 Marco Am Dienstag, 18. Januar 2011, um 10.29:00 schrieb Radim Blazek: > On Tue, Jan 18, 2011 at 9:19 AM, Marco Hugentobler > > <marco.hugentob...@sourcepole.ch> wrote: > > oops, that should be 'Agreed, int to double conversion could be > > problematic' > > Why do you consider it problematic, because it occupies too much space? > Regarding precision, int to double is OK, I believe, but long to > double is not because double has only 52bits to store mantissa. GDAL > however does not define long, > the longest integer is GDT_Int32 > > > What about an approach where the out-of-bound values are assigned the > > last value only if reprojection is used (and if the layer does not have > > a null value)? > > Still the problem remains for projected data. > > I think that usually with common data and wider data type like int, > float and double the max value is never used except for some special > values like null. The problem occurs > with shorter types like byte and short. So I suggest: > > source_type -> qgis_type > byte -> byte (if null value is defined) / short (if null value is not > defined) short -> short (if null value is defined) / int (if null value > is not defined) int -> int, if null value is not defined use max value for > null > float -> float, use NaN for null values > double -> double, use NaN for null values > > This is still not 100% solution, but it should cover most common cases. > The only code complication is, that we need a new srcDataType() > provider method, > to return the true data source type. > > Radim > > > This would be quite similar to your current approach, except that people > > will have the appropriate raster appearance if they don't use reproj. > > And if they do, they have an undesired border, but still the right > > colors in the raster area. > > > > Regards, > > Marco > > > > Am Montag, 17. Januar 2011, um 17.34:22 schrieb Radim Blazek: > >> On Mon, Jan 17, 2011 at 10:06 AM, Marco Hugentobler > >> <marco.hugentob...@sourcepole.ch> > Using NaN sounds like a good idea > >> and Qt has platform independent support for > >> > >> > it (qIsNan & co.). > >> > All other solutions I can think of seem to be more complicated (e.g. > >> > force a transparency value only if raster is reprojected). > >> > > >> >>float + NaN for byte/int? > >> >> > >> > This is not clear to me. Could you explain your approach for byte/int? > >> > >> I thought that if data type of the source is integer the provider > >> could represent them as floating point. Byte can be represented as > >> integer. Bad solution however. > >> > >> Radim > > > > -- > > Dr. Marco Hugentobler > > Sourcepole - Linux & Open Source Solutions > > Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland > > marco.hugentob...@sourcepole.ch http://www.sourcepole.ch > > Technical Advisor QGIS Project Steering Committee -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
