Showing results for 
Show  only  | Search instead for 
Did you mean: 

Change Labels from Civil 3d Objects to Standard Blocks (or other objects)

Change Labels from Civil 3d Objects to Standard Blocks (or other objects)

Civil 3d is terrible at regenerating and working with it's own content.  If it gave us a selection to change all labels to static / non-dynamic blocks I imagine it would speed things up.  With an option to change it back when wanted.


Additionally, could do this with everything (networks, surfaces, pipes, profile lines and views, etc) in Civil 3d so we could have the speed / processing LDD had10 years ago but the efficiency of using civil 3d objects when needed. 


Labels in Civil 3D are riddled with problems, because they weren't very well thought out when they were implemented, and the necessary APIs weren't exposed for the developer folk to fill in the massive gaps. 


As example: An Alignment station offset label can use an Profile Expression to derive a relative grade from Profile Grade Line, but it cannot variably determine cross slope elevation (say -2%?), based on Profile Grade * the Offset from Alignment. 


Fuether complicating matters is the is the fact that Labels can consume our Blocks, but they do not populate our Blocks; instead we have to duplicate work to come up with a kludge that ends up being 'like' our actual Blocks.


The only way you're going to be able to convert Block-->COGO, and COGO-->Block, is by coding yourself a custom LISP, etc. the only thing faster, which still doesn't yield your original Blocks, is to EXPORTTOAUTOCAD. 



As for your last part, I'm terribly disappointed in the performance, and amount of additional time required to maintain this internal database malarkey, as compared to how simple it was to work with Land Desktop's external database.  There's a lot about Civil 3D that I like, but those aspects don't build on what Land Desktop was good at, leveraging today's technologies, instead they're built on a sub-standard foundation, that is completely disjointed from the rest of even AutoCAD. 


As examples:


The benefit to an external database is the reference data within the drawing is static until you connect to the project database, which expedites drawing open, and overall plans production. There's less to maintain with external database, as you're no longer having to configure, export/import Styles, etc across myriad drawings as well. 


For the disjointed bit, just take Annotation Scales into account. Autodesk spent beaucoups dollars developing, and implementing the mechanism(s) to allow users to specify which scales annotation entities would support, and their respective positions at each scale. Enter Civil 3D, and the complete disregard for how plans production in AutoCAD is now done in kind, and we're suddenly thrown back 10 years by having to place duplicate labels in a different position, on duplicate layers for each of the various scales for the sheets we're XREFing annotation entities / Labels into, because Civil 3D Labels auto-scale to ALL scales unlike every other annotation entity in AutoCAD. 






@BlackBox_, I'm sure you're familiar with problems of maintaining an interface with an external database - migrating old data to newer versions, dropped interface support such as x64 vs. JET, cloud-hosted content (yeah, yeah - already heard that argument and its not the main point I'm making Smiley Frustrated ) and so on.  Not saying whether its a bad or good thing, just that there are ups and downs with both.


Hi @dgorsman - 


No matter how Autodesk makes it, each has inherent tradeoffs, and I do not discount that some folks smarter than I decided it was worth doing back then... problem is that doing so inherently pushes the burden of effort onto us to make what they wanted to do with Civil 3D possible.


YMMV; I've used both for many years, and continue to use software dependent on external databases still today - Outlook x86 / Exchange Server, Sharepoint, Primavera, Intranet SQL-based apps, etc. anyone? Haha


I'd like to believe that there is performance to be gained in daily plans production, without losing all of the inherent design advantages that Civil 3D has brought to the table... When we start a task that requires the DB, it should connect accordingly, and we should be able to 'disconnect' allowing what is drawn/projected/labeled to 'work' like static blocks to benefit the plans production process.


If Autodesk has already attempted such, and has the quantifiable numbers from plans production tests to justify that users are better served by the internal database, then I look forward to that conversation... Because there are still massive gaps in standards / style management, aside from the slowness attributed to the constant sync at drawing open, etc. 




Looks like Autodesk does realize the benefit of centralizing Style management:

... Now to get them to acknowledge the performance benefits of centralizing the Project's database. Haha

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Answer Day

Rail Community


Autodesk Design & Make Report