[Qgis-user] Raster Calculator bug?
Stefan Kiefer
st_kiefer at web.de
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>
More information about the Qgis-user
mailing list