The workspace/workset rabbit hole has no end.
I'm starting with one client. Trying not to edit those client configs. This client comes with a workset template - folder, CFG & DGNWS.I wanted to see if that template is actually what is used to create new worksets under that client.
Apparently, it's not.
I was able to create a new workset. I selected "Create Workset", gave it a name and selected the template I would like to use. It created a folder, CFG & DGNWS in the proper location. But the folder doesn't include the files from the template folder and the CFG is not the same as the template CFG (far more generic, not even close). It would appear that the template being used is not the template I selected? Or is the CFG file unrelated to the template workset?
I am getting lost in the CFG variables, so I'm sure I have something crossed up. Can anyone make a suggestion to straighten me out?Thank you.
OK, so the issue is with one specific client, but I'm still running into other issues.
The rest of the templates that DO appear to give me CFGs from the proper template aren't creating directories. Now, I don't actually need those directories there but...
As much as I don't want to edit the client configs more than necessary, I did have to add a block to account for they way we store our data. That gets edited after workset creation to the proper project directory, and it includes "placeholders" for files that are about to exist.
# Template for a new WorkSet
PROJECT_YEAR = 2022
PROJECT_NUMBER = WS_Test
PROJECT_DIRECTORY = $(SHR_PROJECTSDIR)$(PROJECT_YEAR)/$(PROJECT_NUMBER)/
_USTN_WORKSETROOT = $(PROJECT_DIRECTORY)CADD/Design/
PROJECT_CADD = $(_USTN_WORKSETROOT)
MS_DEF = $(PROJECT_CADD)Base/
MS_DEF > $(PROJECT_CADD)Sheet Sets/
MS_RFDIR = $(PROJECT_CADD)Base/
MS_RFDIR > $(PROJECT_CADD)Sheet Sets/
%if defined (CIVIL_WORKSET_TEMPLATE_LIBRARY_NAME) && exists ($(PROJECT_CADD)ORD/$(CIVIL_WORKSET_TEMPLATE_LIBRARY_NAME))
CIVIL_ROADWAY_TEMPLATE_LIBRARY = $(PROJECT_CADD)ORD/$(CIVIL_WORKSET_TEMPLATE_LIBRARY_NAME)
%if defined (CIVIL_WORKSET_DESIGNSEED) && exists ($(PROJECT_CADD)ORD/$(CIVIL_WORKSET_DESIGNSEED))
MS_DESIGNSEED = $(PROJECT_CADD)ORD/$(CIVIL_WORKSET_DESIGNSEED)
My thought was that, if the workset creation makes a copy of the workset template directory, that copy could be moved into the project to the proper location, renamed "ORD" and be ready for design with the proper files.
Power GeoPak 08.11.09.918Power InRoads 08.11.09.918OpenRoads Designer 2021 R2
I found it.
#set up workset variables
_USTN_WORKSETDGNWSTEMPLATE = $(_USTN_WORKSETSROOT)TDOT_RDWY_TEMPLATE.dgnws
_USTN_TEMPLATEWORKSETNAME = TDOT_RDWY_TEMPLATE
_USTN_WORKSETTEMPLATE = $(USTN_WORKSETSROOT)$(USTN_TEMPLATEWORKSETNAME)
Workset templates were provided, but not defined. Once I found these variables, I was able to get "proper" worksets.
What issues are you seeing with it in a different location? All our Projectwise ones have them separated, but I'm not sure we've used them extensively yet to actually hold sheet info so we may not have seen the issue yet.
The main thing is they do not retain the Advanced/Custom WorkSet properties. You can create them, but next time you open the WorkSet they are gone.
Rod WingSenior Systems Analyst
I am less concerned about people getting into the CFG file than I am having worksets that anyone could create and a DGNWS that everyone can write to. I am blessed/cursed with a team that are not power users, so once things are set up, they aren't likely to go poking around.
Unfortunately, the way it looks like I might have to set everything up to work with our data structure, I would need a variety of templates available. Our projects are organized by year, and not by client - any given year will have projects for any number of clients. KY might be 22-0057, IN could be 22-0103, TN could be 22-0126 and so on. Creating worksets through the standard interface would require all of those templates to be available to be picked as needed. This means that defining one single workset template doesn't meet our needs. MicroStation appears to only look in the WORKSETSROOT directory for both worksets and templates. I don't see a way to define a template directory separate from the rest of the worksets. It also means I would have to maintain workset templates in every different workspace so that the proper worksets could be created.
I can either define workspaces by client, and have to navigate between years, or define workspaces by years and navigate/%include clients. Year workspaces don't seem too bad - except for the workset template issue.
Since your clients will provide WorkSpace, use what they provide. It will make your life a lot easier.
That leaves you to navigating between years. You can put a year variable in your WorkSet template. I have clients that do that. After creating the WorkSet, the manually edit the WorkSet cfg to set the year and other custom path variables. A custom WorkSet creation tool would solve that problem.
So...keep the client workspaces but abandon their worksets directory in favor of a "S:\Projects\year\Worksets directory (for read/write access)?
Yeah, with that I'd HAVE to have a custom tool. If "Year" is defined in the workset, it can't be accessed by any process that happens before that, including "Create Workset".
I thought I was on the edge of understanding this well enough to put it all together, but I'm getting more confused again.
Workspace: ClientWorksetsroot: Many (by year, in projects directories) or one(in client workspace directory)Workset Template: One (client)
Workspace: YearWorksetsroot: One (by year, in projects directory) or many (in client workspace directory)Workset Template: Many (client)
Do i have the analysis right?
You don't have to separate your WorkSets by year. They can all be in the same folder with custom variables in the workset cfg directing them to the right path. We had proposed to some DOTs setting up the WorkSpaces-WorkSets by year as well. They thought there would be too much confusion as to what year to look in for the project.
We did some test for them and generated over 2000 WorkSets in a single WorkSpace for them. ORD handled it just fine, and there is a search option to search for WorkSet names so they were happy with that.
I was unaware of the search function in Worksets. That makes this much easier - we'd end up with a list of dozens and dozens of project worksets, but a search simplifies finding the right one.
We wouldn't have any issue with year based breakdowns because that's how our project directory is set up - everyone is used to looking at that sort of list. But the search will work fine.
To confirm...I really only need a "workset template" if I am creating worksets through the MicroStation interface, and I use "workset standards". If I have a pre-existing project directory structure, I only need a workset CFG file because the DGNWS will be created from that "seed" when the workset is first opened. Is that right?
That is correct.
Answer Verified By: MaryB
Thank you so much!