Civil Display Browser - Why was it's functionality removed and what is the new workflow?

We recently learned that the ability to repair relationships and remove civil rules from elements was removed from the "Civil Display Browser" key-in functionality in OpenRoads Designer. I have scrubbed the communities and have found no acceptable answer to why this was removed or what the new workflow might be to resolve issues with civil rules.

First of all, the key-in command is hidden and is not something the average user will stumble upon when using the software. I do believe it should remain hidden, but the full functionality was very useful for administrators and power users to resolve problems with civil elements quickly and efficiently. We can’t be expected to send a file to Bentley for analysis every time we come across a corrupted file or element. The time this would take makes it impractical, especially when we had a tool that did exactly what we needed before.  Using the tool can absolutely mess up a file as easily as it can fix it. As they say, with great power comes great responsibility. But to think users that know about the command, understand the information it provides, and know the implications of rules and design intent can't use a tool because it might break something is insulting.

Here is a scenario that I was personally involved in where the repair relationships tool in Civil Display Browser (PowerGEOPAK SS4) saved countless hours of work. We had a rule on our mainline alignment that was corrupted. We had no idea why or what happened but it was causing all kinds of instability with our other files. The alignment is the most important element in any project because of all the elements that reference and rule from it. We had roadway geometry, corridors, off-site models, driveways, side roads, storm sewer, water main, and more, all referencing that one element in some way. Obviously, recreating that alignment would have caused an enormous amount of rework to get the other files to associate to a new alignment. Civil Display Browser was able to isolate the issue and repair the broken rules and the project went on without any interruption.

Another issue we had was after we converted some SS4 projects to the new ORD format. The files had no issues prior to the conversion process but the files were riddled with broken relationships after the conversion. A few files would crash instantly after selecting any element. Luckily, the projects were in their infancy and to recreate them wasn't a major issue but still caused about a week of headache and rework.

So, why the tool was removed in the first place, can it be brought back, and what are the alternative workflows for the scenarios mentioned above?

Parents
  • Jack this tool was implemented as a development / support aid to help identify and trace potential issues with files and it still does that. It was never intended to be in general use as it seems to have become and I always ask to anyone trying to use it 'what did it actually repair?' as there are lots of assumptions on what it could / couldn't do. 

    The command actually did a variety of things to help with file investigations specifically to civil rules, like removing broken rules that render elements inert with no ability to heal, strip relationships that are possibly from missing references or where files have been replaced with a different file version meaning the rule does not find matching element id's, to name a couple of the simple scenarios. The results of the 'repair' actions are misleading since it doesn't 'repair' but deletes broken rules so while it might appear to 'fix' something, in many instances it actually made the situation worse with static models and further rule failures further downstream.

    The information this tool provides was always intended to help trace and solve issues in other ways and I appreciate why you'd like it reinstated  the best option is where it identifies file issues please contact support that way we can investigate, repair and hopefully prevent the issue from occuring in the first place.

    Regards

    Ian



  • >The results of the 'repair' actions are misleading since it doesn't 'repair' but deletes broken rules so while it might appear to 'fix' something, in many instances it actually made the situation worse with static models and further rule failures further downstream.

    You're right. But it's not that simple.

    Can we just be a little bit honest and acknowledge that 90% of the 'workarounds' are simply destructive and, assuming they do anything at all, simply give us a freshly initialized file that replaces the bugged one?

    If we are to learn anything from these fixes, based on the user's aptitude and timecrunch, it's one of these two:

    1. I learned what file to delete, and I learned how that affects me as a user because now I have to set up all my buttons like I had them.
    2. I learned what file to delete, so now it's up to me to ferret out the buggy behavior that I observed so that I don't have to delete this file again.

    Civil Display Browser allows us to do this in one more context.

    And if you don't think it does what you think we (ought to) want it to do, then why not provide that functionality instead?

Reply
  • >The results of the 'repair' actions are misleading since it doesn't 'repair' but deletes broken rules so while it might appear to 'fix' something, in many instances it actually made the situation worse with static models and further rule failures further downstream.

    You're right. But it's not that simple.

    Can we just be a little bit honest and acknowledge that 90% of the 'workarounds' are simply destructive and, assuming they do anything at all, simply give us a freshly initialized file that replaces the bugged one?

    If we are to learn anything from these fixes, based on the user's aptitude and timecrunch, it's one of these two:

    1. I learned what file to delete, and I learned how that affects me as a user because now I have to set up all my buttons like I had them.
    2. I learned what file to delete, so now it's up to me to ferret out the buggy behavior that I observed so that I don't have to delete this file again.

    Civil Display Browser allows us to do this in one more context.

    And if you don't think it does what you think we (ought to) want it to do, then why not provide that functionality instead?

Children
No Data