Please forget partition list. Your data tree is already correct, flattening and partitioning is not needed.
You are using List Item like it was Tree Branch
List Item gives you Items from list (if you have a tree it gives you the item (s) from each list)
Use Tree Branch and provide the paths you prefer (you can read and select them with Tree Statistics)
your very first file posted in this thread already has the data structure you wanted:
strip facade forum doubt_Re.gh (74.7 KB)
consider that data tree address can be read like: {branch}(item_index)
so for instance branch {0} will contain left line at index (0) and right line at index (1)
so if you want to access the -for instance- 3rd pair, you will have to use Tree Branch component and ask for path {2} → it will give you two items: left line at index 0, right line at index 1
or you could ask for all the left lines, in that case you can use List Item with i=0
or all the right lines by using List Item i=1
When I partitioned , why am i seeing a set of 2 lines, but they are not the sequential pairs, but a skipped ones,
In the partition lists, the first two lists should show me the first 2 sets of lines right? image attached below
I hope I am not offending any one, if so if any find got offended after all that what’s happened, i’m sorry for that
thank you @inno for your explanation above.
Here’s the latest GH script
strip facade.gh (70.5 KB)
Why do you flatten the tree and then create a partition list when you already have the output you want in the merge component?
strip facade no doubt.gh (23.9 KB)
In your case, the list item component shows item (0) and (1) of each list.
read again carefully please, also @inno gave you the same explanation but with pictures. That is all you need
here is the answer you looking for
@Vasanth_C its already solved here …
Let me give it a try. Somewhere there is a confusion in the logical steps you have in mind. For some reason you think the partionlist (you already have is not OK). But it fact it already is, like many explained.
To show you I played a bit with the gh. file. See for your selves if this is what you want (You already have). And if not, what has to be changed.
The circles are just an illustration:
strip facade forum doubtEW.gh (56.8 KB)
Thank you @Eef_Weenink , will understand more about and return
The problem is not that your list is not being correctly partitioned into branches of two items each, the problem is that you do not understand how the List Item component works.
I will take this slowly, first with an example using characters before moving on to an example with geometry.
Here, I have started with a “flat” list of 10 letters; the letters A through J which are indexed 0 through 9 in a single branch {0}. A data structure where all items live in a single branch is what we call a “flat” list:
I then use the Partition List component to split this list into a data tree with 3 branches where the number of items in first, second, and third branches are 2, 5, and 3 respectively.
If I now use List Item with an index of “0” and Wrap set to “False” (for clarity’s sake) on the partitioned list, List Item will take the first, or "0"th item from each branch of the partitioned list, and return this as a new data tree.
Instead of the "0"th item, I can attempt to retrieve the 3rd list items (the items with index “2”):
In this case, however, you will notice that the first branch of the partitioned list does not have a 3rd item, or an item with index two, and so the List Item component goes orange, throws a warning, and outputs a < null > value for the first branch.
You can also use a list of indices instead of a single integer…:
If you have managed to follow along so far, the result of this how and why you get the result that you do here, should be evident.
Moving on the the ZUI outputs of the List Item component; instead of a single output stream, you can get multiple results which are the index offset results of the original result.
Let us first recall the result of List Item with an index of 0, but the other ZUI outputs exposed:
This is familiar. But what happens if we choose the +2 output stream? The result for the +2 output stream will the the same as if we had started with and index of 0 and added 2 to it before evaluating, so 0 + 2, or “2”:
which you can compare to the third screen shot of this post.
What about negative offsets? Well, if we give List Item an index of “2” and pick the output stream -1, this should be the same as 2 - 1 = 1, or using the index “1”. In comparing the lists we find that:
yes, this is indeed the case. These offset streams work in the same way whether you are using a single integer index for List Item or a list (or tree!) of values. How the Wrap input of the List Item component influences all of this, I leave up to you to investigate.
Returning to your problem:
After the Partition List component, you have succesfully broken your flat list of lines into a data tree of branches containing two items for each branch. You can verify this from Panel attached to the output of the Partition List component.
You then run the partitioned list through a List Item component with a default index of “0” and the output streams “i” and “+1” exposed.
From the partitioned list, you get as a result from the “i” output all the the 0 index items (and only the 0 index items) from all branches of the original partitioned list as a new (reduced) data structure. You then chose to pipe and color these lines cyan.
Similarly, from the “+1” output, you get all the the 1 index items (and only the 1 index items) from all branches of the original partitioned list as a new (reduced) data structure. You then chose to pipe and color these lines blue.
So when you look at the result, you see in pairs all the 0 index items for all branches of the partitioned list in cyan on the left, and all the 1 index items for all branches of the partitioned list in blue on the right. This does not mean that your list has been incorrectly partitioned, it just means that you have chosen to color the items in this way!
If you want to select items alternatingly by BRANCH, then you will have to pay attention to what @Edr has shown you here:
I hope this helps. If not, I do not have any more time to spend on this.
@Eef_Weenink @Volker_Rakow @rajeev_pulari @Fabio_Franchetti @martinsiegrist was my above approach is correct?
No. It is meaningless. You are weaving, then dispatching (essentially undoing the weave) directly after. The two curve containers will be the same as the two line components.
yes correct i misunderstood.