Select to view content in your preferred language

Creating correct format of json for Renderer.fromJson

981
2
04-26-2022 10:09 AM
JohnFannon
Frequent Contributor

Hi

I've been experimenting with how to apply renderers to various locally stored data that are loaded as feature layers. I would like to retreive the layer symbology from a configuration file or similar and don't want to hard-code like in many of the samples.

It appears one way to do this would be to use the Renderer.fromJson(string) static method to generate the renderer from stored json and then apply it to the layer. There is no documentation on what format is required as input for Renderer.fromJson(string), but I have done some experiementation and found the following:

1) The json format for the renderer returned from a feature service published from the same data in Pro seems to work. This is similar to what is used in the JS API.

2) The json format for the renderer that is used in the mmap file that is part of an mmpk created from the same data also seems to work.

3) The json format used in a layer file (.lyrx) created from the same data in Pro does not work.

So my questions are:

A) Is there a better way to store and apply symbology to layers in the .net API?

B) If not, then is there a better way to generate the required renderer json for each layer, preferably from Pro?

I feel certain someone else will have attempted similar, so any thoughts/experience appreciated.

Thanks

John

Tags (3)
0 Kudos
2 Replies
DominiqueBroux
Esri Frequent Contributor

Using Renderer.fromJson(string) is a reasonable approach if you don't want to use the fined grained API to create a renderer.
You will find the renderer specifications and many examples of json renderers here: https://developers.arcgis.com/web-map-specification/objects/renderer/

JohnFannon
Frequent Contributor

Thanks a useful link, thanks. Though I was hoping for a way to generate the required renderer json from ArcGIS Pro or something similar, but perhaps that's not possible. It seems like with the mobile SDKs you are largely left to your own devices with regards to symbology etc.

0 Kudos