X Y Locations of Blocks References Inside a Block Reference

Yesterday, @jacob.small helped me out on a separate graph that also enlightened me that I can access data inside of block references and utilize that geometry, that had me thinking about using this on another workflow to help me identify piles on a solar site. Trying this, it seems to work… kind of. I have created some test blocks for a solar array with a pile blocks spaced inside of the array block. I have pulled the coordinates of the piles inside the block, for each array block that occurs in model space, BUT it appears all of the coordinates coming out of the Object.Location node are the same, which isn’t true when it comes from model space. The coordinates also aren’t coming back with relative coordinates to their position within the array block editor, the coordinates are real coordinates, but only from one block iteration and it appears to just repeat. Screenshot below and .dyn and .dwg files attached if anyone is able to help me this!



Pile Locations.dyn (18.5 KB)
Pile Location Test.dwg (1.7 MB)

All geometry in the block will report relative to the origin found in the block editor. To get it into the project context you need to then transform it by the block reference’s coordinate system to get it into the ‘project coordinates’ if you will.

However it appears that you’ve got some nesting going on, including an array. This complicates things as you have to get the objects in the block, then get the block references from there, then get the geometry form in the nested block reference, then transform the nested block geometry by the nested block reference’s coordinate system, then transform the transformed nested block geometry by the host block instance reference’s coordinate system… it’s a lot of steps.

For what it’s worth, instead of reverse engineering all of this from the result of the layout design (i.e. the layout is already done), you’d be better off producing the content programmatically by leveraging Dynamo (and even generative design) for the effort of layout design.

1 Like

Dang you are right! I swear I looked at this yesterday and the Object.Location was giving me real world coordinates, which, at the time, did surprise me (haha). But after your message I can confirm that these coordinates are relative, but I think I should be able to use that, and the insertion point coordinates of the block references to generate real locations - one way or another.

To your last point, I really wish I could down that path, but right now our group is provided the layout by another team and they are sold on using third-party software to generate their layouts. That would be an uphill battle for our group, haha.

1 Like

@jacob.small

I have been working on this script today and I think I have gotten to a key point with the data. I now have relative pile coordinates per AutoCAD block type/name and then I have the insertion point of each AutoCAD block with the associated name. Do you have any advice on how to get these data compiled to where it will read the insertion point of each block instance and then output the real world coordinates of the piles based on the relative pile locations? Dictionaries are still very confusing to me right now. I feel like I am just messing around until I get something to work, haha. Screenshot below of the data I have right now, if it helps:

One option, instead of a dictionary use a list. Format it something like name, block, x, y, z, group, etc… Exact order doesn’t matter too much, so long as you are consistent. When done (or before) insert the names of the data at index 0. Then write out to CSV or Excel.

Option 2: build a list of dictionaries, where each object has a key for name, block, x, y, z, group, etc… Order isn’t relevant here either, but consistency is. Then use the node Data.StringifyJSON and write the resulting string to a .txt file.

JSON is more portably, and can carry things like geometry easily. CSV is next most portable, and most people can figure out how to use it. Excel is most prolific, but least portable and most likely to fail in Dynamo as Micrisoft breaks their API access on update once every 3 months.