Locking down specific label locations
I have a need to create labels for features (not annotation) where most of the labels can be placed at the "best location" (according to the Maplex label engine), but where some of the labels should be placed at (or near) a user specified location. I really want to try to avoid annotation feature classes, if at all possible, because for 95% of all features, labels is all I need.
An idea that I have is to create a customization where a user could click on a 5x5 grid that surrounded the feature that was to be labeled. Based on which of the 25 grids they clicked on, the feature would be labeled using a different label class...each class would have a different XY offset defined for it.
What I'm wondering is if there is a better way of accomplishing this that I haven't thought of. Thanks!
The client that I'm working with is essentially quite happy with Maplex in about 95-99% of cases. There are plenty of properties that can be set to establish where the label should appear, whether it can be overlapped, whether it must display or not, and how elements can be abbreviated...etc. The client feels that Maplex is great, but ultimately, it is that 1-5% of labels that has them wanting something of a hybrid between the "place-wherever-you-want" freedom of annotation and the speed and consistency of labeling for this one specific layer. There is nothing concrete that they have provided me in terms of a set of rules that could get translated into something really usable by Maplex...its more the case that in specific instances they just disagree with where Maplex placed the label.
So, a good question would be why not just use feature-linked annotation (I believe you can still use Mapplex to place the annotation, and then move it around if needed, right)? Well...here's why...
Currently, the label text for this layer ("Pole") are being generated by some custom code written by me that queries related data and formulates a label string on the fly. For example there is an external table called StreetLight which is related to "Pole" in a one to many relationship. StreetLight has data detailing streetlights that might exist on the pole...it's just one of several elements that can get used in the label string (it can be very long). In the case of StreetLight, the related table actually lives completely outside of the geodatabase. As the user pans and zooms around, the labels automatically update and stay in synch with the underlying related data. In an effort to keep the database normalized, the label strings are not stored with the feature at all. This is all working great, and the only complaint is the precise placement of just a few labels.
So, basically my idea was to have a customization that can give the user a chance to point to a location that approximates where they want the label to be. The location would essentially be a labeling class that would have the correct XY offset used by Maplex.
As I thought about this more on the weekend, I've come up with what might be a cleaner approach...If the user is not happy with the maplex placement for a label, they would set a field named "DontLabelMe" to true on the Pole feature class...Of course, labeling would be set up to not label such features...the user would be further required to add a related point feature called "PoleLabelPoint" that would indicate exactly where the label was to be placed. I think that's better. My custom code would then have to be modified to label that feature.
A colleague just suggested that I investigate "Representation" and setting that up in ArcCatalog and in ArcMap. It seems like the ideas here is that you can have an alternate display geometry, but that the feature remains at its original XY location...That would be perfect (I think) for what I want to do...but...it seems like it is just the symbol and not the label that wants to move. Can you tell me if "Representation" is at all relevant to labeling?
Mapping Center Answer:
So, your approach of having a field that identifies features that tend not to be labeled so well with Maplex is in the general area of what I would recommend in this case. One of the tricks we use, though, when producing annotation is to produce one set of annotation first, and then use that as barriers to the other layer's labels. This allows the more important layer (poles for you) to get labeled without Maplex doing extra work to fit more labels on the map, but sacrificing the quality of placement (changing an ideal placement to merely good) at times to do so.
I would suggest, since ArcMap doesn't do the hybrid workflow you'd ideally like is to split the poles labels into two classes, one that is for the troublesome placements, and another (or more if you've already got them) for the rest of the poles. Then make sure the troublesome poles label class is first in Label Priority Ranking list. I also, on occasion, find that switching Maplex from Best to Fast produces better results (because first/best options are kept in favor of fitting more labels).
You might have uncovered a bug in one of the Maplex placement algorithms. So, if there are cases for the placement of specific labels that profoundly do not make sense, definitely contact Technical Support.
The question about representations is interesting--yes, labels will be placed relative to representation geometry, so a manual override of a pole's position could work. The trick here is that you'll likely want to draw the original position as you are now, but also have another layer (that will be labeled) that has representations, but the symbols are "No Color" and then you could move poles in the representation to mitigate the circumstances for label placement. You could try to label just the override features in the representation layer as well.
If you would like to post a comment, please login.