Folks:
I am having a network configuration issue which is baffling me at the current moment. Attached, I have a couple of screen shots: one from OpenRoads Designer, and the other from OpenBridge Modeler/ Designer. In moving our files to the network, I made a change to the WorkSpaceSetup .cfg file, and to that file ONLY. This file only reroutes the data storage from the local c:/ default to a a place on our network where our Civil_Organization standards are placed. In both programs, I have access to our standard MicroStation, OpenRoads and OpenBridge data EXCEPT for the fact that the OpenBridge Explorer is not showing additionally accessed dgnlib's from any other area than the Organization-Civil\_Bridge Default Standards - Imperial\OpenBridge Modeler\Dgnlib\Feature Definitions\Bridge_Features_Levels_Elem Temp Imperial.dgnlib. The CIVIL_CONTENTMANAGEMENTDGNLIBLIST configuration variable for both programs clearly shows that this information is being accessed in both OpenBridge and in OpenRoads, but it actually ONLY shows up in Explorer for OpenRoads. As such, I cannot access any of the feature definitions from my additional libraries within OpenBridge. For both programs installed at their default local drive (c:/), these libraries all show up just fine. My workspace as is installed on our network is identical to the default Imperial Standards.cfg which is installed locally by default.
As my local and network installations differ by only the location of the Organization-Civil (My_Civil_Organization_Root variable) within the WorkSpaceSetup.cfg file, I am at a loss as to how OpenBridge allows access to some information (element templates, levels, dimension styles, text styles, etc. for all configured libraries) but does not allow access to any other features than what are stored within the Bridge_Features_Levels_Elem Temp Imperial.dgnlib.
Any help/ ideas will be much appreciated.
OpenRoads Designer 2021 R1
OpenBridge Designer CONNECT Edition Version 10.09.01.15
Thanks!
Mark
Hi Mark,
I believe this is because your ORD dgnlibs use a newer Civil schema than OBM (10.09). OBM builds adopt the matching ORD Civil schema, so OBM 10.09 uses the same schema as ORD 10.09. This also happens with OBM dgnlibs using an older schema.
If you can't move to OBM 10.10 you may need to downgrade the dgnlibs to 10.09. I think they should still work OK in ORD 10.10.
Regards,
OpenRoads Designer 2023 | Microstation 2023.2 | ProjectWise 2023
Answer Verified By: Mark Plum
Did these dgnlibs work fine when used in your local workspace?
Mark:
Your thinking is quite brilliant, and may make the only bit of sense here. It is almost 9:00 PM where I reside, but I will certainly do some research along your manner of thinking when I get back into the office tomorrow. I will certainly follow up on this thread!
Thanks so much, brother!
To answer your question here, yes, they did work fine locally, but they were also Bentley default dgnlib's, while our OpenRoads settings were already on our dedicated network location. Copying our network OpenRoads configuration to the local location resulted in the same issue as I have mentioned in my initial post; well, of course it did as these were files from a later schema. Copying an older Bentley dgnlib from the local location to our network location resulted in the file being read fine.
I appreciate your quite shrewd insight, here. You are absolutely correct in your assumption that the later schema would not be read correctly in all aspects with the earlier schema of OpenBridge which we have employed. Rather than downgrade my OpenRoads dgnlibs, I upgraded OpenBridge to the later 10.10 version- that you recommended- and all is syncing perfectly now.
Thank so much for your help, Mark, and Kind Regards,
Have you setup a ProjectWise managed workspace with this configuration?