I’m trying to offset building footprints derived from GIS shapefile data. The intent is to shrink them to approximate a subtraction of wall thickness, as well as correct for overlapping shapes to ensure downstream boolean operations work. I’m working with Rhino 5 for Mac.
Offset works when done in Rhino, but fails for some shapes when done in GH. Thanks to help on this forum, I have overcome that using Clipper’s PolyOffset.
However with curves that have curves inside them - i.e. building courtyards - PolyOffset, unlike normal Offset, does not autodetect this and requires you to choose the direction of the offset per curve.
Again, with help from this forum, esp @anon39580149, I have deconstructed the curves and automated by filtering for the smaller shapes.
This works well, except in cases where the courtyard is too close to the external wall, in which case an extra shape is created which intersects. To solve this I am using an If condition and Sift, but I’m having some trouble with list organization.
So my questions are:
Am I correct in using python instead of an If expression because expressions can’t deal with nulls?
What am I doing wrong with Sift that the Outer offset works but the Inner doesn’t? The “object instance” error seems to be because the Distance input is getting too many values, but flattening doesn’t work. Also I would expect the error to appear for both offsets…
Some shapes that have narrow parts get split into two shapes when offset. This is okay but how do I keep them grouped so that the data integrity is maintained for later (i.e. labeling with address from GIS data)?
In general, is there a smarter way to achieve the desired outcome?
Optional bonus question - why does Rhino offset work in Rhino but not in GH for some curves? You can test yourself by baking one of the shapes in the middle row.
Thanks in advance, I hope this isn’t too many questions at once.
Even my above “special case” is a non-ideal workaround, since the courtyard is being offset in the wrong direction (compared to normal courtyards, as seen in the lower left of the first image in my first post).
But I just want to learn more about what I am doing wrong operating with subsets of lists.
Later I will do something more elaborate, to keep offsets consistent (towards “inside” of building), and move it make sure it retains minimum wall thickness. Like this:
maybe try to find the polyline center; if the two centers are inside the smallest polyline that mean they are not close; but that don’t work in all cases, the same when you use CurveProximity.
especially if there are many small polylines inside with different positions and sizes.
there is other method i will try if it work
The idea is to separate the multiple polylines than use boolean and check if the number of polylines change that mean some of them intersect ; than we apply the new offset method
That way still reverses some of the courtyards. But I can fix that.
More importantly, how can this retain the list order? So if starts with 9 buildings (some with courtyards, some without, some that get split into two), it needs to end with 9 buildings, in the same order so they are associated properly with the data source.
See attached example with object names, via Human Attributes object.
Ugh. There’s lot of differences with Mac version, but I never expected fundamental data handling to be different. Very odd.
Well for now I’ll just cull those curves that are too close. That should make it easier. Hopefully I can figure out how to keep the data association correct. (The curves are from a shapefile list that also has addresses and extrusion depths that need to stay linked.)
I think I got the list order worked out. Except for one thing. When buildings get split into two shapes, the depth data associates correctly to both, however the names don’t. The new sub-item causes the name of the next bldg to be incorrectly assigned. I.e. 10 depths get properly assigned to 11 meshes (2 meshes get same depth), but 10 names do not get properly assigned.
In terms of GH list theory, why would OffsetMesh keep the list sub-group structure, but Bake doesn’t? If [Human] Attribute is causing the problem, is there a list technique (flatten/graft/etc) to fix it?
Further simplified def attached, with internalized data. Human required.
- why does Rhino offset work in Rhino but not in GH for some curves? You can test yourself by baking one of the shapes in the middle row.
