Topic: Civil 3D | Where Do You Label What?

[nobody]

I xref the profile views into my cut sheets and label the pipes in those. Seems to work but on large projects can slow drawing open times down considerably. 

When xref'ing files with dref'd data...does that dref data come in as well (the surfaces for example that are dref'd into my profiles)?

Sorry Late night last night.

Question is if you have a DWG that has a Pipe Network in it with a Data Shortcut / Referenced Surface into it. Then Xref that file into a sheet file, and then RE-DATA REF the Pipe Network and Surface into the same sheet file "To Cut Plan and Profiles".?

I have seen this here at our office a few times. Personally I think its bad practice, but just curious what you guys think...

A problem I've encountered with having a the pipe network in the xref (initially would put in base file) and then dref'd in to cut profiles is the profile in my profile views will disappear and have to be added to the profile view every time I open the drawing.
I try and dref the pipe network as little as possible - styles don't update resulting in the same structure being edited after dref and appearing different in each file.
I wouldn't even mind xrefing the pipe network, and just having my profiles cut in the same file, except the pipe file needs the surface dref in, but also has to be dref into the sheet file for labeling, and then the surface is the the sheet file as part of the pipe xref and a dref.

[MSTG007]

I believe it does. again we usually have a pipes data ref that have the pipe network and the alignments that are all data ref'd out. In my cut sheet we data ref all that in with the surfaces and then create our views and labels.

[nobody]

Think this is the best-practices method... it feels sort of like when we didn't have paper space and had to break drawings out in pieces just to create sheets...can't get myself do dref all that

I believe it does. again we usually have a pipes data ref that have the pipe network and the alignments that are all data ref'd out. In my cut sheet we data ref all that in with the surfaces and then create our views and labels.

[MSTG007]

what I prefer is to do less work. Lol. If it was me and a small firm, I would keep all my networks and surfaces profiles and views in a design.dwg. Label it all in there, then xref that into a cut sheet file. Lol.

[nobody]

 

what I prefer is to do less work. Lol. If it was me and a small firm, I would keep all my networks and surfaces profiles and views in a design.dwg. Label it all in there, then xref that into a cut sheet file. Lol.

[BlackBox]

A problem I've encountered with having a the pipe network in the xref (initially would put in base file) and then dref'd in to cut profiles is the profile in my profile views will disappear and have to be added to the profile view every time I open the drawing.
I try and dref the pipe network as little as possible - styles don't update resulting in the same structure being edited after dref and appearing different in each file.
I wouldn't even mind xrefing the pipe network, and just having my profiles cut in the same file, except the pipe file needs the surface dref in, but also has to be dref into the sheet file for labeling, and then the surface is the the sheet file as part of the pipe xref and a dref.

If you DREF the Surface into your Pipe drawing, and XREF that into your Sheet drawing, then simply label the XREF Surface (which is a DREF)... It Labels just like any other XREF Object... The only reason to then DREF the Surface into the Sheet, is if you need a different Style applied, though not sure why you'd not then instead apply that Style before saving the Pipe drawing.

As for Style maintenance, 2017 does now support external Style template references, which may come in handy if you're on Subscription (or whatever they're calling it now).


Cheers

[BlackBox]

what I prefer is to do less work. Lol. If it was me and a small firm, I would keep all my networks and surfaces profiles and views in a design.dwg. Label it all in there, then xref that into a cut sheet file. Lol.

Haha - this is the very sort of mess that prompted my starting this thread.

[BlackBox]

I xref the profile views into my cut sheets and label the pipes in those. Seems to work but on large projects can slow drawing open times down considerably. 

When xref'ing files with dref'd data...does that dref data come in as well (the surfaces for example that are dref'd into my profiles)?

Yes - that's the problem.

Civil 3D doesn't support Overlay functionality for DREF; only Attachment. This is what can lead to duplicate DREFs in Sheet drawings, and due to C3D not being smart enough to realize that they're duplicates of the same DREF, it can greatly slow down drawing open from synchronization.

Further still, C3D isn't smart enough to only sync those DREFs that are stale - you save one Alignment's Start a station change, and the entire lot is synced.

Further, the internal DB doesn't allow us the luxury of only connecting to DB in design, it is always connected, and synchronized, etc. Instead, we *should* be able to have static DREFs that aren't connected which perform like blocks, and are only connected when Promoted for Labels, or Edit to the Object, and then Demoted back to DREF (sort of like REFEDIT).

[nobody]

Yes, in my opinion, all labels belong in the sheet files. Most of the reasons why have already been mentioned. One other that I don't recall seeing here is that labels take processing power to populate. If you have all the labels in the base/design file, then each and every sheet must wait for all those labels to be populated. And those calculations occur with every REGEN. Keeping just those labels necessary for the specific sheet speeds up that process.

This is so stupid...how did Autodesk degrade so much in their understanding of processing and regeneration. LDD wasn't dynamic, but it was fast. Really hope they get this crap figured out. 

[BlackBox]

maybe we need a Venn Diagram or Flow Chart to make it clear to all....bust out your best Visio

I'll download & install that from MSDN (thank you, BizSpark!), and see what I can do.