ORD 2020 Rel.3: Terrain: Analyze Elevation - how to add point names

When using the Analyze Elevation I'm able to create a report which lists the elevation differences between a terrain and single points. This works well but I miss an option to add point names in both my dgn file and in the report ...there is a point name column in the report. Workflow: OpenRoads Modeling -> Terrain -> Analysis -> Analyze Elevation

I can't find any documentation on this function and I can't figure out if it's possible to add names to the points.
The function apperently only accepts point and cells so the point name possible should add'ed as an Item or...?

Any ideas are welcome :-)

Regards Anders

PS: Basically it suits me well that I don't have to create a new terrain and import the points into and then create a delta terrain or something like that.

  • I recently ran into this issue and this is what I found.  It may or may not apply to your situation depending on how you are bringing your points into the file.  For this particular process, I use Geometry>Import/Export>Import Horizontal Points from ASCII file.  Bringing in the points through a survey workflow may yield different results.

    When importing geometry points with elevations, ORD writes two graphic elements to the file.  The first is the plan point.  It is written to the active model whether 2D or 3D.  When importing into a 3D model, it is placed at the point's true elevation.  The second is written to the associated 3D model.  If the active model is 3D, it is written to that model and you have two points written to the same model and are coincident.  The two types of points are interpreted differently by some ORD commands.  This report will only grab the name attached to the plan point.  For whatever reason, it ignores point names attached to the 3D points.

    My solution was to import into a 3D model and call out different element templates for the two point types that placed one as primary class and the other as construction class.  Obviously, you could use other characteristics to differentiate - level, color, cell, etc. - but you ultimately need some way to select only the plan points.

    Answer Verified By: Anders W 

  • Hi Ray

    Thank you very much for your prompt and thorough reply. I didn't thought of that the points should be imported as civil geometry points. It was also important that you describe the problem about the point names and that they are only read from the plan points. It isn't logical and it must have taken you some time to figure this out! It is also strange that the point name is not "synchronized" between 2d and 3d so it doesn't matter which is selected.

    Thanks to your help, I have now managed to create a report with point names. However, I wonder why the point names are only written in the "heading" of the individual points. The "Name" column is left blank as seen in the screenshot below ...when I use Bentley's standard Style Sheet (notice the red arrows). I may be able to edit the XSL file to fill in the Name column as well.

    By the way: I can only include the point names in the report if they are imported into a 3d model and select the plane points. If I import the points into a 2d model and select the plane points it doesn't read the elevation from the 3d reference :-(

    The best thing would be that there was an option to import the points as ordinary MicroStation points (cells etc.) and that the point name e.g. could be read from an Item on the points - not all of our survey data needs to be imported into a terrain model or alignment so it's an extra step we need to do to create this report.

    Best regards


  • I kind of stumbled on the Plan/3D point thing so fortunately it didn't take too long to uncover.

    The reason the name doesn't show up is that the feature name and feature data are in two different elements - TerrainCheckElement and TerrainDataElement, respectively - in the raw xml file of the report:

    <InRoads productName="OpenRoads Designer CONNECT Edition - 2020 Release 2" productVersion="" linearUnits="Imperial" angularUnits="Degrees" isInternationalFoot="true" commandName="Terrain Elevation Checker Report">
      <TerrainCheckElement ElementName="7002" ElementType="PointEntity2dInPlan">
        <TerrainDataElement xCoordinate="245159.721300000" yCoordinate="228536.858700000" Length="" CheckElevation="3404.874500000" TerrainElevation="External" ElevationDifference="" />

    Since TerrainDataElement is a child of TerrainCheckElement you have to call "../@ElementName" rather than "@ElementName" to fill that field of the table:

                  <xsl:for-each select="TerrainDataElement">
                        <td class="sidepad" align="center" nowrap="nowrap" style="color:black;">
                          <xsl:value-of select="../@ElementName"/>

    I've attached a stylesheet that I think will work for you.  I can't guarantee it because we're still on 2020R2 and some of this information is only included in R3.


    As far as picking the plan points versus the 3D points, that's why I changed the feature symbologies and element templates to display the 3D point as construction elements.  It's easy to turn them off so it's easier to pick only the plan points.

    I've found issues like this in several of the reports and I have a few theories as to why.  My mom told me if I can't say something nice, don't say any thing at all so I'll keep those theories to myself.

  • Hi Ray

    you have to call "../@ElementName" rather than "@ElementName"

    Thanks a lot ...this also works well in 2020R3 :-)

    I changed the feature symbologies and element templates to display the 3D point as construction elements.  It's easy to turn them off so it's easier to pick only the plan points.

    I have to "dig" into the feature symbologies and element templates. If I just "manually" change the 3d point to construction class and turn this off in View Attributes it also turn off the plan points although they still are primary class!

    My mom told me

    Your mom is a wise woman ...and Bentley still doesn't risk to becoming "unemployed" because the possibilities for optimizing ORD is exhausted!!!!

    Have a nice day :-)

    Best Regards


  • The feature symbology should call different element templates for the plan and 3D elements:

    The element templates determine what class is used to display the elements:

    Answer Verified By: Anders W 

Reply Children