Offset puzzle and help with Sift/Combine

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 @seghierkhaled, 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:

  1. Am I correct in using python instead of an If expression because expressions can’t deal with nulls?

  2. 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…

  3. 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)?

  4. In general, is there a smarter way to achieve the desired outcome?

  5. Optional bonus question :nerd_face: - 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.

Rhino Offset workaround:

offset (37.6 KB)

Needed plugins: Python, Clipper
ghpython2.gha (117 KB)
clipper-022.rhi (96.9 KB)
clipper-023-rhino6.rhi (97.1 KB)

If the problem with closest polylines you can use this

I want to keep the external wall though

which external wall?

But you choose this already ? if you want change offset direction of some polylines you must select them manually

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:

Even though that distorts the courtyard shape from a square to a rectangle, it’s the lesser of two evils (vs making walls not line up).

For now I’m just focusing on figuring out the issue with Sift.

the result is what you choose , i think you need a method to find when the polylines are very close than you apply other offset settings

Right, that’s what I’m doing, with CurveProximity. It works. Except for part of my Sift operation. Or do you mean I shouldn’t be doing that way?

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

offset (29.7 KB)

Update : offset (37.5 KB)

this work if there are many polylines inside

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.

offset (23.3 KB)
offset troubleshooting.3dm (2.7 MB)

Required plugin: Human

Try this the output result have the same list order of the input

offset (35.7 KB)

Thank you for your help. This doesn’t work for me -

I don’t have this problem
Maybe something wrong in mac version

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.)

Follow the definition , plug panels and find where exactly the data changed

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.

naming (47.9 KB)

First you need to simplify depth or simplify offset mesh output than use Path mapper; and always check simplify option



1 Like