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@1" < 238 AND "m@1" > 210 AND "m@2" < 123 AND "m@2" > 94 AND "m@3" <
130 AND "m@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 <[email protected]
<mailto:[email protected]>> 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@1" < 238 AND "map@1" > 210)) + (1/("map@2" < 123 AND "map@2"
> 94)) + (1/("map@3" < 130 AND "map@3" > 98))
Perhaps my math is fuzzy. Why would the divisor resolve this
situation whereas multiplier in following has problems?
((“m@1" < 238 AND “m@1" > 210) * 1) * ((“m@2" < 123 AND “m@2" > 94) *
1) * ((“m@3" < 130 AND “m@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@1">240 AND
"pm2-5-europe-2001-2010@1"<250))*(1/("pm2-5-europe-2001-2010@2">139
AND "pm2-5-europe-2001-2010@2"<145)) *
(1/("pm2-5-europe-2001-2010@3">80 AND "pm2-5-europe-2001-2010@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 <[email protected]> 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 <[email protected]> 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@1" < 238 AND “m@1" > 213 AND “m@2" < 123 AND “m@2" > 98 AND
“m@3" < 125 AND “m@3” > 99) * ((“m@1" < 238 AND “m@1" > 210) *
"m@1") + ((“m@2" < 123 AND “m@2" > 94) * “m@2") + ((“m@3" < 130 AND
“m@3" > 98) *“m@3"))
> >
> > cheers
> >
> > Stefan
> >
> > > Nick Papadonis <[email protected]> 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@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND
“m@2" > 94) * 1) + ((“m@3" < 130 AND “m@3" > 98) * 1)
> > >
> > > I then change the expression to only use values 2 and greater
and this shows properly:
> > > b) ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND
“m@2" > 94) * 1) + ((“m@3" < 130 AND “m@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@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2"
> 94) * 1) + ((“m@3" < 130 AND “m@3" > 98) * 1) > 2.1
> > > ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2"
> 94) * 1) + ((“m@3" < 130 AND “m@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
<[email protected]> 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@1" < 238 AND “m@1" > 213 AND “m@2" < 123 AND “m@2" >
98 AND “m@3" < 125 AND “m@3” > 99) * 1
> > > > b) ((“m@1" < 238 AND “m@1" > 210) * 1) * ((“m@2" < 123 AND
“m@2" > 94) * 1) * ((“m@3" < 130 AND “m@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@1" < 238 AND “m@1" > 213) * 1
> > > > d) (“m@2" < 123 AND “m@2" > 98) * 1
> > > > e) (“m@3" < 125 AND “m@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@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND
“m@2" > 94) * 1) + ((“m@3" < 130 AND “m@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
> > > [email protected]
> > > http://lists.osgeo.org/mailman/listinfo/qgis-user
>
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________
Qgis-user mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
