I am working on building out SUDA feature definitions. It was my intent to build two DGNLIBs for this effort, one for proposed and one for existing. The proposed utility DGNLIB is the SUDA seed file for hydraulic properties. In building the existing feature definitions, I created a utility project in the existing DGNLIB and then used the prototypes created with that in the existing Feature Definitions. When creating a network in a new (clean file) the nodes hold the prototype but the conduits do not. Has anyone seen similar, or been successful in using a secondary DGNLIB for conduit Feature Definitions?
Nodes are created properly, referencing the prototype assigned in the existing utility DGNLIB. Active File shows the prototype and allows changing, Library shows the assigned prototype, grayed out.
Conduits will not place giving the error below anytime an existing utility Feature Definition is selected, or you pass over a node with the Feature Definition in the Place Conduit dialog.
In the Explorer, conduits show that there are not any prototypes available.
Any thoughts appreciated.
Thanks,
Steve
There are no technological risks to your plan. This whole area of conversation is just administrative challenges. If there is only one admin then having a single file is convenient for maintenance. But when the work load needs to be spread around then multiple files are handy. Where things become a real problem is when the administration of the files is dispersed to multiple groups within an organization which are only minimally connected to one another.
Example: an organization I know is only loosely connected between units of the organization. The utilities ggroup (think sanitary sewer) is very separate from the hydraulics unit (drainage design). Both groups maintain independent libraries yet both groups need hydraulic design capability, ie a single SUDA seed.
The solution is simple right? Just put the sanitary stuff into the hydraulic library which is my standard practice. But that solution assumes that one group will cede or share ownership of the library with the other group. See what I mean about being an admin problem rather than a tech problem.
Robert Garrett Senior Consultant
www.envisioncad.com
Folks:
What I wound up doing here was to have a combined SUDA library for both existing and proposed structures, and used directories/ templates divided into a "Proposed" and "Existing" schema. Such allows us to utilize the SUDA seed file as Bentley has designed as a single library instance. It does make for a very large library, but it "seems" to work fine here (with the caveat that I may not be correct in the design for reasons which Mr. Garrett- in particular- may further explain); however, our cell libraries for Inlets, headwalls, valves, etc. are separated into Proposed and Existing libraries such that that they may be more easily refined. If any of you folks perceive an inherent danger in doing what I have done, please speak up! It is better to redesign a few things during development than to see a major flaw during design.
A year old thread, shows up in my search about Hydraulic Prototypes with a response literally hours old! What are the odds. And not only that, but it answered my question spot on!
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration
Steve: This is a deficiency in the software which creates great challenges for many. I reported this for enhancement some months ago.
Here's what happens:
The only workaround I have found to date is to make a special seed file for utilities where the necessary prototypes are pre-populated. This is not a trivial task and must be redone from time to time to keep the seed in synch with the library.
On a more technical note: The OpenRoads drainage and utilities tools are a merger of openroads and Haestad technology. This merger is not trivial and was anticipated to take multiple years. Some of the last vestiges of the items not merged are the hydraulic properties and settings which still live in a 100% Haestad context. Once these cross the threshold and become native (for OpenRoads) properties then these challenges go away. For example, one of the items which exist in your conduit prototypes is roughness coefficient. This needs to become a native property of the feature definition rather than a pointer from the FD to a prototype. This is a pretty heavy lift for the Bentley development team.
Stevem - I am having the exact same issue. Everything set up and working/ showing fine in the DGNLIB. Then within the new file it looks like the hydraulic property detaches itself, only for conduits. I have a colleague looking into this just now i will try and report back if we find a solution.