[ORD 10.10] Worksets vs data locations?

I know I've posted about this before, but I'd like to go over and discuss my situation once again. Some things I understand a bit better, whlie I still have questions about others.

I reproduced the "Configuration" directory structure on our network, using ConfigurationSetup.cfg and WorkSpaceSetup.cfg to redirect to that network drive. That seems to work well enough.

Our projects are stored on a Projects Drive, organized by project year, then project number, basically like this:

ORD/Connect configuration does NOT like this arrangement out of the box.

After a certain amount of trial and error for creating workspaces and worksets, I settled onto workspaces based on Project year and worksets by project number, with the workset CFG %include-ing the client standards configuration. Workspaces and worksets, including the workset CFG and the DGNWS, are saved into the network "Configuration" directory. Actual project CAD data is stored in the regular project directory as always. I developed a "front-end" VB .exe to gather project year, number and client to generate the workset CFG. The DGNWS is created from the client seed DGNWS when the project is first opened.

It's not the most robust solution, but it appears to be functioning.

We have a new employee who is very experienced with ORD, in terms of training and teaching. I'm not certain how deep her practical, project knowledge goes. She has told me that my approach is entirely wrong, and that we need to load all client configurations directly onto everyone's hard drive. She has also brought up concerns that, with my workspace approach, we will not be able to make full use of the DGNWS and will be missing out on a lot of useful features. Apparently the way around that is to move all of our CAD project files into the networked "Configuration" directory structure as worksets - out of the regular project directories. I brought up that we may not want to blow up the entire company way of storing project data, and she suggested that we just tell them that this is how it was going to have to be with OpenRoads.

I am willing to consider that I am overlooking some aspects of ORD setup with my ham-handed attempt to force it work with our existing directory structure. I'm sure I am not considering some advanced functionality that we could leverage for production. But I'm not convinced that we need to dictate how the entire company stores data just for the transportation department, and I'm equally unconvinced that our transportation projects need to have a different storage arrangement than every other project.

We are not using, and not (at this point) planning to use ProjectWise.

How do you all store your project data? Do you store DGN files in your ORD configuration, or does your company have a networked project repository? How do you account for that in your configuration, workspaces and worksets? I can see directing the worksets directory to the project drive to get it out from the Configuration directory (ensuring DGNWS write-access) but I don't think we could store the worksets with the actual project directories because defining configuration files to find them sounds impossible.

How do you manage locally stored client configurations? Are your users expected to keep them updated or does your IT department cooperate with you to "push" updated resources?

While the DGNWS sounds minorly useful, what features make it essential to project production? I know it can be used to fill out title blocks and create print sets, but is there anything else that we HAVE to have it for? And does it HAVE to be all defined on creation, or can properties be added to it after it is created. I know that you can't update it once it's in use, but could it be created from a seed file and then updated with the appropriate properties prior to project sheet creation? I don't know what I don't know, and I'll admit, I don't really understand why the DGNWS is so critical.

Are there other ways I could simplify or rework my configuration plan to work better with the Bentley preferences AND our corporate data structure?
Thank you.

Parents
  • Mary:

    I am going to directly address your second to the last paragraph immediately. The DGNWS has the capability to store ALL relevant project information unique to that project. Each WorkSet has its own DGNWS for precisely that reason. Besides the relevant project information, it also keeps track of the sheet numbering and the disciplines for which those sheets may be used. The DGNWS is actually required, and if it does not currently exist for a WorkSet, CONNECT series products will create it for you. As regards "... you can't update it once it's in use" is not true. You can add additional properties to the DGNWS at any time (if I understand your narrative correctly). THE DGNWS is truly one of the most powerful objects in the CONNECT edition products.

    I am attaching a snapshot of our default template. Keep in mind that each one of these labels is used by a field to automate our production processes, and these fields populate- in one manner or another- all of our default sheets and sheet.dgnlibs. Certainly, they keep basic typing errors within the sheets from happening as well.

    I will think on the other issues you have mentioned as I get more time!

    Best Regards,

    Mark

    Mark Anthony Plum
    Chief Technology Officer

    1601 N.W. Expressway, Suite 400
    Oklahoma City, OK  73118
      
Reply
  • Mary:

    I am going to directly address your second to the last paragraph immediately. The DGNWS has the capability to store ALL relevant project information unique to that project. Each WorkSet has its own DGNWS for precisely that reason. Besides the relevant project information, it also keeps track of the sheet numbering and the disciplines for which those sheets may be used. The DGNWS is actually required, and if it does not currently exist for a WorkSet, CONNECT series products will create it for you. As regards "... you can't update it once it's in use" is not true. You can add additional properties to the DGNWS at any time (if I understand your narrative correctly). THE DGNWS is truly one of the most powerful objects in the CONNECT edition products.

    I am attaching a snapshot of our default template. Keep in mind that each one of these labels is used by a field to automate our production processes, and these fields populate- in one manner or another- all of our default sheets and sheet.dgnlibs. Certainly, they keep basic typing errors within the sheets from happening as well.

    I will think on the other issues you have mentioned as I get more time!

    Best Regards,

    Mark

    Mark Anthony Plum
    Chief Technology Officer

    1601 N.W. Expressway, Suite 400
    Oklahoma City, OK  73118
      
Children
  • So that sounds as if we could set up our configurations and edit the DGNWS after creation. The workset configuration includes the path to the DGNWS seed for the client, so that is created on the intital opening of a workset drawing. Or would it be better to have the configuration setup process actually copy and rename the DGNWS at that point, so the DGNWS can be set up with the appropriate properties before any file is opened?

    I have heard that changes to the DGNWS do not get propagated back to existing drawings, so I imagine most of the setup has to happen pretty early in the process. But that could probably be included in the directions for the "project initialization".

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2