You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would expect that Cell.area() should return the net area of a cell (i.e. areas where multiple layers overlap should not be double-counted). However, it seems to return the sum of layer areas. In the example case, I have a rectangle of area 10 fully overlapping with a trapezoid of area 30. The result of the area function is 40, when I would expect it to be 30.
I would argue this is a bug, as it's probably not what most people would expect. Do you agree @heitzmann ?
The text was updated successfully, but these errors were encountered:
This really depends on what the layers are used for. If each layer will be a separate process, the sum makes sense. If they are to be merged and run in single process step, then of course it is more important to get the area of the merged contents. It doesn't even need to be different layers. overlapping shapes in a single layer will also double count.
I agree that the merged contents area often makes more sense, but I worry about introducing a mandatory (possibly large) boolean operation step before the area computation (area is O(n) and boolean is O(n log n) in the average case).
Maybe we can introduce a flag Cell.area(merge=False) to add this as an option. What do you think?
Hi @heitzmann , sure' I would be happy if we add the option to merge layers before calculating and elaborate on the function behavior in the docstring. Thanks.
See gdsfactory/gdsfactory#1778
I would expect that
Cell.area()
should return the net area of a cell (i.e. areas where multiple layers overlap should not be double-counted). However, it seems to return the sum of layer areas. In the example case, I have a rectangle of area 10 fully overlapping with a trapezoid of area 30. The result of the area function is 40, when I would expect it to be 30.I would argue this is a bug, as it's probably not what most people would expect. Do you agree @heitzmann ?
The text was updated successfully, but these errors were encountered: