Single Instance End Condition Problem and Design Stages

The term “single instance end condition” probably isn’t an
official term.   So I will describe it
before asking for addition help.  A
single instance end condition problem occurs when you have a template that has
multiple end condition solutions and when applied to a corridor you have a
single instance of an end condition within a series of sections.  For example, a template could have 2 end
conditions solutions; one to draw a simple fill in-slope and another to draw a
ditch section.  The template may solve –
draw for a series of corridor cross sections. 
The first and second sections may solve as a fill slope. The third
section solve as a ditch section.  The
fourth and fifth section may solve as a fill slope.  The third section (ditch section) can be
considered a single instance end condition within a series of sections.  This section may have a valid solution but it
may not model well and or draw correctly in the cross sections.

                                                                                 

I have worked around the single instance end condition
problem a few different ways.


  1. Adding a key station to create at least 2
    consecutive solutions can solve the problem. 
    In the example above the key station would be added adjacent to the
    third section.  If the key station is
    close enough to the single instance end condition the new section is usually
    the same.  After the key station is added
    you would no longer have a single instance and the problem would be solved.

  2. Changing the temple drop interval may also
    adjust the series to avoid a single instance. 
    However it may also create new single instance end conditions problems.

  3. You can eliminate the single instance end condition
    with an end condition exception.  The end
    condition exception could force an end condition that matches one of the
    adjacent sections.

  4. You can eliminate the single instance end
    condition by changing a parametric variable and therefore changing the series
    of solutions.

  5. Component name overrides can help minimize this
    problem, but some end conditions may have different numbers of points –
    different types of components.

 

I am looking for
better solutions than mentioned above.
 
This is a cumbersome problem to begin with. Now let’s talk about
changing project settings or design stages. 
The end condition problem may re-occur at multiple design stages.  This compounds the problem and the
frustration.  New single instance end
conditions may be introduced with tighter intervals or curve densification.  It appears the harder I work to avoid single
instance end conditions the more complicated I make the model.    Does anyone have better solutions?

 

 

Parents
  • Hello Jon,

    Can you please tell me what version of the GEOPAK product you are running?  Are you working with the Roadway Designer (SS2) or maybe Corridor Modeling (SS3)?  Please provide me with the exact version number.  It can be found under Help > About Bentley GEOPAK

        

  • I work with both Geopak 8.11.09.493 and 8.11.07.615.  I think the question - problem is applicable in both versions.  Presently all of our production work is in SS2.  However I am presently reworking a  project in SS3 with the open roads tools.

  • Hi Jon,

    First, in SS3 there is no need to use any of your workarounds.  The process that the program uses to create the component meshes and top/bottom meshes was completely rewritten and it has no problems if there is only one drop of a component in a line of other components.  Therefore, you should not have to do any extra work no matter what your design stage settings are.

    In SS2, the 5 workarounds you mention are exactly the tools available to work around the issue.  The easiest (in my opinion) is to set the template drop interval to a small value.  This works well until your corridor is big enough that this causes a performance hit, but the vast majority of the corridors you work with on a typical job should be OK.

    Thanks,

    Kevin

Reply
  • Hi Jon,

    First, in SS3 there is no need to use any of your workarounds.  The process that the program uses to create the component meshes and top/bottom meshes was completely rewritten and it has no problems if there is only one drop of a component in a line of other components.  Therefore, you should not have to do any extra work no matter what your design stage settings are.

    In SS2, the 5 workarounds you mention are exactly the tools available to work around the issue.  The easiest (in my opinion) is to set the template drop interval to a small value.  This works well until your corridor is big enough that this causes a performance hit, but the vast majority of the corridors you work with on a typical job should be OK.

    Thanks,

    Kevin

Children