Best practice for documenting design changes in ORD

Hi all,

I'm reaching out to the community at large to please share some inisght or practical experience with documenting design changes in ORD. We're having some issues on a current major project where the design isn't behaving as it should between corridor re-processing and it is becoming increasingly difficult to track down if it is due to unintentional changes by the designer or whether it is an issue with ORD or the templates.

A previous thread I posted (https://communities.bentley.com/products/road___site_design/f/geopak-inroads-mx-openroads-forum/215324/ord-2020-r3-output-log-similar-to-mx-output-window/655747#655747) was the start of this where we were trying to find the way to track the processing done by ORD but the answers I received confirmed what we thought after we had first searched ORD quite extensively ourselves.

When we used MX, we would document any changes made in the header part of the relevant input file. This changelog was commented out and grew as the input file grew, but it was useful to see who did what when and where in the input file so we could start there to identify any obvious errors (typo's, use of incorrect strings, etc.). The benefit of this method was that the changelog was contained within the input file itself and was part of the design package so it was relatively simple to keep up to date. An example is provided below:

What I'd like to know is how do you all track your design changes? Design History, direct text table or text elements in DGN file, separate Microsoft Word or Excel register? Personally I'm a bit reluctant to use an external file or process as it just adds an extra layer of activity to an already constrained team, so ideally something inside the DGN or within MicroStation would be advantageous. In saying that, if the general consensus is to use an external file or mechanism then I guess we must just bit the bullet and get moving on it!

We are running OpenRoads Designer CONNECT Edition - 2020 Release 3 and we are not using ProjectWise.

Any advice or insight will be greatly appreciated!

Thanks,

Chris

Parents
  • Hi Chris,

    This is something we're still trying to iron out as well. We investigated Design History but it quickly bloats your DGN as it records every thing a Corridor process does and can destroy your file if a user Restores a specific change (and there is no way to just disable this).

    One thing that you can do is actually embed an Excel spreadsheet in your DGN in an extra Drawing model for example (using the Microstation OLE tools). It is quite compact and works well. The hardest thing is making sure people use it. Unlike MX input file comments, its not in your face so it will be harder to make sure users fill the spreadsheets out.

    Regards,

    Mark


    OpenRoads Designer 2022 R3 (10.12)  |  Microstation 2023.1  |  ProjectWise CE 3.4

Reply
  • Hi Chris,

    This is something we're still trying to iron out as well. We investigated Design History but it quickly bloats your DGN as it records every thing a Corridor process does and can destroy your file if a user Restores a specific change (and there is no way to just disable this).

    One thing that you can do is actually embed an Excel spreadsheet in your DGN in an extra Drawing model for example (using the Microstation OLE tools). It is quite compact and works well. The hardest thing is making sure people use it. Unlike MX input file comments, its not in your face so it will be harder to make sure users fill the spreadsheets out.

    Regards,

    Mark


    OpenRoads Designer 2022 R3 (10.12)  |  Microstation 2023.1  |  ProjectWise CE 3.4

Children
  • Hi Mark,

    Yes Design History seems to be like Tracked Changes in MS Word so the bloat to the DGN is understandable! Your suggestion is essentially what I'm thinking of doing as a start: an embedded spreadsheet that is two-way (user can edit in DGN directly or edit in Excel directly and changes can be seen vice versa) and place the table close to the actual design as a construction element on a non-print layer.

    Enforcement will be the main issue though, but we have to start somewhere - at this stage we're spending more time trying to track down the issue(s) rather than just documenting them in the first place!

    Regards,

    Chris


    OpenRoads Designer 2020 R3 Update 9 (10.09.00.91)  |  Microstation PowerDraft v8i SS10 (08.11.09.912)  |  Previous MX User