Topic: Data Shortcuts - The Short Course

[mjfarrell]

From this topic:http://www.theswamp.org/index.php?topic=26022.0


To set up Data Shortcuts, or Datarefs as they are sometimes called.

One first decides
Do I want to set my working path EVERY time I change projects should I decide to keep the shortcuts folder in the project folder. This is due to lack of true project support being native to C3D. Or does one want to keep all data shortcuts in a single folder?
Then one Creates a new folder for the data shortcuts from Prospector>>Toolspace [Master Virew] Datashortcuts.
Then one sets the working Folder there.
Then one can create the data shortcuts.
To use the newly minted shortcuts, Exit and Save the file.
Start NEW file. Save and Name the File
Then one Creates a new folder for the data shortcuts from Prospector>>Toolspace [Master Virew] Datashortcuts, one then Creates a Reference to the short cutted(?) data, Datarefs are similar in function to DWG XREFS in that one can see the data and change it's Style, however on must try hard to accidentally edit the data.

[Dinosaur]

So which one is the preferred method?  I always kept the shortcuts with the appropriate project folder, but I also actively ignored Vault.  Does the use of Vault have any influence on the better choice?

[sinc]

(We also do not use Vault.)

We prefer to change the working folder as-needed, as obnoxious as that is.

The majority of our projects do not use any data references, so we actually end up not needing to change the working folder very often.  And this method keeps all the data for each project in the same directory, which makes it easier for us to deal with project archival.

But doing it this way means we have to fight the software to some extent.  But as annoying as this can be, all in all, we find it preferable to the configuration that Autodesk apparently wants us to use.  It's a close call, though.  It all seems to boil down to "Use whichever one you find less annoying."   :ugly:

[Dinosaur]

I know sinc, those were my initial thoughts as well . . . when we were working on smaller 1 phase projects.  The last few projects I was on though were going to be multiphase with 60+ lots each.  Some of the streets and sewer runs were going to be shown in most of them but fully designed with the first submittal.  They also might be active in all phases of design and construction at the same time for different phases on occasion.  This is where I thought the single location might prove the superior choice or perhaps some exotic new technique would be developed out of need.
I have one more chance to install a 30 day trial that I am saving for when the workload eases up on my day job (I am actually working overtime for the first time in many years and we are looking for 5 or 6 new people to cool things down).  I have some data for one of our multiphase jobs that I am going to try to use the single location idea plus test a few other things.

[mjfarrell]

The lack of project specific controls is a blessing and a curse.  Here it acts as a a blessing, in that a multi phased project, and or any project, that needs to use another's base data through shortcuts is not limited by the 'project' restricting the user from pointing the working folder anywhere one needs to get the data in question.
I think even with a creative use of XREFs, one could even sequence data from multiple projects (phases) into a single drawing; as each XREF could point to it's own working folder to bring together all of the data one needs.

I think the challenge with either method, is that without a good directory structure and file folder naming it presents a chance to lose a lot of time browsing and choosing (the right) folder to get ones shortcuts from.

Might this be something that could be coded to read attributes from a user defined block?  That could prove to be a very useful little helper.

[sinc]

I don't know.  There might be some possibilities, but everything would basically be fighting what Autodesk is doing.

Autodesk is mixing together Project Management and Model Data Management.  They are really two different things, and we really need a way of using one model in multiple projects.  So in a sense, Autodesk is doing something right when they maintain the model data in a location outside of the project.  It's just that, in addition to maintaining a separate model, we need good tools for working with and managing projects, including project archival and sharing of projects with other people (who may be using a different version of C3D, or may not be using C3D at all).  It's these tools that are missing completely.

And of course, at Autodesk, they are still melding Project Management and Model Data Management into one giant problem, which is the biggest part of the reason why they are completely failing to provide coherent tools to work with Projects, which is why we will probably not see a coherent way to manage multi-phase projects anytime in the next few years.

The real problem with the solution you are proposing is that, because of what Autodesk does at the C3D level, Project Management and Model Data Management are mixed together.  So simply trying to provide some "over tool" that lets us manage groups of C3D drawings does not really solve our problem.  The problem begins when C3D itself munges together the concepts of model data and project management, and there's no way to separate them again at a higher level.

That's not to say there isn't potential there, just that it will be difficult to get anything useful working, and it will never be what we really want.

[mjfarrell]

you're going to make me cry

[sinc]

you're going to make me cry

Yep...

To make it worse, any attempt to write a third-party solution to this mess would be highly-susceptible to changes in the core product.  We might be able to come up with something that helps us manage multi-phase projects - it won't really work, since each phase really needs to access the same model, and the model itself needs to support the multi-phasing - but we might be able to create something.  However, if Autodesk actually starts fixing any of this stuff, whatever effort we put into a third-party solution would be wasted.

So this is basically one of those gambles.  Is Autodesk so out-of-touch and incapable of real improvements in the product that we can count on them not fixing this for at least the next 3-5 years?  Or will Autodesk actually start doing something?

It might be safe enough to say that we expect Autodesk to continue to be Autodesk, and C3D will see no fundamental fixes or improvements; instead, it will continue to get incremental improvements and additional features layered on top of a bad foundation, and all of its severe problems will remain in the product until C3D is completely replaced by its successor (as happened with Land Desktop).  In fact, there is an extremely high probability of this.

So if we assume Autodesk will continue shipping a flawed product for its entire lifetime, then we start to see potential value in writing something.  The big problem, though, is that the foundation is wrong.  We really need a system where multiple projects can use the same model, and phasing information is incorporated into the model itself.  If Autodesk starts moving in that direction, any third party solution that uses the current mess will immediately be obsolete, because it won't work all that well to start with.  It will merely be "better than OOTB C3D 2009", but not the solution we really want.

In other words, this is a task that would take considerable development effort by a third-party, to get a solution that isn't really what we want, and one that is highly-vulnerable to changes in the core product that might render it completely worthless.

I'm not sure about others, but I know I'm not in a hurry to tackle this one...   

[sinc]

Actually, now that I think about it, I believe I see a way that this could all be accomplished....

...just probably not with the current API, which won't even let us do simple things like change the current Working Folder.  I also shudder at the amount of work involved, and how delicately-balanced on top of C3D all that code would have to be...

[doggarncity]

From this topic:http://www.theswamp.org/index.php?topic=26022.0


To set up Data Shortcuts, or Datarefs as they are sometimes called.

One first decides
Do I want to set my working path EVERY time I change projects should I decide to keep the shortcuts folder in the project folder. This is due to lack of true project support being native to C3D. Or does one want to keep all data shortcuts in a single folder?
Then one Creates a new folder for the data shortcuts from Prospector>>Toolspace [Master Virew] Datashortcuts.
Then one sets the working Folder there.
Then one can create the data shortcuts.
To use the newly minted shortcuts, Exit and Save the file.
Start NEW file. Save and Name the File
Then one Creates a new folder for the data shortcuts from Prospector>>Toolspace [Master Virew] Datashortcuts, one then Creates a Reference to the short cutted(?) data, Datarefs are similar in function to DWG XREFS in that one can see the data and change it's Style, however on must try hard to accidentally edit the data.

Let's see if I get this right. I have a base dwg that I have a master project. Say in phases and I have my data shortcuts established for the first phase and now I want to procede with a second phase. I take a blank dwg and import my data shortcuts and I can now see and work with my networks, surface etc. So, I now add on the the pipe of a new street adding to my pipenetwork and surface. Do, I now export my updated network into the base dwg so long as nothing new has been done to it. Or is it going to be a meltdown and I make the orginal object data corrupt. Does it know that a network is duplicated and updated or just what kind of results can I expect doing this tool? Is this a smart data shortcut, or a dumb one?

Mike

[mjfarrell]

the short cut lets you see the first phase, true.

when you do the second phase work and import it into the base it will most likely NOT become part of the same network, you might have to do that by exporting BOTH runs to XML and merging the files to make them all part of a single network.

[doggarncity]

the short cut lets you see the first phase, true.

when you do the second phase work and import it into the base it will most likely NOT become part of the same network, you might have to do that by exporting BOTH runs to XML and merging the files to make them all part of a single network.

I haven't done a merge of XML yet, just how would you do that to make one network?

Mike

[mjfarrell]

open in a text editor each pipe run, follow the format therein and take the second phase pipes and combine into the first. them import the newly merged pipe run...

NOTE this is an unofficial work around, that I learned together with our good friend Dinosaur as he was fighting various pipe issues.  So he is our resident expert on merging XML pipe runs...

[Dinosaur]

Here is a rundown of what I had to do to get this to XML merge to work.  First I chose the main network I wanted to build upon and then export an XML of each run then deleted the one I wanted to merge into the main network from the drawing along with the parts and alignment for the discarded route.  After making sure there were no duplicate part names in the XML files, I edited the network name in the XML file with my text editor to match the name of the remaining pipe network in my drawing and imported the XML file and adjusted the part names along with reference alignments and surfaces in toolspace.  Tedious work, but less time than redrawing the network.  This was for sanitary networks that always behaves better than storm for all of the reasons I posted elsewhere.  I would expect a fully massaged storm network designed to structure walls to have all parts revert to structure centers with all pipe lengths and slopes fully borked.