calculate corridor by iterations (loops)

[joantopo]

Currently, we cannot use corridor surfaces as a surface targets or corridor featureLines as an offset/elevation targets if they are from the same corridor, so we must use "setup" corridors.

But, why not a sequency of iterations to determine which subassembly must be calculated in each iteration?

Look at the following example:

My assembly contains subassemblies about daylight,sidewalk,curbe and gutter,travel lanels, all of them in the "Number iteration 1".

My custom subassembly= My_StrippingTopSoil, needs the corridor feature line (code Intersection), so this subasssembly will have "Iteration Number"=2.

So, "Iteration Number" must be an Integer input parameter (property) for all subassemblies. By default, Iteration number=1:

Important:

when we choose an assembly for a Region, Civil 3D will always check if some subassembly (belongs to the next iterations) doesn´t have repeated codes (code links or code points) versus all codes of the corridor.

I mean, if iteration 1 generates surface corridor "datum", then the second iteration cannot generate again a surface corridor with code "datum".

So, in that case Civil 3D will warn us about this with a messagebox.

In this case, the subassembly My_StrippingTopSoil, doesn´t repeat any code about the "all codes" from the iteration 1.

Moreover, in the Assembly properties, we will be able to choose the iteration number to show the subassemblies with that iteration in the panel:

If we choose the iteration number=2 in the combobox, then the panel shows all subassemblies of that assembly with iteration number=2.

So,using "iteration numbers" I think that is a clear and "easy" way to implement it.

Civil 3D will have to calculate the corridor as many times as there are iterations.

[joantopo]

well... maybe we could solve this if we were able to deal with the Subassembly Groups:

quote:

Each subassembly added to an assembly is automatically associated with a named group within the assembly.

Subassembly groups manage the order in which subassemblies are processed during corridor modeling

-We cannot add Subassembly Groups in my own, such as "user subassemblies group".

-We cannot move some subassembly to another subassembly Group.

If we were able to do this, then we didn´t have to use the "iteration number" as a property...

[joantopo]

Don´t read my last comment. I was wrong, so the "iteration number" concept is necessary.

[joantopo]

I have seen that we might need other items to accomplish this.

We need some commands to generate a corridor until a particular iteration number. (similar than debugging an application until a "break point").

In the example above, we would generate the corridor until the first iteration.

Once the features lines was generated, we would be able to extract them to assign as an offset target to the subassembly "MyStrippingTopsoil".

If we don´t do this and the corridor is calculated with iteration 1 and 2, then the subassembly "My_StrippingTopsoil" won´t be properly calculated because it misses the offset target, so, we should extract the corridor feature line to assign this as an offset target and calculate again the corridor.

 Maybe, it is faster the first option.

[joantopo]

This can be implemented in new C3D release at the moment because all old subassemblies, from old custom subassemblies or stock subassemblies will have by default the value "iteration number"=1.obviously, we cannot change this value for old subassemblies because it would be an internal value, but we don't need it.

The default input parameter= iteration number as the Side parameter, will be for future subassemblies from 2017, for example.

[joantopo]

 Iteration number must be a new obligatory input parameter in SAC, like Side.

In fact iteration number could be an enumeration parameter: combobox with "first","second", "third", "fourth".

I think that we don't need more than 4 iterations.

Moreover, instead of calling "iteration number" this parameter, you could name it as "phase".