I’m looking to elevate polylines by the nearest mtext value.
I’ve managed to get all the polylines and all the mtext into lists but the lists don’t match up.
I tried sorting the coordinates by x and then y but this didn’t work and also seems to be quite complicated (for me anyway).
Is there a way to sort the coordinates for the 2 lists in the same way so that the nearest text will set the polyline elevation? Or another way of going about this.
As an aside from the question, it’s odd that dynamo isn’t already selecting the objects in the same order given that there is the same qty of mtext and polylines.
Ah OK I see, thank you.
No, I’m trying to elevate some polylines which represent building outlines to a proposed level which has been given as text within the polyline. In my test case I have 34 of each object.
Do you want to get the nearest text based on a vertex of the polyline?
Or the perpendicular position of the text relative to the polyline?
In both cases, you’ll need to use the GetClosestPointTo method to find the closest point on the polyline then use that to determine the nearest MText.
Hi,
Thanks for your reply. The text is within the polyline so there is no specific vertex. Initially I used bounding box min but thinking about it now it’s possible that this won’t always match the correct elevation if the buildings are close together.
OK thanks I did give GetClosestPointTo a try but I wasn’t sure what I would do with that point once obtained?
Yes the text will always be within the polyline.
Just one polyline, I am doing some preparatory work with lineworkshrinkwrap to just get the outer polylines of the plots.
Get the geometry of the polylines into Dynamo as PolyCurves.
Patch the PolyCurves into surfaces.
Get the location of all the MText notes into Dynamo as a point.
Test each mText’s location for intersection with each surface using a Geometry.DoesIntersect. You want to either set the location point to be @L1 or use cross product lacing - you should have N^2 intersections in total where N is the number of polylines (N * N as there are as many mtext locations as there are polylines)
Use a List.FilterByBoolMask node to filter the MText which intersects each surface. The mask input should be @L2 here. In the ‘in’ list you should now have N MText objects - if not watch your list levels and lacing on this and previous steps.
Extract the note of the MText which will be string.
Convert the string to a number.
Set the elevation of each polyline to the respective number. This is (somehow) likely the hardest and easiest part. Personally I’d just take the original polycurves and translate them on the Z axis by the elevation, and then make new polylines from those at the right elevation to start with. Keeping the ‘2d flat’ version might have value in the long term anyway (planar elements are insanely useful for analysis and design).
Might - I’m assuming all work was done on the global XY plane, so the MText and existing polylines are already on the same plane. If the mtext is at crazy elevations or if the polylines are partially elevated I would zero everything out first.
Ah love the new nodes. Sadly we also lose the 2d flat version this way, so best to consider the long term uses of each.
Case in point: You can calculate the travel path between buildings (even maintaining travel along alignments) in an instant if everything is kept planar by way of VASA. If you go 3D you have a LOT more work in those calculations.
Hi,
Thanks for the script.
This worked perfectly on one site but when I tested on another it assigns the wrong elevations.
As I suspected earlier on in the thread, in some cases the bounding box is picking up mtext from an adjacent plot so the above script should only be used if all the plot outlines are orthogonal.
I have made a start with Jacob’s method using the surface and will report back.
Thanks A.C3D. I was just about to post almost exactly the same solution but using Jacob’s idea of making a surface. I didn’t know about that curve patch node, it would also work fine for this situation especially since there are no z values to consider in the inputs.
The script I was about to post is suitable for 2025 and doesn’t require any additional packages:
Nice! thanks for the update.
I think it would be more robust if we set all mtext elevation (geometry, not content) to 0 before intersecting to make sure the surface intersect with the polys @Z=0 too, just in case there is some mtext at elevation different than 0.
