nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Runtime SDK for .NET 200.0 No Label Deconfliction Strategy?

KyleGruberItc

Running into an issue where the .NET Runtime SDK (WPF) map does not seem to be taking any sort of deconfliction strategy for labels into account, and just piling all of them on top of each other.

Map in Runtime SDK:

Map in ArcGIS Pro:

I am aware and appreciate that ArcGIS Pro and Runtime SDK use two very different map displays, but I need to try to understand how to get the two a bit closer than what is being shown. Do I need to explicitly set JSON definitions for labels, does this information not come over in MMPKs?

Encuentra más publicaciones etiquetadas con

Accepted answers

RichardJShepherd

Hi, @KyleGruberItc .

Thanks for sharing your data so we could understand why Runtime labeling was ignoring the expected label deconfliction.

In this case, the key setting was the label class being set to `Background` labeling in ArcGISPro.

`Background` labels are all placed first (avoiding each other), and then all the `Foreground` label classes have their labels placed (avoiding each each other but ignoring, and possibly overlapping, the `Background` labels).

Unfortunately, this amount of detailed placement is not carried out in Runtime and a only a simplified version of the settings is published in the mmpk.

In particular, if `Background` is set in the label class, then the ArcGISPro publishing sets the mmpk labeling setting `allowOverlapOfLabel` to `allow`. This makes sense for the main intent of Background labels to be used as watermark labels (e.g. large polygon labels) but misses their ability to deconflict from each other.

Another difference between the maps is the use of Overrun. In ArcGISPro, your label class has a very small (1pt) overrun set, so labels should stay almost entirely on their features.

In Runtime you see the labels running further off the ends of the street features.

This is because Runtime labeling only has `allowOverrun`:`true`/`false` and no distance setting yet. When the mmpk is published any label class overrun causes `allowOverrun` to be set to `true`.

Unfortunately, if you wanted to avoid this and set your overrun distance to 0 in the aprx, it would work (i.e. stop any overrun), but you would lose all your labels because of a different limitation. The line connection algorithm in Runtime SDK labeling not as powerful as that in ArcGISPro and is unable to join all the small line features before trying to place the large labels along multiple features. So your best compromise at the moment is probably to keep the overrun.

We will continue to enhance the labeling support in the Runtime SDK to better respect that authored in ArcGISPro and queries such as your help us to adjust priorities.

All comments

KyleGruber

@RichardJShepherd @PreetiMaske

Sorry to respond to such an old thread, but is there any update on MMPK storing overrun values and the engine's ability to support it? It would cut down on a tremendous amount of work and make the labeling engine (especially when it comes to street labeling) much more intuitive.

KyleGruberItc

@RichardJShepherd

Thank you for this incredibly thoughtful and helpful response. I'm very happy to hear that there are people who understand the limitations and differences between the labeling engines in ArcGIS Pro and Runtime SDK and that effort is being put in to making them closer.

@RichardJShepherd wrote:
Hi, @KyleGruberItc .

Thanks for sharing your data so we could understand why Runtime labeling was ignoring the expected label deconfliction.

In this case, the key setting was the label class being set to `Background` labeling in ArcGISPro.
`Background` labels are all placed first (avoiding each other), and then all the `Foreground` label classes have their labels placed (avoiding each each other but ignoring, and possibly overlapping, the `Background` labels).

This in particular was a very helpful bit of information. Background label features is not something I have ever used directly. Turning this off is definitely getting the labeling in Runtime to behave more as expected. I suspect running dissolve or a similar tool on the centerline will further help the labeling function as expected, so segments like this:

Look and behave more like this:

RichardJShepherd

Hi, @KyleGruberItc .

Thanks for sharing your data so we could understand why Runtime labeling was ignoring the expected label deconfliction.

In this case, the key setting was the label class being set to `Background` labeling in ArcGISPro.

Unfortunately, this amount of detailed placement is not carried out in Runtime and a only a simplified version of the settings is published in the mmpk.

Another difference between the maps is the use of Overrun. In ArcGISPro, your label class has a very small (1pt) overrun set, so labels should stay almost entirely on their features.

In Runtime you see the labels running further off the ends of the street features.

This is because Runtime labeling only has `allowOverrun`:`true`/`false` and no distance setting yet. When the mmpk is published any label class overrun causes `allowOverrun` to be set to `true`.

We will continue to enhance the labeling support in the Runtime SDK to better respect that authored in ArcGISPro and queries such as your help us to adjust priorities.

PreetiMaske

You can send the files to pmaske@esri.com. It will be helpful if you can also briefly describe your workflow in the email.

KyleGruberItc

@PreetiMaske Yes, I would be happy to do this. The project and MMPK were both created with ArcGIS Pro 3.0.3. Please let me know what the ideal way to share the ARPX and MMPK would be. Thank you!

PreetiMaske

I will be happy to look into this further and see what's going on 🙂 . Is it possible for you to share your ArcGIS Pro project and MMPK you published. Please specify ArcGIS Pro version that you used to create the Pro project and the MMPK.

KyleGruberItc

I will begrudgingly admit that reading the documentation was actually pretty helpful in this case.

Enum LabelOverlapStrategy (arcgis.com)

Setting this to Exclude on all layers gets the map much closer to the behavior in ArcGIS Pro. It's not identical, but it's acceptable.

Update: Upon loading the MMPK, I am subscribing to each layer load and setting the overlap strategy based on the geometry type. This feels counterintuitive, but currently it seems like nothing from the original map comes over from the original map for the label strategies in the MMPK.

foreach (var ld in layer.LabelDefinitions)
                {
                    if (layer.FeatureTable?.GeometryType == GeometryType.Polyline || layer.FeatureTable?.GeometryType == GeometryType.Point)
                        ld.LabelOverlapStrategy = Esri.ArcGISRuntime.Mapping.Labeling.LabelOverlapStrategy.Exclude;
                    else
                        ld.LabelOverlapStrategy = Esri.ArcGISRuntime.Mapping.Labeling.LabelOverlapStrategy.Avoid;
                }

This still creates an undesirable effect of some polygon labels just plotting right on top of each other for seemingly no reason.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.