Is there a way to divide land plots equally in grasshopper?

Def the computing time went orders of magnitude down. Evolutionary solvers are blind after all.

Here’s a nice example of the power of evolutionary solvers.
I can’t see any way these sorts of results could be achieved by simple gradient descent.

1 Like

Well … in fact a slightly different approach is required here: given a boundary List AND an indicative “start” partitioning per boundary (via either “spines” or lines or both) … get the polylines (split BrepFace with Curves then get the outer Loops) and then … blah, blah.

Plus there’s the building regulations (per country) that MAY dictate some additional goal(s) with regard the acceptable parcel shape/topology and the derivant building clearances per parcel etc etc. This makes the whole puzzle more challenging,

Good points. For making the polylines, one further issue is that some plot boundaries will need to be split not just at their corners, but also at points on their straight sides when there is a t-junction with multiple plots adjacent, otherwise triangular voids of no man’s land could appear in between. I think maybe the script Giulio posted here could be part of how to do this.
Also agree that further constraints might be necessary to constrain the plots to reasonable shapes, such as no very sharp angles. If the initial division is not fairly close to the final one, it could also become necessary to allow for some sorts of topological changes, which would make this all much more complicated.

Well … cases like these are like annual checkups > better avoid doing them because you’ll never know what may pop-up out of the blue, he he.

May save your life as well. :slight_smile:

Hi Daniel! I was testing your script because I need a solution for lots like this one. However, when I do a different block shape (not with the cul de sac in the middle) , the lots distort all over the place. I don’t understand why? I followed the script step by step I just don’t know why it is not working.

Difficult to say without seeing the file.
I’d guess it’s something to do with the outer boundary constraint.

sure, here is the test file I am using:Test.3dm (2.5 MB) plot_area3.gh (22.9 KB)

Ah, it looks like the curves are oriented clockwise. Flipping them fixes this:

I’ll add a check for this in the next version so curves are always given the right orientation.

Ahh!! it was driving me crazy hahaha thank you very much!

1 Like

Is there a way to use this algorithm by keeping the boundary edges in-tact with curved polylines? In my case, moving one edge, causes Kangaroo to self-intersect/ overlap.

Mesh self-intersect

Equalise parcels - self-intersect.gh (61.2 KB)

E: Does this require a loop plugin?

It looks like in your definition you’re anchoring the points around the outside of the curve instead of keeping them on the curve and free to slide, making it impossible for the area goal to be met without overlaps.
If you let them slide that might fix it already, but you might find you also want to add this to ensure the ordering stays consistent

If I remove the anchoring, I get something like this:

I have been messing with the strength values for a while, but no matter what I set them to, the curved areas will explode (the straight divisions will remain in place for the most part).
I’ll look at the other topic tomorrow, it’s getting late now. Thanks for the link!

I kept on trying stubbornly to get it to work and it still explodes just the same.
Equalise parcels - self-intersect.gh (127.3 KB)

It looks like you’ve not got all the outer points kept on the curve.

1 Like

Hi @DanielPiker OrderedOnCurve helps a lot,
but is there a way to insert points when is necessary? I imagine a kind of OnPolyline Goal that in order to keep the points attached to the Polyline(a fake segments evaluation), the Goal insert new points near to the Polyline Corners to create a new polygon with more resolution.
but then the problem would be the PolygonArea Goal that works with the old polygon…


Works fine if the polygons have the exact necessary vertices, but so hard to anticipate that

plot_area4.gh (21.2 KB)

Almost got it where I want it to be, apart from the wedging of the straight parcels.

The issue can get worse with different geometry, to the point where the wedging destroys the entire block.

I managed to minimise this tendency by playing with the parameters a little, including the input polyline segmentation, the angle threshold for the anchor points and the goal strengths. But, changing one of the parameters (e.g. the target value for the plot area or the start of the polyline seam for the initial subdivision) tends to mess with the end result, so I have to go back and forth quite a lot.

E: I am thinking about adding a length goal for the parcel lines to restrict their diagonal movement. It is clear to me that the plot lengths for exploded blocks are a significant percentage larger than their inputs.
Equalise parcels - advanced.gh (75.6 KB)

Okay, I tried to get a length clamp in by adding the start length and a factor to determine the upper and lower bounds, but no matter what I do, the solver doesn’t seem to accept this input. If only I could use the polyline length instead, I would assume it would work. Does anyone have any other ideas?

Equalise parcels - advanced.gh (88.0 KB)

This always has been a problem, at least for the past 10 years, mainly because, parcel partitioning is never really done based on equal area, there are a lot of other factors that matter more during the partition, like the regularity and orthogonality of the final plots, access points, terrain level and easement locations, and utilities. A proper parcel partitioning algorithm requires the use of a lot of heuristics and a way of selecting the factors that are important. Because of this considerations, Packing, Partitioning and Nesting all fail in achieving a good result. “Parcel Partitioning” is a very similar problem to “Plan Partitioning”, this is probably one of the central problems of Architecture because you can see it at pretty much every scale

1 Like