[Qgis-user] Raster Calculator bug?

Fri Jul 31 14:44:42 PDT 2015

Hi Nick,
in fact I don't think there is a bug in the calculator. It is rather the 
legend confusing you. I agree that while calculating there might be some 
bias with floating number conversation - it got me either. Otherwise 
when I use this approach:

"m at 1" < 238 AND "m at 1" > 210 AND "m at 2" < 123 AND "m at 2" > 94 AND "m at 3" < 
130 AND "m at 3" > 98

I get a perfectly fitting 0/1 raster. Only that the automated legend 
settings do not fit. When setting the layer-Style-properties to 
"pseudocolor", color interpretation to "exact" and then add a class with 
value "1" then it shows correct.

Just don't use greyscale. Maybe the settings for Greyscale can be 
tweeked. Whatsoever, I haven't used that by now. Maybe someone else has 
an explanation for this behaviour. Or maybe can explain how to set the 
parameters.

cheers

Stefan

Am 31.07.2015 um 17:31 schrieb Nick Papadonis:
> Hi Stefan,
>
>> On Jul 31, 2015, at 9:37 AM, Stefan Kiefer <st_kiefer at web.de 
>> <mailto:st_kiefer at web.de>> wrote:
>>
>> Hi Nick,
>> back to office I was eager to try by myself. Actually it seems that 
>> the result of multiple AND or multiple layers - I didn't check this 
>> by now - results in values slightly lower 1 (e.g. 0.9995 in my case). 
>> And therefore maybe rounded to "0". What I have done is the folowing:
>>
>
> Thanks! I did try your suggestion and it provided me the results I was 
> seeking of only showing the red routes:
>
> (1/("map at 1" < 238 AND "map at 1" > 210)) + (1/("map at 2" < 123 AND "map at 2" 
> > 94)) + (1/("map at 3" < 130 AND "map at 3" > 98))
>
> Perhaps my math is fuzzy.  Why would the divisor resolve this 
> situation whereas multiplier in following has problems?
>
> ((“m at 1" < 238 AND “m at 1" > 210) * 1) * ((“m at 2" < 123 AND “m at 2" > 94) * 
> 1) * ((“m at 3" < 130 AND “m at 3" > 98) * 1)
>
> The floating point values is a why I believe we have a rounding bug in 
> Raster Calculator.  I suspect that during the calculation a number is 
> converted to floating point, between 0 and 1 (eg 0.9995), and that 
> causes the equation to result in all 0s.  Its unusual that the 
> calculator is performing floating point math because these are all 
> integer values being operated on by value comparison operators and 
> other integer numbers without any division which would cause floating 
> point conversion or multiplication by a floating point.  The numbers 
> are all whole integers.  I was hoping the original author could chime 
> in on the tool and perhaps this is a bug.
>
> I’m on Mac OSX using 2.10.1 release and see same results on 2.8 release.
>
> I’m suspecting this may be a bug related to:
>
> Raster calculator always returns float32 tiffs
> https://hub.qgis.org/issues/10965
> Raster calculator produces only 0 values with conditional expression
> https://hub.qgis.org/issues/11682
>
> There is this suggestion on the mailing list of how to resolve, 
> however am a bit confused on the methods.  The workaround may be to 
> reproject the raster layer and I’m unsure why that’s required:
> http://lists.osgeo.org/pipermail/qgis-user/2014-November/029873.html
> http://lists.osgeo.org/pipermail/qgis-user/2014-November/029878.html
>
> Thanks again,
> Nick
>
>> (1/("pm2-5-europe-2001-2010 at 1">240 AND 
>> "pm2-5-europe-2001-2010 at 1"<250))*(1/("pm2-5-europe-2001-2010 at 2">139 
>> AND "pm2-5-europe-2001-2010 at 2"<145)) * 
>> (1/("pm2-5-europe-2001-2010 at 3">80 AND "pm2-5-europe-2001-2010 at 3"<85))
>>
>> which results in a perfektly fitting mask of my pseudo demand.
>> Mayby you could verfy this with your data
>>
>> cheers
>>
>> Stefan
>>
>> Am 31.07.2015 um 08:48 schrieb Stefan Kiefer:
>>> Hi Nick,
>>> you are absolutely right. My thought was, that you get A layer with 
>>> distinct values to identify the road. For a mask you are on the 
>>> right way, and I either don't understand the behaviour except that 
>>> you operate over three layers, which of course should work.
>>> Have you tryed to generate a composit of the three layers and mask 
>>> the single values resulting for road structures? (it's more or less 
>>> what I expected from my first approach.)
>>> cheers
>>> Stefan
>>>
>>> > Nick Papadonis <npapadonis at gmail.com> hat am 31. Juli 2015 um 
>>> 08:31 geschrieben:
>>> >
>>> >
>>> > Hi Stefan,
>>> >
>>> > It’s my understanding black has a value of 0 in the resulting layer.
>>> >
>>> > I tried this and it results in similar image to step (a) and also 
>>> includes other colors at lower intensities mixed in with the red. 
>>> The red has the highest intensity in the greyscale. I’m looking to 
>>> create a binary image with just the colors of red in the palette I 
>>> choose and using this trace vectors over the paths.
>>> >
>>> > Thanks,
>>> > Nick
>>> >
>>> > > On Jul 31, 2015, at 2:04 AM, Stefan Kiefer <st_kiefer at web.de> wrote:
>>> > >
>>> > > Hi Nick,
>>> > > I believe it is black bcause you always get a value of "1". 
>>> Unfortunately I can not verify this, because I have no QGis by this 
>>> moment. Most propably you wanted to calculate:
>>> > >
>>> > > (“m at 1" < 238 AND “m at 1" > 213 AND “m at 2" < 123 AND “m at 2" > 98 AND 
>>> “m at 3" < 125 AND “m at 3” > 99) * ((“m at 1" < 238 AND “m at 1" > 210) * 
>>> "m at 1") + ((“m at 2" < 123 AND “m at 2" > 94) * “m at 2") + ((“m at 3" < 130 AND 
>>> “m at 3" > 98) *“m at 3"))
>>> > >
>>> > > cheers
>>> > >
>>> > > Stefan
>>> > >
>>> > > > Nick Papadonis <npapadonis at gmail.com> hat am 31. Juli 2015 um 
>>> 07:49 geschrieben:
>>> > > >
>>> > > >
>>> > > > One more comment. The resulting layer histogram is showing the 
>>> pixel range spread over frequency in floating point values. Is the 
>>> raster calculator performing floating point math with potential 
>>> rounding error?
>>> > > >
>>> > > > I found it also interesting that the following expression 
>>> resulted in a layer, which when inspected for band values, has 
>>> integer values of 2 and 3. 3 being the value I want for the red route.
>>> > > >
>>> > > > a) ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND 
>>> “m at 2" > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1)
>>> > > >
>>> > > > I then change the expression to only use values 2 and greater 
>>> and this shows properly:
>>> > > > b) ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND 
>>> “m at 2" > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1) > 2
>>> > > >
>>> > > > I then changed the expression to ensure all three values are 
>>> obtained and it results in a black image of 0’s. I was expecting 
>>> only the red route to appear as it resulted in value of 3 in step (a).
>>> > > >
>>> > > > ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND “m at 2" 
>>> > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1) > 2.1
>>> > > > ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND “m at 2" 
>>> > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1) >= 3
>>> > > >
>>> > > > I’m wondering how much testing the Raster Calculator has gone 
>>> through and if there is a possible bug here. Perhaps something to do 
>>> with floating point?
>>> > > >
>>> > > > Thanks again
>>> > > >
>>> > > > > On Jul 31, 2015, at 12:39 AM, Nick Papadonis 
>>> <npapadonis at gmail.com> wrote:
>>> > > > >
>>> > > > > Folks,
>>> > > > >
>>> > > > > I’m using QGIS 10.1. The following expressions result in a 
>>> black raster of 0’s, when I expected only red pixels to appears in 
>>> the binary image indicating routes on a map:
>>> > > > >
>>> > > > > a) (“m at 1" < 238 AND “m at 1" > 213 AND “m at 2" < 123 AND “m at 2" > 
>>> 98 AND “m at 3" < 125 AND “m at 3” > 99) * 1
>>> > > > > b) ((“m at 1" < 238 AND “m at 1" > 210) * 1) * ((“m at 2" < 123 AND 
>>> “m at 2" > 94) * 1) * ((“m at 3" < 130 AND “m at 3" > 98) * 1)
>>> > > > >
>>> > > > > I then tried the following individual expressions for each 
>>> band as separate steps (sanity check) and they work to cover the 
>>> pixels in range:
>>> > > > > c) (“m at 1" < 238 AND “m at 1" > 213) * 1
>>> > > > > d) (“m at 2" < 123 AND “m at 2" > 98) * 1
>>> > > > > e) (“m at 3" < 125 AND “m at 3” > 99) * 1
>>> > > > >
>>> > > > > I then tried the following expression which appears to 
>>> create a proper greyscale image focusing on the red pixels. I 
>>> replaced the multiplication with addition to see what was happening:
>>> > > > > f) ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND 
>>> “m at 2" > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1)
>>> > > > >
>>> > > > > The resulting raster has a Min = 0 and Max = 1.998. I was 
>>> expecting it to be Min = 0 and Max = 3. The value of 3 would 
>>> indicate all 3 bands were positive on color match. I then go to the 
>>> layer properties and load calculate min/max again and it is Min = 0 
>>> and Max = 3. I tried to change the min/max settings on they layer 
>>> and these settings will not stay set. The layer goes back to Max = 
>>> 1.998. What’s even more odd is the max being a floating point 
>>> number. I suspect that may be part of the issue. Anyone know why 
>>> this is the case for integer band values? Has anyone successfully 
>>> used the Raster Calculator to perform this sort of work before?
>>> > > > >
>>> > > > > Thanks again,
>>> > > > > Nick
>>> > > >
>>> > > > _______________________________________________
>>> > > > Qgis-user mailing list
>>> > > > Qgis-user at lists.osgeo.org
>>> > > > http://lists.osgeo.org/mailman/listinfo/qgis-user
>>> >
>>>
>>>
>>> _______________________________________________
>>> Qgis-user mailing list
>>> Qgis-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org <mailto:Qgis-user at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20150731/56abe1ec/attachment.html>