Hey all,
This is basically a bump of an older topic but I feel it needs to be pushed. Parametric cells and active level attributes don't work well together. Other cell types will take on the active level attributes for the geometry within the cell that is set to default (by level). However, Parametric Cells don't do this. Bentley's response is "Parametric Cells aren't supposed to work that way" which my response is Why? Why would you cripple a very powerful tool. the intent of a parametric cell is to create variants of a single cell so we don't have to have an individual graphic cell of the same component for 10 different variants. Yes, I understand that they can also be used as extrusion profiles for 3D geometry as well.
The current tool as it stands in CE15 allows for Graphic cells to use preset levels within the cell file to maintain a graphical standard AS WELL AS allow any line whose attributes are set to default and by level to take on the active attributes in the dgn file in which it is place. this shows that cells can have a dual functionality in regards to level display so why is it that Parametric cells can't do that?
Here's an example of what is needed...
Let's say we have a bridge that we are widening. when viewing a typical section of the Girders, we show New and Existing components differently. so we will have existing Wide Flange girders, shown with a phantom line style. This bridge will use the same girder type on the widening, but new will be shown with a solid line style. Both will be in the same section view, with the new geometry connecting to the old. Now, bentley's proposal is to have a parametric cell library for new and a parametric cell library for existing... but a WF girder is the same regardless of STATUS. each girder type also has multiple variants (WF36, WF42, WF50, etc...) which is why the parametric cell is very appealing in this situation.
Another example is...
on a new bridge project we have traffic barriers. Parametric cells are used here as well due to the fact that we have multiple variants of the same barrier type. The barrier will be placed on a NewBarrier level. The difference here though is that at the base there's a construction joint that stays the same regardless of phase. It comes in as a thick dashed line. in a GRAPHIC cell I can set the barrier line to default and by level, and have the construction joint line set to a ConstructionJoints level with the linestyle and color set. In doing this, when placing the graphic cell into a dgn, anything set to default and by level will take on the active level attributes within the dgn, but the construction joint will maintain it's level and linestyle attributes as set in the cell library file. However, again the Parametric cell fails to do this and instead maintains the Default level attribute (white, linestyle 0, weight 0). The reason we would need the default to take on the active level attributes becomes apparent in any future projects.
Let's say this bridge after a few years has a repair or retrofit project. rather than redraw the whole thing we can take a copy of the existing model to modify (this reduces the likelihood of errors). Those barriers could then be set to an ExistingBarrier level and the line style would update to reflect. with the current version of the Parametric Cells tool, we would have to delete the barrier and bring in an existing barrier cell. No geometry has changed, just its STATUS.
The last example is more of a reasoning to use parametric cells over a mass library of graphic cells...
First, the cells that are created as parametric have multiple variants, so if anything changes with the base design for all variants, it's easier to update in one place. It also creates less for our drafters to have to sort through to find the cell they need. If they need a WF50 girder, rather than sort through all the girder cells, they just find the WF cell and set the variant to WF50.
Second, during design we may have multiple iterations and what variants of certain components such as Girders or traffic barriers that were placed in the preliminary plan may change. It's common that a bridge will have a standard height single slope 36" traffic barrier and perhaps WF42 Girders in prelim. Then as design moves forward, we need to change to a single slope 42" barrier and WF50 girders. Rather than delete these cells and insert new ones, with parametric cells we could simply select the current components within the dgn, select the variant in the properties window and update them there. This is why we want to rely on the functionality of parametric cells in 2D at this time.
So to sum things up, we are asking that Parametric Cells function more like graphic cells display wise in that we can hard set the level and line styles within the cell library file if we need to, AS WELL AS allow for anything set to default and by level to take on the active level attributes of the dgn file in which it is place.
Thoughts?
This has me rethinking my disregard for parametric cells.
As a roadway engineer, I had thought of parametric cells as "a mechanical thing" that I'd never have a use for. Your description of using parametric cells as a medium to shift between existing and proposed intrigues me. I can also think of a few roadway incidentals that might actually be very good for parametrics (metal end sections for one...). I can definitely follow your workflow, and your explanation of what you want to do and why.
MaryB
Power GeoPak 08.11.09.918Power InRoads 08.11.09.918OpenRoads Designer 2021 R2
They are definitely a powerful tool. in our workflow, the ability to assign it to a level and take on that level's attributes is how we would differentiate between existing and proposed, but you can do so much with these. You can assign expressions to constraints that calculate a condition in the background for a simple user input. I was making a bridge deck cross section that has the ability to calculate the angle for a given slope of the roadway. The constraints use only common dimensions (linear, angular, radius, that sort of thing) but with the proper expression set up, the user only needs to input a grade percent (i.e. 2) and the calculation runs in the background and sets the geometry to the proper angle.
another nice thing is that let's say for roadway you have specific details for catch basins, barriers, or guard rails. if you have variants of these, like (made up example here) a catch basin 1, Catch Basin 2, and a catch basin 3 that are identical in shape, just different sizes, you could make one single cell with the dimensional constraints, then create the variants associated with it. that way when placing those, you only have to insert the catch basin cell, and select the variant you want. it makes design changes much easier too. Lets say you have these type 1 basins allover a project, but hydraulics comes back and says we need type 3s to better facilitate drainage, you just have to select all the basins, then in the properties window you can select the next variant without having to do much else. I've attached a few images showing what I'm talking about.
Inserting the Parametric Cell and selecting variations
Updating existing variations of the parametric cell (note, the selected cell on the left gets updated to match the one on the right)
Hi Cory, thanks for your post. Parametric Cells are - from a data structure point of view - very different from graphic cells and were originally designed with a much narrower scope.
We are looking at combining both behaviours, if possible, so that you will have the best of both and have more flexibility for what can be changed at instance level.
Thanks for the response. I'm glad to hear you will be looking into this and, if possible, hopefully implementing these behaviors to ultimately increase the functionality and flexibility of these cells.
Cory, can i aske you to please post this as an idea in our idea page?
Thanks
will do.
Idea has been submitted. (MSR I-656)