I’m trying to get the coordinates from various tagged elements, tagged with Spot Coordinates.
Here’s what I have so far:
The “All View-Dependent Family Instances Of Category” node is from Clockwork.
The python script is from this forum post: Spot elevations and elements
It’s supposed to get the location of the tagged elements, but I’m finding the results to not line up with the tagged elements:
I’ve tried looking up getting tag text in a few ways but none of them are working for the Spot Coordinates.
Anyone have any ideas on how to just get the tagged info?
Even just the N/E info would be great.
Thanks in advance!
THIS IS WHAT I DID FOR A LARGE STRUCTURE I WAS WORKING ON. IT WORK A FEW MONTHS AGO.
Extrapolate Data multiple spot elevations.dyn (72.4 KB) Extrapolate Data.dyn (34.9 KB)
Sorry for the late response. Didn’t realize that it was Friday when I posted this.
I tried a script similar to this.
The problem is when I use the Element.Location node, it doesn’t line up with what is actually tagged.
I just want to get the tag text or information somehow if that’s possible.
Not sure if that’s possible.
Might be a few dozen different things, can you post a small portion of the model returning these results, or a small model with a similar setup to what you have so someone can look into what’s happened with your model so far? The objects tagged and the tagged view are really all which is needed.
Hi @jacob.small !
It does seem like the model we have is inconsistently tagged, which doesn’t help.
There are so many points in this model though that re-tagging the elements might take a while, unless that’s scripted.
Here’s an example model of what I’m running into, which is giving me the same results.
Example-Problem-Area.rvt (1.4 MB)
I see three issues here, but am not quite sure what you’re after, so I’ll lay them out with the caveat that I may not be understanding what you’re after…
If you’re looking for the point which the spot elevation was associated to, then you’re asking the wrong items for the data you are after. The python script in that thread retrieves the element which the spot coordinate is associated to, not the location of the spot coordinate’s host. By pulling the element and then asking for it’s location, you’re pulling the 0,0,0 or initial placement point of your adaptive component (not really sure which but neither is useful here), and the reference points are returning a null value as they don’t have a location (crazy I know). If you use an
Element.Location node immediately after the
All View Dependent Family Instances Of Category node (or right after the
Flatten node), and you should get XY values that make sense. Z values though…
The Z values are all over the place. Create a default 3d view and look at the model which you posted. A lot of these items are all over the place elevation wise. You’ve clearly got some stuff outside of the level which has been tagged. This may have been intentional, but I suggest narrowing the view range before you tag stuff as that would have helped ensure some consistency here. Better yet, isolating the 3d datum families before you tag them. Even better still would be to tag the points programatically (as you noted above), using something like the
SpotCoorinate.ByPoint node from the clockwork package. A problem for another day though.
Your selection method is grabbing some additional spot coordinates, and I’m not sure why. It may be how you stripped content from the model, it could be something else entirely - no clue really. I’d leverage the
Select.ByCategoryAndView node in the Archi-lab package instead. This will grab the spot coordinates in the given view(s), omitting the dependent views which I believe is what the Clockwork node was doing, causing there to be 14 items selected instead of 9 (the total sum of instances in the active view).
This graph should help narrow things down:
Yes, there are a definitely many issues here (as there always are), but I see them as challenges! >:D
I’ve gotten a bit farther now after posting this so I can cover these points, then do an update here.
- I’m really just looking for the N/E point that the tag is calling out. It doesn’t need to be coming from the exact element that the spot elevations are calling out. That, as you found as well, will give you the initial placement point/ center of whichever component was called out or null because they tagged a reference point. Because the tagging was inconsistent to begin with. After going down a complicated rabbit hole, the inconsistent tags wound up not being the way to go.
- I’m not as concerned about the Z values. We are just looking at the N/E points because we are eventually going to take these points, offset them and make a floor plate. We know the heights of the floor plates, so we know don’t need the Z value.
- That sounds like it’s coming from the stripped down section of the model. Sorry I can’t post the full model here. Not sure if I gave enough info for this forum post overall. It’s really more of a complex issue, so it’s hard to put it all in a post and I tried to simplify. That model was more to show what was going on with the tagging.
Eventually I found that I could take the 3D Datum points (the circles at the faceted corners) are where I can get the N/E info. Even though they were stacked on top of each other and different Z values, I was able to just get the N/E values, which wound up being the same number that was tagged.
The next trick in this epic script will be to clean up the edge geometry I’m getting, which could be a whole new forum post in itself. I’ll post if I run into any major snags with that.
Thank you for your in-depth response though! It’s helping my sanity getting other opinions on this haha!