InMemoryFeatureLayer with zoom specific labels

[Russ]

I have a fairly complex map with various InMemoryFeatureLayer instances providing various dynamic features. In some of those layers, I have hooked up a handler for layer.DrawingFeatures where I mostly just decide what to display for that label based on current state and user “mode”.

Anyway, one of the annoying features of my current implementation is that when zoomed out, the features are close together and the labels just stack obscuring everything.

Basically I would ideally want to determine whether enough space exists to reasonably present the label, and simply not draw it at all if things are “too crowded”. The definition of “too crowded” is TBD, but clearly depends on size of label vs screen space. It wouldn’t be perfect, but this might take the form of something like “if 1/2” of screen space is > 100’ of world space, then the objects are likely too close together, so don’t draw the labels". Or maybe draw condensed labels with abbreviated content, or ??? That or something similar would produce a reasonably good chance that the labels will not interfere overly much, and I could make the threshold user configured.

Alternately, it could be that I draw the labels only when zoomed in to a lever greater than zoomLevel8, though that would be less ideal since it would be harder for the user to understand, .and the full view extent for some maps is different from others, so the point at which the labels start showing up would vary by a substantial range.

But those are just the ideas I had when I started looking at this. However, it seems like the pieces I need to figure this out are not readily available for my label drawing method hooked to layer.DrawingFeatures. Can you provide some guidance on this?

[Ethan]

Hi Russ,

It’s not easy to handle the label, just like you mentioned, the text size in screen need be calculated based on the zoomlevel(if you set different size for different zoomlevel) and font etc.

And you should put the logic in some function for example DrawCore of your custom text style.

But the problem is your custom logic is hard to handle the label between different layers.

In fact if you don’t want to make the label looks not too crowded, why not directly set the properties for text style:

OverlappingRule:
This defines the rules for label overlapping. Currently, either we allow overlapping or we do not. In the future, we may extend this to allow some percentage of partial overlapping.

GridSize:
The grid size determines how many labels will be considered as candidates for drawing. The smaller the grid size, the higher the density of candidates. Making the grid size too small may have a performance impact.

Our property will works for all layers in the same overlay.

And if you want to add your logic, you can write your custom style, override the function for example: CheckOverlappingCore

Then add your custom logic in it.

Wish that’s helpful.

Regards,

Ethan

[Russ]

I did some mock ups with the OverlappingRule (etc), and the product owner did not like that at all. Unless I missed some knob somewhere, there seems to be no way around the "some labels show up, then zoom in and some more show up, zoom again for a few more, and because of quite a few very close objects, we don’t get everything until you hit the last 2 or 3 almost max zoomed in levels.

We need them all to come in at once, and if a few obscure each other such that the user can’t identify them (mostly can due to context), then they can zoom until they can identify the problem labels.

So, if I’m not missing something, it seems like handling in the style is the only real option. At that point, what layer is drawing isn’t so much an issue as what zoom level we are at. We have 20 zoom levels.

During an interactive discussion with the product owner, reviewing a few of the most problematic maps, he said that he want’s the objects to be visible regardless of zoom, but have all the labels for those objects appear only when zoomed in 6-8 or more levels.

[Russ]

Never mind. I got it working in a manner acceptable to the product owner by flipping it over. Instead of trying to decide when to draw labels or not based on zoom or scale inside the style, I just changed the code to set up each zoom level with text styles (or not) based on the zoom level specified. It’s not completely ideal, but much better than it was.

[Ethan]

Hi Russ,

Thanks for your update, based on the further information your solution a good idea. In fact our API design is ask user to set different style for different zoomlevel, we do it in our WorldMapKit in version 9 and before. In most scenario, user only need to set one style and assign it to all 20 levels, but set different styles can get better effect.

Regards,

Ethan