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&

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

**redwolf23**(Redwolf23) #1

**davidsmavrov**(David S. Mavrov) #2

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

EvenAreaSubdivisions.gh (21.1 KB)

**davidsmavrov**(David S. Mavrov) #4

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

**redwolf23**(Redwolf23) #5

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?

**Konrad.Kobayashi**(Konrad Kobayashi) #6

maybe like this:

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

have fun !

**ivelin.peychev**(IVELIN PEYCHEV) #7

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

**PeterFotiadis**(Pfotiad0) #9

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.

**DanielPiker**(Daniel Piker) #10

With Kangaroo:

plot_area.gh (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).

**DanielPiker**(Daniel Piker) #13

Keeping the boundary is simply a matter of adding another goal for this:

plot_area2.gh (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.

**DanielPiker**(Daniel Piker) #15

Oops, sorry - forgot to internalise everything:

plot_area3.gh (22.9 KB)

**Konrad.Kobayashi**(Konrad Kobayashi) #17

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

**Konrad.Kobayashi**(Konrad Kobayashi) #18

and my followup question would be:

why can kangaoo handle a problem like this so easily?

**DanielPiker**(Daniel Piker) #19

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.