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

Civil 3D Sites, DREFs, and PasteBase... Oh my!

Civil 3D Sites, DREFs, and PasteBase... Oh my!

Okay, so Civil 3D Sites are not able to be DREF-ed (Data Referenced) - methinks that's a poor implementation of what could be a useful aspect to Civil 3D, but so be it.


Why then, when I copy Parcel Segments, etc. from one Drawing (as members of Site name "FOO"), and past them into another Drawing, which also has a Site named "FOO," do I end up with a resultant "FOO|1" Site?  (Think different subdivision designs, following client requested site changes, etc.)


The Sites have the same name - shouldn't Civil 3D be smart enough to identify that, and automagically add said pasted Object(s) into the Site of same name first, and only if it doesn't exist, create a new Site?


C3D is smart enough to see that the sites have the same name. If there wasn't already one with that name it wouldn't bother adding the |1 on the end.

I believe the idea is that the user may not realise that the sites have the same name and that the feature lines will interact. Therefore the program adds the suffix to prevent unwanted changes to the data being pasted and/or preexisting in the drawing.


Maybe the program is being too smart!


By design, Autodesk expects the potentiality for users to have duplicates Sites throughout multiple drawings as they cannot be DREF-ed, much the same as is expected for Styles, Blocks, and even Layers... Yet these are not renamed in kind.


Unwanted changes when pasting an Object from one drawing to another, is an entry level training issue - At most, Civil 3D should prompt the user to 'append' or 'add and rename', with the option to check a box to 'always perform this action', and be done with it.


If I want the Objects being pasted to reside in a new Site, etc., then I'll either rename prior to copy, or Move to [a new] Site following paste.




Ultimately this flaw, and others like it, trace back to Autodesk's decision to get rid of an external Database, which has led to wasted time managing the myriad Drawing-specific Objects, Styles, etc. across multiple templates, and projects.


Sounded like an neat idea back when using Land Desktop, but with the improvements of today's technology, workstations, etc., between drawing bloat with unused Styles, and the constant effort to purge unused, import when needed, it really stinks, IMO.



@BlackBox_ wrote:

Okay, so Civil 3D Sites are not able to be DREF-ed (Data Referenced) - methinks that's a poor implementation of what could be a useful aspect to Civil 3D, but so be it.


I think this is the main point. Never mind 'so be it'. My wish would be full ability to d-ref feature lines. Then the current copy/paste situation would be irrelevant.


Just ran into this again, with Alignments + Station Offset Labels -



I have a 1,000 AC subdivision, where four roads approach one of the internal Focal Points (aka Parks), with divided medians, multiple Alignments and Profiles for each accordingly.


I only copied the Station Offset Labels, but the Alignments were also replicated in the target drawing where the same parent Alignment(s) (from same Source Drawing[s]) already existed.


[Edit] - ... And I think ^^ this last bit ^^ is a prudent factor in the potential renaming vs. merging logic in the code-behind.



In any event, my point in posting this update was to also point out another related issue with this - specifically, that even after 'cleanup', re-assigning the Station Offset Labels' parent Alignment to <AlignmentName> rather than <AlignmentName>|1, etc. and subsequently deleting the latter, when a Station Offset Label is selected the recently deleted duplicate Alignments are still available via Properties pane, under General, Alignment dropdown.


Each-and-every-single time an Alignment (or fill in the Civil 3D Object blank) is deleted, shouldn't the data binding mapped to such dropdowns, controls, etc. be updated in kind?


They're clearly _NOT_ updating at runtime when the child Station Offset Label is selected.




Hi @peterfunkautodesk -


You've been very interactive in some of the other 'ideas', and I am hopeful that you can offer some guidance here, as this just came up again.




Autodesk's suggested workflow, is to label everything within the sheet drawings - which is consistent with how I have always worked, back in the days of LDD.


Problem is - when we have to send out a single drawing with all line work (which includes objects), and labels.




Back in LDD, one accomplished this by simply inserting & exploding the sheets that contained the labels for the area(s) that needed to be sent out, and maybe clean up some overlapping labels at match lines.


In Ciivl 3D, this could not be a more frustrating, and difficult task - if everything is DREF + labeled within the sheets, and you INSERT + EXPLODE those sheets into the 'master' line work drawing to send out to consultants (something my current employer does frequently), then we end up with myriad useless duplicates for each-and-every-single Object that is needed to produce a sheet drawing.




I'm torn -


Plans production is complicated with ALL labels in XREFs, due to dependency on Layer States, but has always been easier to manage Styles - For this reason, I've hated working in Civil 3D due to difficulty in managing Styles across a directory of drawing, which Civil 3D 2017 thankfully has made some (not enough) progress in simplifying with Style templates.


I prefer to label within the sheets, as it yields a better looking product, IMO, and the Style templates removes some of the difficulty to manage (Hooray!), but there is no simple means by which to 'send out' a project in a single drawing (which is a requirement here).


The suggested workflows, and new external Style management are working completely against the COPY+PASTE or INSERT+EXPLODE of drawings with labels in them, which is infuriating this many years into Civil 3D.


We MUST have an option to COPY+PASTE or INSERT+EXPLODE labels, without resulting in myriad duplicate Objects, Sites, etc. - EXPORTTOAUTOCAD *shouldn't* be the best option, and is unacceptable, frankly.



... Please help.

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