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

I have big area with roads and plots that are currently not equal to each other, approximately traced from handdrawing. Is there a way to shift the borders a bit to equalize them (without moving the roads) or make new plot division so plots won’t look weird and too stretched out in one or another direction?
Maybe there are some plugins out there that can help at least partially with this task&

If you post the geometry it will be a lot easier. I hope you don´t expect anybody will re-draw it. (21.1 KB)

1 Like

drg1.dwg (153.3 KB)
Sure, here it ts

The other approach will be iterative. You are dealign with non-linear problem here.

It will probably work if I divide the whole area in smaller parts, but the tricky thing is make plots radially attracted to the circles at the ends of roads, do you have any ideas how to do that?

maybe like this:

  1. place a seed point for every house in each plot.
  2. develop some kind of rule how to divide the space. voronoi would be a start but maybe Manhattan distance is better
  3. calculate area of each plot and the average plot area
  4. move each plot seed with galapagos and minimize for the difference of area between each plot and the average

have fun :slight_smile: !

If you accept bribes give some more land to some people. A little sometin’ sometin’ under the table. Then you won’t need equal land division :stuck_out_tongue_winking_eye: :pirate_flag: (13.8 KB)

… well it proves my plan wasn’t so good 6-10% difference on average

There is just one for that type of job: Kangaroo2 (i.e. a Physics Engine by a certain Daniel P). K2 attempts to optimize a variety of “targets” (named IGoals) that you provide as input. In your case such targets are: the target parcel area, the polyline that defines the parcel (derived from a BrepFace that is derived from splitting the boundary with your parcel curves), the OnCurve IGoals that dictate how much various poly points can deviate from curves (and the boundary), maybe a bunch of plastic Anchors (maybe not) and some other things as well.

I could provide an “indicative” demo on that puzzle of yours … but using 100% code meaning that a solution like that may be the wrong one for you if you are not familiar with coding.

Why? because going from “ïndicative” to final (of some sort) may require various code modifications.

With Kangaroo: (13.5 KB)

You’ll need to clean up your curves into all closed polylines first

If the plots have to change a large amount you might need to add some low strength anchors to keep it close to the original geometry (you can gradually decrease them to zero at the end so that the areas are also enforced accurately).


This changes the boundary though

It should be something like this

Keeping the boundary is simply a matter of adding another goal for this: (18.0 KB)

Solving a problem like this with Galapagos is a bit like throwing darts at a board, it might solve it to within 5% or so if you wait a few minutes (and as you scale the number of plots this will get much worse), instead of just following the gradient and getting a solution to within 0.0001% in a few milliseconds.

Evolutionary solvers are fantastic for some types of problem, where there are a smallish number of input variables and there isn’t any way of knowing the gradient, but this isn’t one of them.


What is missing here?

Oops, sorry - forgot to internalise everything: (22.9 KB)


EPIC! This is awesome!

hi daniel,

is there some information about when to use/not use galapagos?
is it something like this:
low number of input parameters and a “direct” correlation from input to goal

and my followup question would be:
why can kangaoo handle a problem like this so easily?

Actually maybe I came across as too negative about evolutionary solvers there - the great thing about something like Galapagos is that you can plug it into any problem where the target can be evaluated as a single number and the inputs are some numerical sliders. Sometimes even though theoretically a way of evaluating the gradient might exist, it might be hard to find and evolving it could be the best and sometimes only practical alternative to just brute force checking all combinations.

If we take the classic optimisation example of climbing a hill, a gradient based solver like Kangaroo can directly follow the steepest slope (provided we know enough about the thing we are optimising to evaluate this), in fact with the projective solver in Kangaroo2, it can even know how far to step along this gradient direction.
…whereas an evolutionary solver would randomly evaluate many coordinates in the terrain, and take combinations of which ones gave the highest result. As you get into problems with hundreds or thousands of dimensions (harder to picture as hills here, but these dimensions could be the x,y,z coordinates of a few hundred points), this performs really badly.


thanks! very informative