Why OpenRoads? Six Words

1. OpenRoads Remembers
2. Common Data Environment
3. Extensible

I get that question a lot:  "Why OpenRoads? It's different and more complex than my old familiar software. Why OpenRoads?"

Industry DEMANDED it

1. "I change one thing and I have to manually change everything that is dependent on that.  This burns time and budget.  The software should make those updates automatically!"
2. "What do you mean that the software has a bunch of cryptic binary files?  None of which are compatible?  What?  You can't trust the graphics?  Are you kidding me?  Five different formats just in your platform?  Converting data burns time and budget.  Being unable to easily share collateral work is a liability risk.  Better software should streamline collaboration!." 
3. "I really hate having to go to addtional software packages to keep track of element data.  Document chasedowns burn time and budget.  I should be able to attach information about an object to that object and have the software platform fully leverage that information in its tools.  This is the era of Big Data and Big Data Management.  Your software should be built for that."

These revolutionary, ready-for-the future demands required a grounds-up rebuild of the software platform: OpenRoads Designer.  Built on Bentley's Common Data Environment: MicroStation.

OpenRoads Remembers

Bentley markets it as "Design Intent" and Rules-based Design.  We've always had design intent and rules-based design.  The problem was that MicroStation and InRoads didn't remember the rules you used.   OpenRoads Remembers.  

We never just place elements all willy-nilly.  Engineering is about providing optimum solutions given a collection of constraints.  Constraints are relationships.  While we laid out designs according to those relationships (Edge of Pavement twelve feet to the right of the Centerline and 2% down), the relationships were never stored in the elements.  OpenRoads tools - picked by the relationship you want to honor - stores the relationships in the features.  It remembers.  Tweak the Parent, all the Descendants update.  OpenRoads Remembers and manages the updates - based on the constraints you defined.  Not some "most likely guess".

Common Data Environment

A Common Data Environment (CDE) allows sharing data without translating data.  It streamlines the workflow and expands the scope of interoperability.  It allows you to collaborate more easily and more broadly.

The Bentley CDE is not some standardized but opaque data file - it's the graphics: the DGN.  If it's DGN (or DWG): you can reference it, you can SEE it.  And it's all in there.  No external separate binary file.  

Multidisciplinary live-collaboration MegaProjects are almost as easy as small single discipline projects (well, you really want to be hosting it in ProjectWise).

Extensible

OpenRoads was built for the future: BIM and Digital Twins ready.

In brief, BIM-ready means extended data is stored with the geospatial element (the Feature).  The graphic contains (all!) the data.

Forget about "we need to build Digital Twins".  Instead, think "let's store the valuable element data WITH THE ELEMENT". 

Item Types is the technology that easily let's you extend the off-the-shelf data model.  Storing the data you care about with the element dramatically streamlines all your processes, especially the iterative design and review processes.  Item Types are fullly integrated into the palette of platform viewing, filtering, reporting, and Quality tools.  You can realize immediate in-project Return on Investment - this is how you organically and profitably expand your client solutions and expertise into the new inevitable Digital Twins industry reality.\

Item Types - Adding YOUR Data