Tin triangulating incorrectly - corridor modeler

I am working on our final model for the dtm, finished grade tin, and top of dirt tin in Geopak SS2 Roadway Designer.  I recently had to create additional templates to aid in the top of dirt surface creation.  In doing so, somehow now my top of surface tin is not triangulating correctly for the sidewalks in a few templates.  I can’t seem to figure out what is causing this problem.  This corridor now has over 20 templates and this is occurring in 7 of them.  My recent changes to the corridor were primarily new templates to remove parametric constraints that made components go to zero (since the top of dirt alternate surface triangulated to those zero width components) and also merging points that were sitting on top of each other. 

 

Anyone have any ideas what could be wrong? 


 

Running GEOPAK V8i (Selectseries 2) 08.11.07.615, Microstation V8i

Parents
  • I can not tell from the picture what you are describing, this will certainly take some time to troubleshoot, you will need to provide the rest of the data and also give a starting place where to start looking through and deciphering your corridor and how you constructed it.

    If you look at the corridor in 3D and the 3D graphics I assume it is correct? and if you manully extract the graphics into a surface the surface is correct? SO the issue is the Roadway Designer is building a surface that does not triangulate the same as manually creating a TIN from graphics.


    For more information about the Road and Site design tools, visit the Road and Site design WIKI at: http://communities.bentley.com/products/road___site_design/w/road_and_site_design__wiki

  • The problem is that the front face of sidewalk is triangulating to the bottom back of curb instead of the top back of curb in places.  This is occurring inconsistently in 7 templates, which is why you see up and down or waviness in the green smooth modeling representation of the tin file from the original post.  Hopefully the snip below clarifies the issue.  The 3D components produced by corridor modeler do look correct.  I have not tried to manually extract the surface from graphics.  The best place to start looking is from station 2+28 to 4+25 on the SnowyRange corridor, template "SnowyRangeBarnRoofConc_NoRtSep".  The sidewalk is triangulating correctly on the left hand side, but not on the right hand side.  The template was recently edited to remove the sidewalk separation between the back of curb and front of sidewalk and merge the top back of curb point with the top front of sidewalk point.  This was done so that a parametric constraint was not needed to force the sidewalk separation to zero feet wide, This was because the alternate surface needing to be created (for top of dirt) was incorrectly triangulating to that zero foot wide component.  Snip below, other data will be uploaded through the secure file upload.

  • Other data uploaded to this forum thread using the secure file upload: communities.bentley.com/.../370040
    Folder name UPPR.zip
  • Emily, as Beebe Ray mentioned, this is a tricky one to diagnose without really looking at how the modeling is set up with all of its controls; it's not directly evident in the ITL alone. I attempted to download the files you posted but was unsuccessful. But I will say that whenever I've seen this in the past it's because of duplicate breaklines (horizontally) each with different elevations. In cases like this, the triangulation (at least from an InRoads perspective) will remove 'certain' overlapping (horizontally duplicate) breaklines. The result is an up and down jump between the breaklines that are retained resulting in triangulation that looks like you show. In InRoads I would look at the DTM and review the Features, Crossing Breaklines, and Triangulation report. This review would at least identify the problem in the resulting surface. And then it could be traced back to the Roadway Designer and Templates to find the source of the problem.
     
    Civilly yours,
    The Zen Dude (also known as "Mark")
    Civil Software Guru & Philosopher
    InRoads User since its birth in the 80's
    OpenRoads Documentation / Training / Support
    Zen Engineering, Owner
  • I've had the same problem in the past, though it no longer occurs with my current workflow. One piece of guidance I might have, though, is that from more recent work in the ITL file, I've noticed an attribute applied to points within the XML of the ITL file:

    For example:

    <Point name="inside31" featureName="" style="Znull" includeInSubgrade="false" subgradeName="" x="-0.766044443" y="0.357212390" isPartOfBackbone="true" superType="0" superTransitionType="0" superNonLinearLength="0.000000000" transitionX="0.000000000" transitionY="0.000000000" XByExternalControl="false" YByExternalControl="false" ControlledByParametric="0" isTopPoint="false">

    I believe the key part here is:

    <Point name="inside31" isTopPoint="false">

    I haven't experimented with this before, but from what I can tell, this isTopPoint toggle appears nowhere in our template editor tools. And this toggle may be the issue at hand. You might want to open your ITL, locate some points that you know shouldn't be top points, especially ones that are picked up properly, and then locate some points that you know are causing trouble. See if you notice a pattern.

    I don't know a particularly good XML editor, which would probably be of great help, but I use Notepad++ effectively. Just don't expect to get good use out of the Notepad that comes with Windows. 

Reply
  • I've had the same problem in the past, though it no longer occurs with my current workflow. One piece of guidance I might have, though, is that from more recent work in the ITL file, I've noticed an attribute applied to points within the XML of the ITL file:

    For example:

    <Point name="inside31" featureName="" style="Znull" includeInSubgrade="false" subgradeName="" x="-0.766044443" y="0.357212390" isPartOfBackbone="true" superType="0" superTransitionType="0" superNonLinearLength="0.000000000" transitionX="0.000000000" transitionY="0.000000000" XByExternalControl="false" YByExternalControl="false" ControlledByParametric="0" isTopPoint="false">

    I believe the key part here is:

    <Point name="inside31" isTopPoint="false">

    I haven't experimented with this before, but from what I can tell, this isTopPoint toggle appears nowhere in our template editor tools. And this toggle may be the issue at hand. You might want to open your ITL, locate some points that you know shouldn't be top points, especially ones that are picked up properly, and then locate some points that you know are causing trouble. See if you notice a pattern.

    I don't know a particularly good XML editor, which would probably be of great help, but I use Notepad++ effectively. Just don't expect to get good use out of the Notepad that comes with Windows. 

Children
  • Unfortunately added complexity enters the picture when the template contains points that are positioned and repositioned using either Parametric Constraints and / or Point Controls. In some cases the points are moving around and can result in conflicts that aren't easily resolved by the template include / exclude flag. I've seen this happen when multiple points are stacked onto one another and then 'zero'ed' out using Parametric Constraints. Horizontally the breakline 'disappears' but there is a continuity to that breakline throughout the model that can conflict with other breaklines. Clipping Corridors can also create this type of problem. That's why the Triangulation and Components need to be reviewed outside of the Roadway Designer. I've found breaklines that should have been excluded, that were actually included after the surface was created. It requires good detective skills to run these things down.
     
    Civilly yours,
    The Zen Dude (also known as "Mark")
    Civil Software Guru & Philosopher
    InRoads User since its birth in the 80's
    OpenRoads Documentation / Training / Support
    Zen Engineering, Owner