what panel ?
Thank you so much! This is such short and powerful way!! Now i need to learn how ‘relative items’ component works. One more component added to the list.
Curious to know, what’s the advantage of using tree branch here because you’re feeding it the same paths you got from the curve parameter before?
I am unable to understand how this is working out.
In the first panel,
How are these values acting ?
{1}(0)
{1}(-1)
Why didn’t you choose the zeroth branch, but decided to choose 1st branch and wrote “{1}(0)”??
The purpose of this maneuver is to renumber the branches by path index. The branches which are currently:
{0;0;0}
{0;0;1}
{0;0;2}
…
become:
{0}
{1}
{2}
since I have set the context menu option of Tree Branch from “Maintain” to “Renumber”.
While it may seem that this is the same thing as Simplify, it is not. Were the branch addresses:
{0;0;2;1}
{0;1;2;0;0}
{0;1;2;3;0}
…
Simplify would modifiy this by trimming the unchanging digits of the branch addresses to:
{0;1}
{1;0;0}
{1;3;0}
…
or just trimming the leading unchanging digits if Front is set to “true” on the Simplify component proper.
Tree Branch set to “Renumber”, on the other hand, will always give me a whole number renumbering of the branches, regardless of what branch addresses originally were.
The above example with Front is set to “true” results in:
{0;2;1}
{1;2;0;0}
{1;2;3;0}
In the case of a necessary root, Simplifiy will preserve the left-most unchanging digit. So:
{1;0;3}
{1;0;3;0}
{1;0;3;1}
becomes
{1}
{1;0}
{1;1}
Single paths do not simplify as they have no other branches to compare themselves to:
{1;1;1} remains {1;1;1}
Suirify is basically like Simplify only it collapses single paths of pure zeros to {0}
{0;0;0} becomes {0}
The reason why I am renumbering the branches is because the offset mask of Relative Item is case sensitive. If I set up a mask {0;1}(0) for a data structure in the form {?;?}(?), but the preceding script is suddenly changed so that incoming the data structure becomes {?,?,?}(?), the component will fail. Yes, you can help yourself with {*;1}(0), but renumber is safer, and easier to reason with. You can always reconstitute the original branch addresses with Match Tree and some data tree modifications later.
Wow!! This is something totally new to me. Thanks for this explanation. I never faced this issue before. Maybe because I never worked with such complex data structures and all data trees were expanding uniformly with common branch numbers at the beginning itself.
This makes total sense in numerical/theoretical way. Do you have any practical geometrical examples where this sort of tree structure..
{0;0;2;1}
{0;1;2;0;0}
{0;1;2;3;0}
is actually present in a cluster/group of geometries?
No. It is unlikely. Generally, components will not create such wierd combinations of path addresses – certainly not jagged trees (that is trees with branch addresses of differing lengths) – unless you forcefully combine different streams into a single tree with a component like Entwine. The renumbering in the script above is an abundance of caution.
In the course of scripting, you will find that branch addresses will naturally explode in length because components add as many digits to a result as would be necessary to represent the most complicated constellation of inputs for those components. However, you may be dealing with simple lists and as a result you get topologically insignificant (meaningless) zeros.
What has established itself as a “best practice” is to ignore these zeros until the moment they threaten to be encapsulated. It is at this point you slap down a Trim component on the canvas to weed out the zeros. This seems to be safer than trying to apply Simplify on a result. Certainly, it promotes more conscientious scripting.
Recently, I have come to realize the power of Match Tree, especially when combining data streams. You can take the addresses of a distance predecessor and impose it on a current data structure given that the two trees have the same path count.
Here is a rare example of using jagged data trees.
Thanks! The example you shared has more unfamiliar components. I’m still trying to learn few at the moment which were mentioned here. I’ll take a deeper look later !
Little relieved to know that the jagged branching is usually unlikely.
Finally! 
…
@Baris Thank you for this:
I don’t know why I didn’t come up with it. Given the discussion around dual graphs and Heteroptera’s component which exposed the topology of them, it seemed to lay in the palm of my hand.
@archz2 Here is a good final solution:
TOLERANCE FIXING VR 3.gh (49.6 KB)
It combines:
- your use of line midpoints for text placement
- my use of Curve Proximity for distance values
- @René_Corella 's notion of an axial grid
- @martinsiegrist 's insight of a hexgrid’s dual
- and @Baris ’ access to topology through Brep Topology
Kudos! 
I guess this is what teamwork looks like.
I was wondering why we did not use relative iteM component for the left and right side branching of lines.
Here’s a short note for my future self and for anyone else just in case.
And dimensions also!
Explanation for Relative IteMS vs. Relative IteM.gh (20.7 KB)
@volker, your original short method did the job very easily without usage of any trimming or anything. Just sorting the data and joining the lines.
Your latest solution looks quite complex. I don’t understand why the extra steps are required. 
The problem with using Relative Item or Relative Items with a list of offset masks is that they produce flat lists for the results of all the masks, branched then by reference item. Ideally, Relative Item and Relative Items would insert an added layer of hierarchy in the resulting branch addresses for the masks, and give the data in branches by unique reference item and mask combination, but no. It doesn’t do this. Even if you graft the mask inputs. So, you have no way of knowing which of the results come from which mask.
I say that. This mess:
does eventually get there. The items in the lists do come in the order of the masks, but results of a mask do not always have the same length when Wrap is set to false, so you cannot simply Partition List with a constant partition size. What a work-around!
It’s better then to use individual Relative Item or Relative Items with single masks and combine the results in a controlled way. This seems inelegant when Relative Item and Relative Items are capable of taking multiple masks. But it is what it is. Or you can use the method shown with Brep Topology. It works quite nicely.
I should underscore, none of this matters if you don’t need the hierarchy of the masks. Like, if you just want all the distances… 
. But if you wanted to, oh I don’t know, say colour the lines by directional groups? Then you will need that information.
My last solution isn’t really that long. The other solutions shown do not include your portion of the script that creates the offset hexes, nor do they show line colouring and text display. It is the most flexible and complete solution so far. But you might not need all the bells and whistles.
@martinsiegrist 's solution is the most simple and succinct. If you never plan to distort the underlying axial grid, and never plan to rotate the offsetted hexagons this is the way to go:
Hex and distance line creation all in one go! For different hexagon sizes, you just plug in a list of sized into the Size of Polygon.
I noticed you wrote you are getting duplicate lines for Relative Item… This is not the case. Edit: I see what you did now. True, the lines are duplicated. I didn’t pay attention to the offset masks. You will still need Relative Item for the same branch adjacencies though. Mask {0}(1)… It seems you are getting the hang of things.
Why? Because Curve Proximity is unreliable, or some other reason?
Especially when you get to here:
This is pretty ninja, when all offsets are combined into a single Relative Item component.
Because Curve Proximity works with the parameter values of the curves. As long as the hexes are “parallel” to each other, there are multiple points along the hex where they equally minimally distant. Curve Proximity chooses to display this then at the first (or last, I’m not sure) parameter point it algorithmically finds on the reference (A) curve.
This is also why I used a combination of Curve Proximity for the distance values and the midpoint of the intersected lines between the centers of the hexes for display location; so that the values don’t get displayed bunched up at the corners. (The lines between the hexes then aren’t actually the minimal distance. They are just markers for which hexes are meant.)
@martinsiegrist An interesting exercise would be to see if you can determine whether Curve Proximity has found a unique smallest distance, or if there are more equally minimally distant points between the curves.
Yes. Yes. True. I’ll need those. Finally data sorting is making full sense to me . Many thanks to your script 
!