[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.

  • 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
      
  • If you have your configuration up and running, then your co-worker cannot say it is wrong. It is just not how she thinks it should work. Did she state why the configuration needed to be on the local machines, rather than on your network ? I have witnessed our networked configuration cause considerable slowness, but this is mainly due to the network and not really the configuration. In any case there are specific offices where we have them set up locally.

    Now for the DGNWS file, there needs to be read/write access if you plan on using it fully. A few variables that will help locate it with the other project data accessed by your users are: _USTN_WORKSETDGNWS, _USTN_WORKSETDGNWSTEMPLATE, and _USTN_WORKSETDGNWSROOT

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • 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

        

  • She comes from working at Bentley, so she is very staunch about doing things the Bentley way. I don't know how much practical experience she has in the production world. The Bentley way is great for what it is, but the real world is much messier and rarely ideal.

    I don't know why she would insist that configurations be local, other than that's the Bentley way, and it requires no network administration.

    Her approach is to use the Bentley way so that MicroStation/ORD sets everything up. That way, anyone can create a workset and it will work with no additional effort. That's commendable, but I can see that moment where someone makes a "new" workset for a project that already exists...Our regular (corporate) project creation is really strictly locked down, and I can't help but think that workset creation should be as well, at least a little bit.

    I just worry that I am being too rigid and inflexible, thinking that I have the only solution. Maybe I am. And my solution isn't super robust, so I know I still have bugs to work out (I have trouble closing a drawing, then selecting another workspace to do something else). I'm a cranky old lady now Upside down But I don't want to upend our project directory structure if we don't have to, and I think we don't have to.

    I guess part of the point of this post is to hear how other people are doing things, and to get some confirmation that, while this might be unusual, it's not WRONG.

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2

        

  • This is the same experience I'm having with the root directory being greyed out when selecting an IDOT template.  Our folder structure will not change, that's a guarantee. We using both cad systems so it's just not happening.  I just want to tell it where to place the files when setting up a new project within our file structure.  It's the typical by year, project, then subfolders.