linking markers between projects

[Patrick M]

I have a project team that wants to put their details in a separate file. 
the project has an architecture shell/core team, and an interiors team. The interiors team wants their details separated out for simplicity, and to avoid unnecessary pollution when pulling cut sheets, other project's details, etc. in.
My plan is to create a blank file, hotlink the main project teamwork file in, then they can draft details from the hotlink, updating when necessary.
...
My only sticking point is that we want to be able to reference the detail views drawings/layouts from the interiors model into the shell/core model. I really want to avoid views > layouts from file B to file A; updating those is a PITA that I will avoid at almost any cost. 
Is there any other option ya'll can think of to make this workflow happen and properly reference the details (manual text in det markers is 100% NOT an option)

Operating system used: Mac Intel-based

[Lingwisyer]

Just clarifying, you are wanting the reference marker to the detail in one file while the referenced layout is in a second file?

[MitchD]

exporting PMK's from file B and linking them in file A is a muuuuuuuuch quicker and cleaner way of showing drawings from another file. as long as they are published after any changes, they work seamlessly.

[Patrick M]

it just seems a bit antiquated to cling to .pmk as a workflow... I remember the plotmaker days, and really don't want to go back to them.
...
@Lingwisyer, we want to draw the details in file B, place them to layouts in file B, but have linked markers referencing those layouts/drawings in file A.

[Stefan L_]

---

@Patrick M  schrieb:

... but have linked markers referencing those [file B] layouts/drawings in file A

---

Because you want to:

- [in file A] open the floor plan, click a marker and beeing beamed to that content in file B?

- [in file B] select a drawing and beeing beamed to the linked marker in file A?

Sounds quite impossible to me, but I'm here to learn. 🤓

We keep main TW model and detail TW seperated since ages, for different reasons:

- file size, performance

- less TW reservation conflicts

- detail TW is 'outlaw territory'; content is pasted from everywhere (including late '90s attributes...)

- 1:50 main model content seldomly suits details (section through window? No, thanks...)

So: manual text in det markers is 100% NOT an our only option

We use a quite dumb lib element as marker BTW:

[Patrick M]

manual text in markers for a plan set with hundred (multiple hundreds) of details is just no feasible.

if I had a project small enough, where manually managing marker references was an option, it would be small enough to keep everything in one file.

I know the .pmk workflow, but I really hate to go back to systems abandoned over 20 years ago. 

...

I'm genuinely curious, do the half million square foot calibre projects still use the antiquated .pmk workflow? and do you actually see a benefit in file performance? You are still managing a layout book that is massive in one file. And the process of exporting, updating/relinking, etc. can not be more efficient.

[Laszlo Nagy]

FYI: As far as I know, there are project sizes where PMK is the only feasible workflow for performance reasons.

There is a solid reason why the PMK file format was kept, and it is due to its lightness and small size.

You can have one or more project files that contain only the model, you publish the Views as PMKs, then place the PMK files as Drawings on the Layouts in the other project file(s) that contain only the Layout Book for documentation.

[Patrick M]

we may just have to go with a pmk... I hate the notion of training teams to use the antiquated workflow; its hard enough to convince them to use .mod's to keep files light.

A 40,000 sq ft project modeled like its cabinet shop drawings is always going to be fraught with hang ups and performance issues, and its compounded by the layout book that looks like we're trying fill a literal library with construction documents... 
it don't know that there is a software out there that can handle these kinds of design and documentation standards; although there was a tool once upon a time, that at a release party, they touted the slogan "faster than ever" and compared a massive model side by side with another software showing how much slower the other software was. Seems speed is no longer a goal.

[Stefan L_]

We do projects of that size and way bigger, and we produce hundreds of details.

But there's obviously a difference in detail marker density. 🤣

Door details for instance are referenced by door schedule and door type/number, no marker neccessary.

Many more things are different here in DE - I just realized, that some seem to be better! 😍