Named Boundaries and Plan Production

We are having some issues with understanding the ORD Plan Production tool set and controlling level overrides in the drawing or sheet models.  When we create a series of plan and profile sheets, we start with a fresh 2D seed file, reference in the necessary reference files, turn on/off levels or set level overrides for the plan set’s needs in the design model, and then use the ORD Named Boundaries workflow to create the drawing models and sheet models.

 

The problem that we are having is none of the level overrides are being honored in the resulting drawing or sheet models.  Additionally, if we need to make any changes to the level on/off settings or additional level overrides from the host design model, none of these changes are dynamically shown on the drawing or sheet models.

 

We typically have hundreds of plan and profile sheets for projects and having to manually set the level on/off or overriding symbology is not a workflow option.  Our preferred workflow would be to have a single design model used for controlling all of the sheet model level settings.

 

Is this a known problem with ORD Plan Production?  Thanks in advance for any help.

Parents
  • Hi Chris,

    I've been looking for a solution to the exact same issue and have found that adding this config variable to your workspace seems to do the trick:


     MS_LEVEL_DO_NOT_OVERRIDE_DESIGN_LEVELS_IN_SHEET = 1


    In ORD I can now control the level display in my 3d model and see the cross section drawing and sheet models are synced automatically (or with reference reload if the cross section drawing/sheet models are open in a view).

     

    This is what MicroStation Help says it does:

    Controls the overriding of design model level properties in sheet and drawing models. If set to 1, the level properties of a design model and its reference attachments cannot be overridden in a sheet or drawing model. They will be the same as when the design model is opened directly.

     

    Regards,

    Mark


    OpenRoads Designer 2023  |  Microstation 2023.2  |  ProjectWise 2023

  • Thanks Mark for the help.  Unfortunately this didn't fix our problem, but did result in another weird other issue.  When using this variable we are not able to edit the "drawing" or "sheet" model reference file levels, which is the intended result of the variable, but we also noticed that the the displayed reference file level settings in the "drawing" and "sheet" models don't match any of the level settings set in the same model.  As I said, it's a really weird issue.

    I'll keep the question active to see if anyone else has ideas.

Reply
  • Thanks Mark for the help.  Unfortunately this didn't fix our problem, but did result in another weird other issue.  When using this variable we are not able to edit the "drawing" or "sheet" model reference file levels, which is the intended result of the variable, but we also noticed that the the displayed reference file level settings in the "drawing" and "sheet" models don't match any of the level settings set in the same model.  As I said, it's a really weird issue.

    I'll keep the question active to see if anyone else has ideas.

Children
  • hmm...perhaps another level variable somewhere interfering with the process? We've been using it for months quite successfully, but I suppose different workflows may give different results. We can edit the levels but they "reset" back to match the source model.

    Regards,

    Mark


    OpenRoads Designer 2023  |  Microstation 2023.2  |  ProjectWise 2023

  • I know in the past, if any level changes were made in the sheet itself, then any further changes in the container file would get brought through. Something about the sheet level table taking preference over the container attachment level table. And there was no way to resync because "Update Levels" went all the way back to the DGNLIB instead of the overrides set up in the container. The only way to get things to match up again was to un-nest the container, save the drawing (I'd usually close it and open it again), then re-nest the container. If that didn't do it, I had to detach and reattach.

    I don't know if that's related to this because I haven't played around with "drawing models" yet (not on CONNECT at this point). But it might be.

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2

        

  • If you make changes in the Source Model, you then need to update all the Saved Views which are used by ORD in the Drawing Models and then into the Sheets.

    That is why i suggested a Display Rule DGNLIB as it would allow you to control what colour, level on/off for a whole set of drawings without having to update potentially 100s of Saved Views

    Regards

    Chris


    AECOM Roads UK&I Digital Engineering, Design & Solutions Lead | Sector Information Management Lead

    Associate Director – Digital

    OpenRoads Designer 10.12 | MicroStation 2023 | ProjectWise CE 10.3.4 | ContextCapture | ProjectWise PowerShell 2023 | ProjectWise WSG API | Generative Components | OpenBridge Designer 10.12

    Civil 3D 2023 | Dynamo | Navisworks Manage

    PowerShell | Visual Studio | Office 365 | Power Platform | Teams | SharePoint | Visio

    Speckle | BIMVision | Revizto | Solibri

  • I'm not a fan of saved views because of all the updating that needs to happen (just like this)...Still sad to hear that is what we are going to have to use.

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2