[MapServer-users] Distinguish between pixels outside of SCALE range and nodata pixels

[Timothy Kempisty - NOAA Federal]

I assume it would read the data twice.

I suppose the other option is to abandon the PROCESSING SCALE directive
entirely.  Set all your CLASS colors for 10.0 to 20.0 manually.  It can be
tedious to set up, but we do this all the time for scales with 200+ custom
colors.  Then you are free to keep the  "< 10 black" and  "> 20 white"
classes in the same layer.

[pixel] < 10   black
[pixel] < 10.1
[pixel] <10.2
...
[pixel] < 20
[pixel] >= 20   white

For readability purposes, I'd put that big collection of classes in a
separate file, and use  #INCLUDE  to bring it into the LAYER section of the
mapfile.

-Tim

On Mon, Nov 28, 2022 at 9:51 AM Mallinger, Bernhard <
bernhard.mallinger at eox.at> wrote:

> Thank you for the suggestion, this actually achieves the desired effect!
>
> I'm just wondering if this now reads the data twice?
>
> We're using data from remote locations which can be slow to read, so
> reading them twice would be inconvenient.
>
> Best,
> Bernhard
>
>
> On Mon, Nov 28, 2022 at 3:18 PM Timothy Kempisty - NOAA Federal <
> timothy.kempisty at noaa.gov> wrote:
>
>> Try adding a separate background layer using the same data, with CLASS
>> statements only for your out of bounds pixel values.  Simplified a bit here:
>>
>> LAYER
>>     # -- Your existing layer
>>     NAME my_actual_data
>> *    GROUP mydata*
>>     DATA same_data
>>     PROCESSING "SCALE_1=10.0,20.0"
>>
>>     <... yadda yadda ...>
>> END
>>
>> LAYER
>> # -- New layer adds black/white colors where pixel values exceed scale
>> bounds
>>    NAME background
>> *   GROUP mydata*
>>    DATA same_data
>>       CLASS
>>           EXPRESSION ([pixel] < 10)
>>               <...black...>
>>       END
>>       CLASS
>>           EXPRESSION ([pixel] > 20)
>>               <...white...>
>>       END
>> END
>>
>> Display both layers together by requesting the "mydata" group name, just
>> like you would request any other layer.  It will render all layers with the
>> same group name.
>>
>> -Tim
>>
>> On Mon, Nov 28, 2022 at 8:35 AM Mallinger, Bernhard <
>> bernhard.mallinger at eox.at> wrote:
>>
>>> Hello,
>>>
>>> We have maps where we want the color scale go from e.g. 10 to 20, so we
>>> are using this directive:
>>>
>>> PROCESSING "SCALE_1=10.0,20.0"
>>>
>>> This works great by itself, however it also means that pixels with
>>> values of e.g. 5 are rendered as transparent, which is the same as the
>>> nodata pixels. So in the final image, you can't tell if data is present but
>>> the values are too low, or if there just isn't any data.
>>>
>>> So the behaviour we would like is that values below 10 are rendered as
>>> black and values over 20 are rendered as white.
>>>
>>> Is this somehow possible with mapscript?
>>>
>>>
>>> We tried to have a look in the source code, and there is this line,
>>> which effectively assigns 0 to pixels below the minimum:
>>> https://github.com/MapServer/MapServer/blob/main/mapdrawgdal.c#L1555
>>>
>>> It turns out that this small code change actually produces the desired
>>> behavior:
>>>
>>>        fScaledValue = (float) ((pafRawData[i]-dfScaleMin)*dfScaleRatio);        if( fScaledValue < 0.0 )-        pabyBuffer[i] = 0;+        if (pafRawData[i] > 0) {+            pabyBuffer[i] = 1;+        } else {+            pabyBuffer[i] = 0;+        }
>>>
>>> (I.e. if the original value was greater than 0, then assign 1 to this pixel such that it will be black and not transparent.)
>>>
>>> If this behavior can't yet be configured via mapscript, we could work on a pull request to implement this behavior, which would then be activated via a new configuration option.
>>> Do you have any thoughts on this? Does this make sense to you as a feature?
>>>
>>> Best regards,
>>> Bernhard
>>>
>>> _______________________________________________
>>> MapServer-users mailing list
>>> MapServer-users at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20221128/9375361f/attachment.htm>