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?
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
<Rant>
This response pretty much hits right at the frustration most end users have with ORD specifically, and Bentley in general. While the Civil Display Browser key-in was treated like a safety blanket for most of us and is a relatively minor thing in the picture, the elephant in the room that we keep ignoring is the instability of ORD and constant need for rebuilding, reimporting, recreating, etc. elements related to ORD. The fact that we have grown so accustom to using a tool to track rule-based relationship breaks/failures (the heart of OpenRoads technology) illustrates the instability and temperamental nature of the software. Many of us have bit the bullet and upgrade our projects, knowing that the program functionality will eventually catch up, or at least we hope so, but I must agree with Jack – it is insulting when we are constantly told what is best for us by Bentley, when they have no idea how we operate, or understand the limitations of their own software. The impression we get is that there isn’t even an interest on Bentley’s end to even ask about how to improve functionality/create efficiencies. To boot, when end users make suggestions, enhancement requests, etc. at best it goes to the bottom of the pile or it is just flat out ignored – I hope this is related to making the program usable, and not an issue of pride. The point about contacting support at Bentley – 9 times out of 10, it is just quicker to rebuild a file than to send it off, have it looked at, then be told that we need to rebuild it anyway.
</Rant>
Don’t get me wrong – I like OpenRoads Designer / OpenBridge Designer, etc. and where the platform in general it is heading, but it is going to be painful for a couple years until all the products are truly ready for prime time. We have upgraded one of our current preliminary design projects ($500MM estimated construction value) with the intent of getting ahead of the curve, but we understand the current production limitations of the software today. We are just hoping these limitations get addressed sooner rather than later…*fingers crossed*
Justin Guiliano, PE
Rios Engineering, LLC
Again, I think you are assuming we don't understand how the tool works. Sometimes breaking the rules is exactly what we want, especially if that element is causing instability in the file. The tool may not be used how it was originally intended, but as Justin pointed out, you can't know exactly how we operate as end users. However, this was a good explanation of how the tool is supposed to work for those that might not understand.
What your answer still lacks is an alternative workflow. Rebuilding files and sending corrupt files for analysis isn't efficient or practical. I'm happy to send them on, but we can't sit idly by while we wait for an answer. Our clients won't accept software limitations and issues as a reason to move a deadline or incur more costs. We understand the software is evolving and improving, so even if the workflow is unpleasant it can't be worse than starting a file from scratch.
OpenRoads Designer 2023 | MicroStation 2023 | ProjectWise 2023
>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:
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?
Ian, you must be aware of these issues already (corrupt elements, crashing when simply hovering over an element with cursor). I am not aware of anyone using this product who has not experienced them from time to time.
Either the issues are so complex that only your developers can recover every individual problem file or it's something you are able to teach your support staff to work through.
If it's the first case, then it's hardly sustainable for your developers to fix every corrupt file that get's sent in.
If it's the second, then I don't understand why you can't extend the same knowledge to CAD managers and other experienced users so they are empowered to work through these issues on there own (then engage Bentley if needed).
It's clear that these issues aren't going to go away overnight, so we need a strategy for dealing with them that does not involve logging a service ticket with Bentley and waiting for a response. AFAIK ORD is well out of it's beta testing phase. Having to wait for a support ticket to be resolved in the middle of a project with tight deadlines is not acceptable.
Couldn't agree with your rant more. Bentley sales is pushing us to upgrade, upgrade, upgrade ie pay more, pay more, pay more, but when you take the bait, you are left in the silence. It's not the Bentley of even 10 years ago for sure.