Feature Stories continued | Elevation Tags

Lurking Evil

I use this term to describe items I know are going to crop up and challenge what may otherwise look like a feasible design.  It lurks in the strangest places yet often stems from conflict with adjacent features, other new features developed in parallel or legacy Revit weirdness.

In the previous post custom elevation tags has a design and is moving forward.  For those who keep track of Revit trivia the feature was born on 20090930_1159 (yyyymmdd_hhmm).  After this date one could fire up a development build and test the feature out.  It’s always desirable to get live code early in a release since problems are easier to witness than imagine.  ….On to some of the issues:

Upgrade

Pre-2011 hard coded elevation tags were somewhat customizable as long as the built in properties could make a tag you liked.  Properties controlled the shape of the tag, how pointy the arrows were, label presence, and label location.  In the 2011 release we planned to ship new content that would match the old content yet this exposed some issues.  Take the ‘View Name Position” property.  Families do not have a property that controls text or label position.  It would be silly since you can just place a label where you want but the hard coded elevation tags required a positional property.  After some brainstorming it was decided that we could make a type for each possible combination of text and label location using visibility properties to turn them on and off.  On upgrade we would map to the type that matched the existing condition.  Sounds good yet the “Text Position”, “View Name Position”, “Reference Label Position” and the “Show View Name” properties demanded 4 x 3 x 3 x 2 types!  The fact that the pointyness of the arrows shifted the labels suggested infinite types were required!  In the end we decided that we could not ensure the tags looked exactly the same after upgrade but we would ensure the same labels were present keeping drawings readable and accurate.  It would be possible to correct the upgrade results manually if this were required.

Reloading Content

Given the capability of loading elevation tag content what happens when elevations exist in the project and the new symbol is different than the original?  How many ways can it be different? This scary issue was raised early so we got a leg up on many of the solutions before actual implementation.  Here are the main cases and solutions:

• If the user desires to make cosmetic changes to the family they must edit the family and reload it into the project.
• • The instance will update on reload without affecting views provided the direction and number of nested pointers is unchanged.
  • Adding new arrows are OK as they do not instantiate a new view until checked.
  • Line work and labels changes are remapped.

• If the new symbol arrows are in the same relative direction and quantity to the base family as the project elevation instance then the system will match the orientation of the new instance to that of the placed instance and remap the arrows in the old instance to the new instance in a clockwise fashion.
• If a new instance is the same as the original but has fewer arrows than any used arrows the new symbol will be considered incompatible.  The user must place a new symbol and delete the old views.
• If the base and pointer arrows do not correlate in number or direction then switching type is disallowed.  The new symbol will be considered incompatible.  The user must place a new symbol and delete the old views.
•  If the user deletes an elevation family and it is instantiated in the project a warning will be issued similar to the one shown below for a callout head family.

Tag Rotation

It turned out that when placing elevation tags the hunting behavior (where it identifies nearby walls) caused the system to rotate the tag.  This caused the now possible asymmetrical tags to be rotated large amounts and look stupid.  A new algorithm had to be created that would choose the arrow from the tag that caused the least rotation rather than always rotate to the top arrow. The existing behavior was impossible to know because all the original hard coded tags were symmetrical. Here is the issue before and after resolution:

 

Text Rotation

It turns out that the hard coded elevation tag text maintained an orientation. 

Labels in our custom families did not have capability this before 2011.  We decided to open up and expose this property.  Now there is a “Fixed Rotation” property for all family text and labels the family category Elevation Marks  A similar property is still needed for lines to get the section head behavior.

Those were the biggest issues.  As you can see nothing is ever a simple as it seems on the surface but I have to admit solving these is half the fun.  Design is a form of problem solving - there are always constraints.  The end result is more rewarding having overcome these obstacles.

_erik

Comments

[Tim Waldock]

Erik,
To quote above, you say :"Families do not have a property that controls text or label position. It would be silly since you can just place a label where you want".
As a general question (not necessarily related to Elevation tags):
Why would that be silly? I often have text or labels within a family, and wanted to be able to move them around with a parameter. I found it immensely frustrating to have to create copies of the text/label with visibility controls - it seemed a very laborious workaround.

[Anthony Hauck]

Silly is perhaps too strong a word then.  Can you say more about your use case?  If text and labels had an offset parameter it would be easy to adjust position and respond to other elements using a formula.  it certainly would have made the upgrade case easier.  I was more thinking that it is silly to use a parameter to adjust a position when you can just open the family and place it where you want.  If there are valid use cases when text must shift position and there are many potential positions I agree it would be helpful.  The visibility workaround would be laborious if you are trying to control many items.

[Joel Osburn]

First of all, great post. I love problem solving of this sort, and the window into Revit development is most interesting.

Regarding Tim's comment, my take is that the real problem is that it is so hard to control the position of text in just about every area of Revit. The lack of snaps and fixed insertion points are real problems. I never thought I'd see a program that made Autocad's text controls look good, but Revit accomplishes that. The simple act of centering text within a symbol has to be eyeballed. What the heck?

So the way I read it is that offsets would be a bandaid for this lack of placement control. Or maybe they'd require basepoints anyway, since what would one offset from, otherwise?

[Anthony Hauck]

Thanks.  Ive gotten similar feedback so Ill try to do this from time to time.  I think many have grown with the product and watched it evolve so the curiosity makes sense. Text is a sore spot.  Ill gather these requirements and ensure they are part of any text efforts.  re-positioning and aligning seem to be two aspects mentioned here.

[Tim Waldock]

Erik,
Sorry for the slow response. Here is one of many examples of needing to control text/label location:
Room Tag, which has 3 labels for name, number and area. Each label has a visiblity y/n paramete. If the middle label (say number) is turned off, then we want to move the top label down to eliminate the gap between the top and bottom labels. Currently we need to have multiple copies of the top label in different positions to deal with this.

[Anthony Hauck]

Got it.  Thanks.  makes sense.