Trimming a DEM-aligned street Brep using city block volumes

Hi all,
I’m new to Rhino and Grasshopper and currently working on generating a street surface model that follows elevation based on DEM data.

Here is a screenshot of the base geometry I’m working with:

Input Data

I’m using three files:

  1. DEM (dem.tif) – used to extract elevation (Z values)
  2. Polygon of the entire survey area (boundary_road.shp) – this is the base surface to be trimmed
  3. Polygons of city blocks (blocks.shp) – these will be extruded and used to trim the surface

Data set is available here:

(Optional: a street polygon shapefile - 20210101-road_edge_polygon.shp - is also included in the dataset, although not used in the current trimming approach.)

Workflow Summary

  • Load the entire survey area polygon (from SHP)
  • Convert it to a polyline, adjust each point’s Z value to follow the DEM, and generate a surface (Brep) using FPatch + Cap
  • Load the city block polygons, extrude them vertically (with enough height to fully intersect the base Brep), and Join + Cap them into solid Breps
  • Perform a Boolean Difference (Trim) operation:
    Trim (A: street surface Brep, B: city block volumes)

The Problem

While some parts are trimmed correctly, many blocks (over half) do not result in any trimmed geometry.
For example, the green block shown below fully intersects the red base Brep, but it does not trim it at all:


I’ve tried the following:

  • Ensuring all Breps are Closed
  • Applying Join + Cap before trimming
  • Using Flatten on inputs
  • Confirmed the block visually intersects the base Brep

But the problem still persists in many parts.

Additional Notes

It is appreciated if the holes (city blocks) also can be retrieved during the process as land lot surface.

I initially considered using street polygons directly (instead of trimming), but needed to explode them into points to assign DEM elevation (Z). Rebuilding surfaces from these often led to fragmented geometry, so I opted for this trimming-based approach.

If anyone has insight into why this Boolean Difference is partially failing, or has suggestions for a more robust workflow, I’d really appreciate your help!

Thank you in advance!

Dear Hideo,

To help you, please upload just a small part of your file.

  • Choose a spot you have questions about (like the spot you described in green).
  • Isolate this. Most easy is to add geo, curve, num components and internalise data in there. That way you can copy paste it to a new Grasshopper file with all data, needed for that issue in it.
  • Do not use PlugIns. We don’t have all plugins installed (and probably do not want to too :slight_smile:

and at the file to the forum (just. like you did with the images).

Regards, Eef

Thank you for your advice.
As I cannot edit the original post, here I attaced .gh and relevant .3dm files here.
It contains only triming part without any external data.
testdata.3dm (148.8 KB)
RoadGeneration.gh (22.7 KB)

Without Cap Holes.

1 Like

Yep, that is it. You were 8 minutes ahead of me. Regards, Eef

1 Like

Thank you for your assitace. I confirmed that the following changes solve the issue. It worked!

  • Skipping CapEx from surface brep
  • Skipping simplify tree after extrusion
1 Like

Hi @HideoShiraishi ,
Have you ever used Gismo?

It can automatically create 3D:
Terrain, buildings, trees, roads, rivers… based on address and radius. Or latitude+longitude and radius.
I used the same location as you, and this what Gismo created:

JPN_Kanazawa_radius=500m.zip|attachment (12.5 MB)

1 Like

Thank you for the suggestion. I’ve installed it but not used it yet. I have a shp file of road edges which contain more accurate geometry than OSM (e.g., width), thus I am currently relying on the local shp files. But your sample model seems more consistent in its geometry (in my case, sometimes DEM fly over the road surface). I recognize that my current approach is a roundabout way. I will check the plugin!

1 Like