elevation tag samples

[sbrown]

I need the functionality of visibility control on various levels. We do Interiors and Architecture mixed projects in the same model. It becomes incredibly time consuming to turn off the interior elevation symbols that pop up on all the arch. views. So some way to filter elevation types by scale, discipline and interior/exterior.

[dbaldacchino]

Wow, very timely....we were discussing elevation standard notation just today!

As for graphic representation of exterior elevations, what's been posted in this thread is typical for us in ADT (symbol that looks like a section mark without the tail and leader). We would definately like to have the possibility to jog elevations. One thing I don't understand is the reason that elevation tags were implemented in the current fashion, instead of making use of an annotation family similar to section tag implementation. That way, it's all up to the user to define the graphical display and layout and there wouldn't be any more gripes.

On the topic of elevations, we need better control over line weights. Objects farther away need to appear thinner. ADT's elevations are a good example of what users are looking for: being able to define zones where lines will be heavy closer to the viewer and zones were lines start to get lighter/recede as they get further away from the viewer. Using Advanced Model Graphics (silhouette overrides) has been problematic when using wall sweeps (such as brick banding) as these also assume the heavier line weight assigned to the override and thus read incorrectly.

Elevation tag management is a serious issue for us too. I had a thought regarding this.....why not make elevation tags visible by default ONLY in the view where created? This solves the issue of having to manually turn off tags in all other views. If a user is creating elevations just for testing things out (temporary elevation views), they can do so in their personal views and not affect the documentation views. If a user wants to add a permanent elevation, they would go to the respective view, such as an interior plan, and place them there. By default, they would not show anywhere else except in that view, which would be part of the document set. If they are desired also in another view (this would be rare for us), then the user would just have to right click on the invisible elevation annotation in that view and select "Show Annotation in view". This is contrary to what our current workflow is (turning tags off in ALL undesirable views).

Thanks for working on this!!

[Rols]

Throughout my career the choice has been pretty darn simple: single or multi.
We typically use the single elevation tag, regardless of whether it's interior or exterior. If I have enough room on my floorplan to use seperate elevation tags for each interior wall, I use singles. If space is a bit cramped, then I use the multi.

I know there are limitations in using the single elevation tag. I will no longer be able to use those cute little check boxes to create and control multiple elevation views. I can deal with it! Just give me the choice.

Thank you, Frame for looking at this matter and asking for our input.

[cstanley]

Frame, thanks for asking!
I attached some of our "standards" used in ACAD.
On the subject of elevation tags, I typically try not to show the Interior ones. They clutter up my drawings, and although it's neat that they display the reference information, it's really not necessary for me. Instead, I name my elevation views "1032 Radiology W" for example. (the W is for west.) this way they aren't necessary on the floor plans, and the GC can find them easily on the elevations sheets. of course, there are exceptions.

However: I would like them to be "room aware" so that I can have them auto-fill their name, number, and the elevation view title.

That said, see below for our "standards" which we would like to be able to use. since we are a large firm in transition, we need all of our drawings, whether in ACAD or Revit, to appear as though they are from the same software. it should be indiscernible what software was used to create the final product. so more flexibility in appearance is necessary.

also, it would be great to be able to use the tags shown with the text properly rotated (see the section heads/tails and refer to this thread http://forums.augi.com/showthread.php?t=45881)

[aaronrumple]

Aside from the graphics issue - I think a more critical component is how the symbols are managed.

1. They should have the "Hide at Scales Coarser Than" (9.1 Feature - thanks...)

2. When a symbol is placed in a top level drawing such as a floor plan - it should only be visible in that top level drawing - not in their duplicated views of the same type. We have architectural floor plans, interior furniture plans, interior floor finish plans, equipment plans, etc. When I place a symbol in an interior design floor plan - it should not show up in the architectural floor plan.

3. There should be subcategories of symbol types. This also applies to sections, details and callouts. When I'm on a roof plan - I want to be able to turn off everything but symbols associated with Detail Views (Roof Details). I'd rather do this using annotation visibility settings rather than filters or some other technique. (Interior Elevations, Exterior Elevations, Casework Elevations, etc...) These should be user definable just like the detail view types.

4. An elevation that extends from Level 1 to Level 2 should not display on Level 2. It should have to cross Level 2 in order to display on Level 2.

5. Elevation symbols should be separated from the picture plane on a view-by-view basis. I want the symbol in slightly different locations in different scale floor plans. Right now that is a constant fight where one person moves a symbol in one view and then it is right on top of someone other views notes.

6. Elevations should have the "Show In" Parent View Only just like callouts. This feature should also be extended to sections. (All of these comments apply to all symbols.)

6. There should be auto view naming based on level and room name. (We use LVL01.100.E as an example in naming our views in the project browser.) Even something like "North Elevation Room 100" would even be better than 22-a, 22-b, 22-c etc... It would be Ok if it did this on first time placement. But a better solution would be to incorporate VBScript in the symbols parameters so I could enter something like "vbRoomName & vbLevelName" in the elevation name field so it would auto update as the symbol moved from space to space. (That would be cool.)

7. Don't make the view depth confusing like ADT. But give us that functionality. I'd propose just a simple Projected, Near and Far setting. Projected diplays with the lineweight and style per the family category. Near displays with 1/2 the defined lineweight. Far displays with 1/2 the lineweight and screened 50%. Line style and color are not changed of course.

[archjake]

I know this question was for elevation tags, but can we talk about the way an interior elevation should be cropped?

See the attached example. We need the ability or a tool to do this easily if one wishes to.

And while I'm at it:
For elevation view depth I'd like to see a system of planes. We currently have the view depth plane. Keep this the same, but we should be able to add new planes in between (1 to n) and define the graphics for what is viewed behind each plane much like what Aaron is talking about. It should be easy to move and adjust the planes. Much like the view depth we currently have. There may also be an instance where the plane does not cross the entire view. An example of this would be a wall at a 45 degree on the right side of a building and a protruding room on the left side of the elevation that occurs somewhere between. The user may want different line weights.

And more: I think it is sometimes important for an elevation to follow a segmented surface and not just be projected. It is kind of like un-folding but not really. This can currently be done with multiple elevations at a 90 deg. angle to a segmented wall and then placed together on a sheet, but why not have this ability in our tool box. I'd love to be able to do a kitchen like this as well.

[The Sweg]

It sounds like this may already exist, but could we have the ability to create our own graphics for the section and elevation heads, load them and be able to insert whatever we want?

BTW, Thanks for asking for suggestions, we all appreciate it, and it just shows class. Good luck with this task!

[Rols]

3. There should be subcategories of symbol types. This also applies to sections, details and callouts.

This would also be applied to views referencing other views. Not every elevation that may reference another elevation (typical views such as bathrooms) is a "SIM". There may be TYP, SIM REV, REV (reverse), or they may be exactly the same, in which case there would be so extra tag. We need to be able to specify the tag type for each instance.

[robert.manna]

This would also be applied to views referencing other views. Not every elevation that may reference another elevation (typical views such as bathrooms) is a "SIM". There may be TYP, SIM REV, REV (reverse), or they may be exactly the same, in which case there would be so extra tag. We need to be able to specify the tag type for each instance.

Yes, the ability to "tag" a view callout as any of these should be an instance parameter so that we don't end up 20 different view types just because of needing all the tags.

Here, here on all the suggustions so far! Having had a programmer for a roomate (works for Microsoft now) I learned about how hard it is to make things infinently flexible in the programming world, but as I think everyone at the factory knows, we need far more functionality in a range of ways when it comes to elevations & views in general.

Thanks,

-R

[aaronrumple]

It sounds like this may already exist, but could we have the ability to create our own graphics for the section and elevation heads, load them and be able to insert whatever we want?

BTW, Thanks for asking for suggestions, we all appreciate it, and it just shows class. Good luck with this task!

Yes - this needs to be fixed. It used to work great, but somewhere along the line this became a type parameter rather than instance and screwed the whole system up.