What I inherited
Proven configuration patterns from existing viewers and Martin Palacios’s technical framework for understanding how the JSON, application, and Sanity implementation connected.
CASE STUDY 05 · CUSTOM WEB GIS
Turning 133 layers into one navigable system.
Project details and geography have been anonymized for client privacy.
THE PROBLEM
The complexity was real.
The interface still had to feel usable.
The viewer brought together 133 planning, transportation, design, community, and environmental layers. The goal was not to hide that complexity. It was to give it a hierarchy: sensible groups, predictable toggles, useful legends, and two coherent map styles.
HOW I WORKED
Reuse was the starting point.
Judgment was the work.
What I changed
I copied, adapted, and extended those patterns for this project; configured 133 layers; maintained separate aerial and street-map files; and added the project-specific hierarchy and behavior.
What I learned
Troubleshooting made the architecture legible: how a layer definition moves through source, metadata, layout, paint, visibility, identify behavior, and the public legend.
THE IMPLEMENTATION
From a proven pattern
to a project-specific viewer.
- 01Start with an established configuration
Reuse working structure instead of retyping solved boilerplate.
- 02Adapt and extend the JSON
Connect sources, layers, metadata, controls, and project-specific behavior.
- 03Maintain two map styles
Keep separate Aerial and Streets configurations aligned.
- 04Configure the project in Sanity
Attach both map styles and enable the viewer’s application controls.
Configuration and rendered map, side by side.
THE TECHNICAL EVIDENCE
Like most things, I learned how the system worked by making it work.
Layer sources
Connected each layer to the right source and source-layer while keeping identifiers consistent across configurations.
Visibility
Used layout and visibility rules so groups could open, close, and appear in a deliberate default state.
Symbology
Adapted paint properties and feature-state behavior so complex engineering geometry stayed readable and interactive.
Public controls
Mapped metadata to the legend, identify behavior, nested groups, and the Aerial / Streets experience.
The hardest part: nested groups, toggles, and legend behavior.
THE HARD PART
A long layer list is not a hierarchy.
The difficult work was making parent groups, child layers, visibility defaults, legends, and nested controls agree. The structure needed to let a visitor move from broad categories into detailed design segments without losing where they were—or turning on an incoherent combination of layers.
“The goal was not fewer layers. It was a clearer way through them.”
THE CONTENT LAYER
The completed configurations became a manageable project.
In the project-specific Sanity entry, the Aerial and Streets map styles live alongside application settings such as location search, user location, media, areas of interest, and engineering-report controls. That separation kept map configuration and project management connected without treating them as the same thing.
Project configuration in Sanity.
MENTORED WORK · HONEST CREDIT
Martin taught me the architecture.
I applied it, adapted it, troubleshot it, and extended it.
This was mentored work—not a solo invention. Martin Palacios gave me the technical framework and patient guidance that allowed me to begin understanding configuration-driven Web GIS. I used that framework to implement this 133-layer viewer, maintain its two map styles, and become more independent as I solved new nesting, visibility, legend, and project requirements.
THE OUTCOME
One public viewer.
Two map styles.
One hundred thirty-three layers with a way through.
The evidence is not that I typed every line from scratch. It is that I could enter an established system, understand enough of its structure to adapt it responsibly, diagnose what did not work, and extend it for a substantially more complex project.