Add Fields to Civil 3D Labels

[Wish List System]

Summary: The ability to add Fields, particuler, sheet numbers inside of Civil 3D labels.

Description: Examples: Install and Construct Notes that then refer to a different sheet for additional information. We love the smart labels to be able to pick up Stationing, Offsets, Elevations, etc. to add dynamic updateable data to the labels but a lot of our labels include refernces to other sheets. Sheetsetholders could be added to the default definition of the note that could then be updated when the reference sheet was added to the sheet set.

Product and Feature: AutoCAD Civil 3D - Annotate (Civil 3D Labels)

Submitted By: Daryl Standrich on 11/19/2013

[KansasCAD]

If you haven't, please cast your votes for this and many other great ideas. This wish is still relevant and has been on the wish list for 3 years now.

[BlackBox]

See... I've always wanted Civil 3D to go the other way, and expose the AECC* Object Properties to the FIELD engine, so that we can instead 'label' using Text, MText, MLeaders, Dimensions as needed.

[cadtag]

voting w/ BB on this one! C3D labels work, but are as ugly and kludgy as venial sins

[BlackBox]

voting w/ BB on this one!

Cheers, dude.

[KansasCAD]

I guess I figured adding fields would be a more simple process than getting at all of the Civil items. Maybe I just made do with the label style, but we can make "Most" of our labels behave the way we want. And we have taken the time to make all of the ones we use all the time. It would seem that trying to add all of the civil data to a multi-leader would be more work. What part of labels does everyone dis-like so much?

Not trying to start any kind of a competition or argument, just curious what part of labels don't work for you.

(And No, I do not work for Autodesk)

Daryl

[cadtag]

everything from managing leaders to masking to editing label text, and that's not even getting not the mess of having 'autoscaling' lables that sorta work like annotative, but really don't.

[KansasCAD]

Sorry you are having issues. We don't seem to be having the issues you mention. And I have never had any issues with auto scaling.

[cadtag]

The dysfunctional problem with the autoscaling is that it works completely differently than annotative. With annotative, the item only displays when the viewport scale is on the list of scales associated with that object. with C3D autoscaling, everything just resizes regardless. So I've got one viewport at one scale, say !"=100', and another detailed view at 1"=10'. In the large scale view, I really don't need to see every contour label, slope label, point label, etc, but con't control whether it displays by scale factor. Heck, maybe on the large scale contours only need to be labeled at index contours, but in the small scale I'll want 1' or half foot labels. Everything can be worked around, but lord love em, just because autoscaling label tech predates annotative scaling doesn't mean that the C3D devs should stick to their guns with their old stuff. (Even if I need the same label showing in both views, the location the label displays in on may need to be different between the two.

And leader management for dragged state is worse than pathetic -- creating umpteen different styles and keeping track of all of them on a multitude of different jobs with multiple client or sub standards - sheesh. What ought to be trivial to do is kludgy as can be.

Bottom line I guess is that MLeaders work much better for displaying information in the large majority of situations, but can't really be used safely because they can't get at the C3D data we need to show.

[rkmcswain]

This should be on the C3D IdeaStation for better exposure to the C3D dev team.