Alignments from polylines. Chained stationing

Hi, I’m working with several polys that I’m willing to convert into alignments. One poly will be the main (1st order) and the rest of polys will intersect the main or each other and (here’s the part where im a little lost) take the intersecting stationing as start stationing of itself

Here is some visual support:
Alineamientos de polilineas.dyn (221.3 KB)
red-main poly
white-rest of polys


This is what i have worked so far, but as you can see, there are some incorrect intersections as the stationing is not cotinuous


I feel like this should be some kind of a loop of by discarting the already used polys but I have no clue how to do this. :upside_down_face: help please

In traditional programming, this would use a Stack list where you add and remove each polyline as you process it, so that you can process subitems of the polyline without inadvertently reprocessing a previously stacked item. You would then store the processed items into another Stack.
I’m not sure how to use this concept in dynamo or if it’s a valid methodology.

1 Like

I have 0 knowledge about programing (I had a hard time to include a for loop in DesignScript :face_with_head_bandage:). Mehtodology sounds valid but I would not know how to implement it

For a ‘stack’ method like you mention can use imperative design script, or you can use Python, or a custom node. Things are usually doable with nodes too though.

Assuming the ‘goal’ is to always have station 0 (start point going forward) of each polycurve closest to the original alignment (red object in the sketch) you can actually do this in a really fun way with VASA. (ok fun might be a relative term here… I am a nerd and if you are too you might enjoy this).

  1. Ensure all polycurves (including the base) are on the XY plane (.
  2. Extrude them on the Z axis by 1 unit to get a list of surfaces
  3. Union the surfaces into a PolySurface.
  4. Build a Voxel model of the resulting polysurface. You can use a DisplayVoxels node to see what this looks like, and you’ll have to scale things to your needed level of detail. For starting out I recommend 1 for the size, for the vertical resolution, and 0 for the level of development. The dimension may want to jump up to 3 or 10 or 5 or other dimension as you up scale the scope.
  5. Build a path model from the voxel model, setting the expand extents for true so you don’t have to worry about vertical clearance.
  6. Take the midpoint of the base curve (the red one) and shift it vertically by 1.5 units (or 1.5x your voxel dimension) to ensure it is not inside a filled voxel.
  7. Build a distance field from the translated mid point.
  8. For every other curve pull the start and end points, translate them up by 1.5 units (or 1.5x your voxel dimension) and get the path from the source of the distance field to the sample point.
  9. Query the length of the resulting paths - if the length to the end is less than the length to the start, your polycurve needs to be reversed.

As a bonus while you are at it you can also use this method to define primary and secondary roads by number of trips (build the path from each lot based on number of units/trips to build a heat map which you can use to size each segment of alignments), route utilities (since they are under the roads anyway) and even identify ideal locations for stuff like public transit or fire hydrants.

Hello,
I am back again with this, but this time with a “Half solution”.

BranchingTest.dyn (173.9 KB)

I already achieved to create the alignments and set the correct start stationing with a different approach, but I need to ask for your help to wrap a Design Script while loop.
In the attached .dyn file I have a group of nodes that repeat each loop iteration. In the green group you will find my best try:rofl: to writte a loop with an Imperative block.
I added some comment sections to clarify my objective on each variable.


I think that if we can close this loop the Branching will work fine.
Any comments about best practices or tips are welcome.

Is it true that imperative blocks do not allow replication operators @@LX and < X > ?
Source: DeepSeek

Correct. The actual source is the design script language guide.

I finally achieve my goal by setting [Associative] blocks inside the [Imperative] ones, maybe this is not strictly correct nor the best practice but unfortunately this post had very little participants.

Using Associative blocks allowed me to use replication operators @@LXLXLXLX and < X > to handle list easily, as imperative needed to create a iteration index “i” for each variable in the list to be laced.

I write this just in case any Civil Engineer without any knowledge in DesignScript/Python (like me) starts to handle Dynamo from zero.

2 Likes