DEV Community

Cover image for Modeling a Seawall From a Map Selection: Geometry, Elevation, and the Water You Can't See
Generate Build
Generate Build

Posted on

Modeling a Seawall From a Map Selection: Geometry, Elevation, and the Water You Can't See

I wanted a 3D model of the Galveston seawall for a small experiment: not a survey-grade deliverable, just something I could rotate and measure while reading about the structure. I picked a one-mile segment near the east end and used GenAnywhere to select the wall, the beach in front of it, and two blocks of streets behind it. A minute later I had a rough model. It was useful, and it was wrong in ways that taught me more than the useful part.

Start With an Extent, Not a Model

The first decision is what to include. A seawall is not a free-standing object; it is the edge of a system that includes the beach, the road on top, the drainage outfalls, and the ground behind it. If the extent stops at the wall, the model cannot show overtopping or ponding. If it runs too far inland, the mesh gets heavy and the wall becomes a thin line.
My box covered about a mile of shoreline and roughly 600 feet inland. That was enough to see the beach width change and to place the road correctly. The generated mesh came back with a terrain surface, a vertical wall, and simple blocks for the buildings. Good for orientation. Not good for anything that depends on the wall's actual profile.

The Coordinate Problem

A model without a coordinate system is a picture. I work in Texas South Central, EPSG:2278, which uses US survey feet, and I treat elevations as NAVD88. Mixing those with web-mercator meters is the fastest way to produce a model that looks fine and measures wrong.
I also keep a local origin near the segment and store offsets, because consumer mesh formats lose precision when coordinates are in the millions of feet. The metadata block I attach to each segment looks like this:
That block is the part a viewer will never see, and it is the part that makes the model usable.

What the Mesh Gets Wrong

The generated wall is a flat extruded ribbon. The real wall has a curved face, a thicker base, construction joints, and a toe that meets rock and sand at an angle. The mesh has none of that. It also has no sheet piles, no weep holes, and no bathymetry. The water in front of the wall is a plane at zero, which is only correct on a calm day.
For my purposes, the flat wall was acceptable as a stand-in, but I had to stop treating it as geometry and start treating it as a symbol. The measurements I trusted were the ones I sampled separately: crest elevation at twenty points, beach width at the same chainages, and the offset between the road centerline and the wall face.

Uploading image

Attributes Matter More Than Triangles

A wall segment is not just a shape. The attributes I care about are the ones that explain why one mile behaves differently from the next:
• Chainage range and length
• Crest elevation and toe elevation
• Wall type and construction era
• Beach width in front of the wall
• Number and location of outfalls
• Inspection rating and last repair date
• Adjacent groin or revetment
Joining those to the mesh by chainage turned the model from a visual into something I could query. "Show me segments where the beach is narrower than 50 feet and the crest is below 17 feet" is a useful question. A pretty render is not.

Putting Water Back In

The most valuable thing I did was add water as a scenario, not a surface. I set still-water levels at 5, 10, and 15 feet above NAVD88 and rendered each against the same wall profile. At 5 feet, the beach disappears. At 10, water reaches the road in the low sections. At 15, the wall is a speed bump.
That is not a prediction. It is a way to see the relationship between three numbers that are usually discussed separately: wall height, surge height, and ground elevation behind the wall. The model made the third number impossible to ignore.

Uploading image

What I Would Do Differently

I would start from LiDAR and surveyed cross-sections instead of a generated mesh, and I would keep the terrain model and the asset model in separate layers. I would also version the assumptions, because a wall model is mostly assumptions: where the toe is, what the beach does in a storm, and how much water arrives from the bay side.
The quick model was still worth the hour. It gave me a frame for the numbers, and it showed me where the frame breaks. A seawall is a simple shape with a complicated job, and any model of it should say which one it is representing.

Top comments (0)