Corridor reference elevations different than source corridor

[jessica.miller]

We are working in 2018.  I've got a corridor I'm using for annotation in my production plans.  I've cut a cross section in the file where the corridor lives & it displays correctly.  I reference the corridor into my production file & the labels drop several hundred feet off of the view.  This only happens for about 80% of the corridor.  I've deleted & recreated the shortcut.  All data to build the corridor is referenced into the file.  I've tried removing the dref then audit & purge.  I get the same result when I bring the corridor back into the dwg.  I've looked at the corridor in 3d orbit in both files.  In the source file it looks great, it's a relatively flat profile.  In the dref file, the feature lines stair step in elevation.  I've even toggled the high quality geometry thinking that might work; nothing.  If anyone has seen or knows how to fix this please advise!  Ideally these corridors stay dynamic.  Ultimately I can explode the sections & move the labels, but when the labels change I'm doing it all again.  

[KirkWM]

Hi Jessica, is the issue with section labels not being placed vertically at the correct location in the section view? I've had something like this happen to me where I was adding corridor labels to mark the right of way and my issue was that the code the label style was looking for didn't match the keyed in code of the subassembly. Hope this points you in the right direction.

[jessica.miller]

Yes & no.  The labels follow the corridor feature line to display information.  The elevations of the feature lines in the corridor are different when the corridor is referenced into the production file.  The code set is working properly, yet in the wrong location.

[samir_rezk]

Hi,

Just wanting to make sure that you did data shortcut all your corridor baselines in to your dref drawing. You have to data reference the alignment and profile of your baselines. I don’t think it is possible to have the dref corridor to work correctly if you used feature lines as baselines! Since it requires the baselines to be data referenced in.

Hope this get closer to the solution,

[jessica.miller]

Right.  When I say feature lines I'm talking about the feature lines the corridor generates from building.  All data references needed to build the corridor accurately were in the file.

[cwr-pae]

Can you post a copy of the sections file? Or at least an image?

[cwr-pae]

Just an FYI on corridor drefs. When you reference the corridor it brings the alignment and profile in to the client drawing. If the alignment and profile exist in the client, referencing the corridor will bring a copy of the alignment and profile. Annoying to say the least.

[jessica.miller]

To clarify I'm posting pictures. 

Correct corridor in 3DOrbit mode:

This is what happens when it's been data refd into the production dwg.  This is also 3D Orbit mode.  Clearly incorrect.

[jessica.miller · Accepted solution]

Upon more research, this turned out to be a drawing issue.  The corridor was reference into a different dwg & it was fine.  Still not sure what caused the miscommunication between the source & the reference.

[abbythralls]

UGG. I am having this issue as well. 

I have tried

(1) Auditing & purging the corrupted file

(2) removing the corridor data shortcut from the corrupted file

(3) auditing & purging the corrupted file again

(4) W-blocking the corrupted file

(5) Deleting the data shortcut from the data shortcuts

(6) Re-creating the data shortcut in the data shortcuts

(7) recovering the W-blocked file, auditing & purging, closing reopening

(8) adding the new corridor data shortcuts into the new W-blocked CLEAN file.

Same errors.

Anyone have any ideas?

[jessica.miller]

It's frustrating...& I think we've not had the issue since. 

Have you tried referencing it into a new unrelated dwg?