How to Change the Colors on a RasterStretchRenderer

2071
6
Jump to solution
08-29-2020 04:23 PM
RyanSutcliffe
Occasional Contributor II

If I have an ImageryLayer or ImageryTileLayer in my ArcGIS JavaScript API map, how do I change the colors of the renderer. Is it possible? I cannot get it to work. 

Here is a CodePen of what I've tried. Basically I'm trying to replace the colorRamp with a new one and then update the renderer. This is basically a copy of an ESRI sample that shows how you can change all other properties of the RasterStretchRenderer on a LERC-based Raster layer. 

I assumed that this was possible as you can change colors and complete styles for SimpleRenderers on vector data. I haven't yet looked at other types of Renderers to see what happens there.

Hoping I don't have to create a new layer. I'd like avoid requiring the client from having to pull all the data down each time the renderer is changed.

Thoughts advice are welcome.

Ryan

0 Kudos
1 Solution

Accepted Solutions
Gianna_BBSRC
Occasional Contributor

Hi Ryan,

It's because you haven't assigned an initial renderer to your layer.

// create initial renderer
let layerRenderer = new RasterStretchRenderer({
    colorRamp: colorRamp,
    stretchType: stretchType
});

// create a ImageryTileLayer from tiled elevation service
const layer = new ImageryTileLayer({
    url: "https://sampleserver6.arcgisonline.com/arcgis/rest/services/Elevation/MtBaldy_Elevation/ImageServer",
    opacity: 0.9,
    renderer: layerRenderer
});‍‍‍‍‍‍‍‍‍‍‍‍

Without it, there's nothing to clone in your updateRenderer function.

View solution in original post

6 Replies
Gianna_BBSRC
Occasional Contributor

Hi Ryan,

It's because you haven't assigned an initial renderer to your layer.

// create initial renderer
let layerRenderer = new RasterStretchRenderer({
    colorRamp: colorRamp,
    stretchType: stretchType
});

// create a ImageryTileLayer from tiled elevation service
const layer = new ImageryTileLayer({
    url: "https://sampleserver6.arcgisonline.com/arcgis/rest/services/Elevation/MtBaldy_Elevation/ImageServer",
    opacity: 0.9,
    renderer: layerRenderer
});‍‍‍‍‍‍‍‍‍‍‍‍

Without it, there's nothing to clone in your updateRenderer function.

RyanSutcliffe
Occasional Contributor II

Thanks for your post @Gianna_BBSRC. Apologies for my delayed response here-- didn't see this come into my inbox. Your post is correct and solves at least part of my problem.  Here is a new code pen with that fix applied (as I understand it). Note though, that now the symbology only changes if you zoom or pan and the original symbology hangs around on the existing tiles? Let me know if you or anyone spots anything wrong looking there.

In my apps I think I've mostly opted to completely reload the layer if I want to change a property like the colorRamp for a renderer to get around this but if there was a way to not need doing that it would be ideal.

0 Kudos
Gianna_BBSRC
Occasional Contributor

Hi Ryan,

This looks like a bug to me. It seems like a caching issue with the tiles. I cleared my browser's cache and selected 'green' before the map loaded completely and got this (without zooming): 

Giannalogy_0-1607436576133.png

I've scripted a few website using a regular ImageryLayer, not ImageryTileLayer, and it updates the renderer automatically. It may be worth raising a new question, or bug report with Esri, to get an answer for this one.

Cheers,

Gianna

0 Kudos
RyanSutcliffe
Occasional Contributor II

Thanks, I will reach out to ESRI Support and post back here any resolution.  As a bit of an aside, there were a few related issue we encountered with changing clientside renderers (not specifically RasterStretchRenderers) on ImageryLayer and other layer types as well. In various circumstances the old styles would hang around. Here is a CodePen of one such case (don't think we ever got this one acknowledged as a bug). Another case that was, I think eventually acknowledged as a bug, was one where if you set up a featurelayer with a certain type of render and definitionExpression but changed it before drawing the layer, the API would insist on fetching and drawing the layer twice (codepen sample, video demo). 

All this is to say why we chose to just reload layers in these circumstances.

0 Kudos
RyanSutcliffe
Occasional Contributor II

Got a prompt response from an ESRI Canada's support rep who pointed that the behaviour has been fixed at ArcGIS JavaScript API 4.17. If you update the above codepen url links to 4.17 you'll see that the caching issue discussed is no longer an issue.

Given that, going to mark @Gianna_BBSRC 's answer as correct. Just remember to use 4.17 or higher

Gianna_BBSRC
Occasional Contributor

Aha! I had half a mind to update it to 4.17 when playing around with the code today. Thanks for finding out!

0 Kudos