Zoning list area doubles when area has internal zones

Hi there,
Bit of a puzzle.

Simple example on a 10m x 10m space.
Split the area in half using zoning and as expected in the zoning list it shows 50sqm of each area.
Image 1

If I add a third area inside one of these halves, for some reason it doubles the area size in the zoning list for the outer area???
The grey areas at the top of the second image show the area measurements using Rhino (not lands)
Image 2

As you can see, the total area when adding up the totals in the zoning list comes to more than the total size of the area.

Hi @albert is this something that you are able to recreate, or am I doing something wrong here?
I am using Rhino v6, but the issue also occurs in v5.

Hi! I’ll take a look. If there are no duplicate objects, it may be a bug.
It would be great if you share the 3dm

Hi Albert,
Two Rhino files attached along with screenshots.
The first shows a 100sqm area split in half. The zoning correctly reads 50sqm for each half.

The second file, I deleted the zones and then added the circular area and re-zoned the spaces.
It seems that the complete rectangle on the left is correct, as is the complete circle, but the right hand rectangle with the circle within it is reading double the actual area (shown as surfaces above to show actual area).

Broken Zoning.3dm (365.9 KB)
Working Zoning.3dm (295.7 KB)

Thank you. Yes, it’s a bug, I’ve reproduced it.
We’ll fix it for the next version.

Hi @albert,
Still having the same issue.Beta VIII

The attached screenshot shows two square areas the same size, however the area on the left totals much more than the simple, undivided space on the right.
Area 1 is measuring twice the size when intersected by the circle shape.

yes, it’s not being easy to solve. The problem is due to the way Rhino makes boolean operations on regions:
(Square - Circle) should return the square with a hole. It does.
(Circle - Square) should return Null, but it returns the square with a hole.
This is, Rhino reverses the order of the operands to ensure a valid result.

We need to find a way to prevent Rhino from acting this way, or we will need to change our algorithm.

Hi @albert it always seems to be double whenever it gets the figures wrong, as if it is calculating both sides of the shape.
Hopefully this is something that can be fixed.

Is it likely that you will introduce the same zoning function on surfaces in the future to enable listing and measuring in the same way?

Hi @albert
Is this issue still on your radar?
Currently, not being able to accurately calculate zoning areas prevents us from using Lands for our main project work as generating accurate area sizes is paramount for the type of work we do.
I notice it is not yet fixed on the latest release, would be great if we can get it working.


yes, we changed completely the way Zones are calculated, avoiding the problem described above.
Next Lands version should show accurate area values. Unfortunately it can take a while until it is released.

That’s great news. Thanks for taking the time to look at this.
On a similar topic, is it possible to produce a table showing area sizes for divided terrain in the same way as it is possible with the Zonify command?

You are lucky today, we have also implemented this, since other users asked for it.
In addition to be listed, it will be possible (optional) to show a hatch as the 2d representation of the terrain division and the label with the area value, just like a Zone.

Awesome news! Really liking the way Lands is progressing.
Do you have a timetable for commercial release yet or is it still early days?

Do you know when the next service release might become available?

Thanks! I’m glad that you like Lands!
Next version should be available in late September early October. It could be a release candidate, so we are closer to the commercial version. But no date is decided yet.

1 Like

FYI, a new version is published that solves this problem.