LegendInfoListModel roles not accessible when iterating over legendinfos

[Anonymous User]

https://developers.arcgis.com/qt/latest/qml/api-reference/qml-esri-arcgisruntime-legendinfolistmodel...

Looking at the LegendInfoListModel, it exposes a number of roles, one of which is the "symbolUrl", which I can successfully access when using the legendinfolistmodel.

However, if I fetch a legendinfo from that model, it doesn't have that symbolUrl role. Is there any way I can access that role outside of the model?

I tried calling forEach on the model, or using the get() method which both return a legendinfo object, but of course that doesn't have the role.

I want a listview filtered to just show certain legendinfos on the fly (based on a search term). My current work around is to set the listview model to the legendinfolistmodel, but then set the visible and height properties of the delegate to hide anything that doesn't match my search term. But the first thing I tried to do was iterate through them and push the matching ones into a new ListModel.

Any ideas on a way to access the symbolUrl and copy it out from the LegendInfoListModel?

[LucasDanzinger · Accepted solution]

Roles are only a concept within the list models themselves. If you iterate through the LegendInfo objects, you will get a name string and a Symbol object. To get the symbol "swatch", call createSwatch on the Symbol, and the swatchImage URL will be returned - https://developers.arcgis.com/qt/latest/qml/api-reference/qml-esri-arcgisruntime-symbol.html#swatchI...

[Anonymous User]

Thanks for that.

Is there any way to get a better quality image out of the legend?

In this particular screenshot, the very two first entries are actually pointing directly to png's on disk, and are displaying nice and crisp. The remaining ones (from ATM down) are pulled directly from the LegendInfoListModel. You can see they are quite fuzzy, and for some reason have a grey outline/halo that doesn't exist in the original source icons.

The data source here is a point layer in an mmpk.

[Anonymous User]

Following up on this:

On map load, I call fetchLegendInfos on the layer in question. This populates the LegendInfoListModel with symbolUrl, which I can verify by using a repeater with a delegate that shows each image using that list model and it's symbolUrl and it displays the symbols (albeit not very good quality). so all good there.

But I then tried iterating over the legendInfo's in the list model. I tried console logging out the swatchImage which gives nothing (since I had already called fetchLegendInfos I kind of expected them to be populated already??). Then I called createSwatch() on each one, and hooked up a function to the swatchImageChanged() signal that just logged out the swatchImage. The function fires, but the swatchImage never spits out a url.

In summary, I can't seem to access the swatchImage of a symbol of a legendInfo at all.

If I can do that, I have now noticed that there is a SwatchOptions property, which potentially could allow me to control the quality of the "swatch" that is created, which could resolve my initial issue which is directly related to quality of that image.

so a couple of things: is there a code sample that shows how to access the swatchImage url of each symbol, and/or how to re-create them with higher quality swatches? And is there any way to control this at the initial time of calling fetchLegendInfos on the layer? e.g. ideally you would be able to tell the actual LegendInfoListModel the size swatches I want prior to actually calling fetchLegendInfos() at all - does that make sense?

cheers,

-Paul

[LucasDanzinger]

Hi Paul-

The autoFetchLegendInfos property is something we added as a convenience to have it fetch everything and populate the model for you. If you'd like to customize further, you can drill down the legendInfoListModel of each layer and manually call fetchLegendInfos on each Layer. This is async, so you'll need to wait until it is done before accessing it - https://developers.arcgis.com/qt/latest/qml/api-reference/qml-esri-arcgisruntime-legendinfolistmodel...

With that said, I've been playing around with SwatchOptions, because that is what is designed to give you the flexibility to change image size and scale, but it doesn't seem to be working properly. We will need to look into this further.  

- Lucas

[Anonymous User]

So I had called "fetchLegendInfo" directly on the layer in question, and waited for the async to complete, but yeah seemed to run into issues with the SwatchOptions.

I guess my uncertainty now is still around how it is supposed to happen: is it supposed to be possible to set the SwatchOptions for all symbols on a given layer, or do you have to iterate through each symbol in the legendinfomodel and set the SwatchOptions on each symbol? I'm hoping there's a way to do the former, as that would be easier and make more sense.

[LucasDanzinger]

The fine-grained controls (setting additional options on the symbol swatch) are at the Symbol level. To make it simpler, Qt added the autoFetchLegendInfos property as a convenience method to go fetch them all for you, but it will just use defaults for the swatch image. What is the workflow you are after? Does autoFetchLegendInfos work for you, only you want different defaults? 

[Anonymous User]

In my mind, the workflow I'd expect would be:

1. Get a reference to the layer
2. Update the SwatchOptions (for the layer, *not* individual symbols)
3. Call "fetchLegendInfos" on that particular layer, which would regenerate the swatches for all symbols in that layer.

Does that make sense?

Or, if "autoFetchLegendInfos" is set to true, then perhaps the 3rd step would happen automatically if someone changed the SwatchOptions.

For my use case, I would be assuming the same SwatchOptions for all symbols for a given layer. I guess someone else would still have a requirement for different SwatchOptions at an individual symbol level too? So perhaps this would mean introducing a new concept of a "default" SwatchOption at the layer level that could still be over-ridden at the Symbol level.

[LucasDanzinger]

Sounds like a good enhancement. Thanks for the details. First thing we need to get going is making the SwatchOptions work with the current API, as this functionality seems broken as it stands.