Folks:
I am having an aggravating but also consistent issues with Item Types assigned through my Drainage and Utilities dgnlib. When placing these Items- which have the Pay Items assigned to them via the dgnlib- they are "duplicated" in the Details listing (as well as quantity reports). As seen, there are five conduits which report (ignore the expression faults ;-)) correctly. These Item Types are assigned after the "conduit" is placed and work well whether an active SUDA conduit or merely a line assigned an Item Type (first five lines of the query). As is seen, there are only four headwalls attached to two conduits, but the report show there to be eight headwalls total. Retrieving the properties of the headwall shows that only one Item Type has been assigned per headwall. When I rotate through the Item Types via Explorer, each headwall highlights for both construction class elements for the headwall (placement and rotation options), and then the 2D headwall in situ. Turing off the Construction class for the view changes nothing.
Does anyone have any idea as to why this is happening or a possible fix?
OpenRoads Designer 2021 R2, 10.16.02.16.
Thanks in advance!
Mark
Update 2022.11.08
So, I tried the following:
I added a new feature definition to the dgnlib and assigned an Item Type to it; in this case a 4' diameter manhole. I did not copy this definition, I created a new one. Upon using it, it did the same thing as before, duplicating the Item Type (one manhole feature created two of the same item types). I then created a fresh feature definition, and did NOT assign an Item Type to it. As should happen, placing this definition produced no Item Type. However, when assigning an Item Type to it in the dgn test file, the assignment produced two identical Item Types assigned to the feature.
I have two Item Type libraries, one assigned to the features annotations dgnlib and one assigned to the DA dgnlib.
I have no idea as to why this is happening, but if it is happening to me, it must be happening to others. It must be something simple (and seemingly universal), but I cannot figure it out. Any ideas or help that y'all may be able to provide would be so appreciated.
Best Regards,
Hi Mark,
Have you tried to run a test again but loading this time only one of your dgnlibs that contain Item Types?
I had a similar issue in the past with Annotation groups that were stored into two dgnlibs.
Have you made sure that those dgnlibs do not contain Item Types with the same name?
Razmik:
Thank you so much for responding to my inquiry. I have tried doing as you have mentioned, but with the same results (I actually have my SUDA Item Types completely segregated into the SUDA Library, and the Features Item Types (Pavement, etc.) completely segregated into that Library). I have done some further investigation and see something troubling happening:
It seems that both the node and a "default" copy is coming in with the node, and I have no idea as to why this is happening; however, such seems to be the issue. I have checked the SUDA cell library for issues, and the default level is not used there at all, and the "default" level is only used in the file as I have pictured here AFTER the node is placed.
One other thing: This issue is not happening with conduits at all, only nodes. I fear that there is something wrong with how the nodes have been created, but have no idea as to what that could be.
Is there anyone at Bentley who wishes to chime in on this thread?
Bentley folks!!!!
I NEED A RESPONSE FOR THIS ISSUE BEFORE I EVEN POSTED THIS ORIGINAL MESSAGE. WHY IS THIS ISSUE HAPPENING??????
Hey Mark,
I bet this is the "single source of truth" where the Item Type from 2d gets propagated to 3d and vice-versa?
Regards,
OpenRoads Designer 2022 R3 (10.12) | Microstation 2023 | ProjectWise CE 3.4
You assume too much from me, friend. I am still working in the previous "multiple sources of truth ORD". Have you seen this happen? The issue is completely consistent across all node definitions, and conduit definitions remain with a single Item type. In l reality, we can eliminate every second item type on export from ORD Details to Excel, but that can be a bit confusing and is certain to promote error.
Overall, you might be on to something where possibly the 3D and the 2D definitions are the issue for duplication?
I appreciate your help. You have always been so helpful to the community.
Kind Regards,