Public agencies have spent years building web maps, dashboards, data portals, field apps, and one-off geospatial tools. Many were created for real operational needs. Over time, they often become difficult to understand, maintain, or trust. During emergencies, that condition becomes visible fast: everyone needs a common operating picture, but the map ecosystem is already cluttered, fragmented, stale, or unclear.

This talk uses emergency management as a concrete case study for a broader public-sector problem: map sprawl. The issue is not that agencies lack mapping tools. ArcGIS, Experience Builder, dashboards, open data portals, Leaflet apps, field collection systems, and national feeds already exist in abundance. The harder problem is knowing what to use, who owns it, whether it still works, which lifeline or operational function it supports, and how that information moves cleanly between the emergency manager who owns the decision and the GIS analyst who owns the plumbing.

The proposed answer is a Civic GeoShell: a lightweight open-source shell that helps agencies organize, inspect, and hand off map layers without creating another permanent dashboard to maintain. The prototype demonstrated in this talk, Lifeline Shell, is a single-file local-first web mapping tool built with vanilla JavaScript and Leaflet. It organizes layers using FEMA’s eight community lifelines, turning a familiar emergency management framework into a shared vocabulary between GIS and emergency operations.

The key design move is that the saved layer set becomes the handoff artifact. GIS can prepare, host, tag, and maintain the layer sources. Emergency managers can see which lifelines are covered, which are missing, and which layers are failing. Instead of treating the map as the deliverable, the shell treats the layer set as the operational object that travels between roles.

The live demo will show a starter operating-picture shell using national open data feeds such as weather alerts, fire perimeters, earthquakes, hospitals, and other public sources. The tool displays a readiness indicator showing which lifelines have coverage, allows users to add a layer by URL, saves the current set as a small JSON file, and shares that set through a URL hash without requiring a server, account, or database.

The most important feature is not the map. It is how the shell handles failure. A deliberately broken layer will be loaded during the demo. Instead of disappearing silently or failing only in a developer console, the broken layer remains visible as a routing slip under its assigned lifeline. The failure is classified by cause, such as restricted, moved, blocked, or offline, and stamped with an owner field. That pattern turns technical failure into operational work: someone can see it, name it, route it, and fix it.

The talk will connect this prototype to a larger open-source design pattern for civic map ecosystems. A Civic GeoShell should not try to replace every platform, portal, dashboard, or GIS server already in use. Instead, it should sit lightly above them: ingesting links, organizing layers, exposing gaps, preserving handoffs, and making failure visible. In a mature version, the same pattern could support ArcGIS REST services, FeatureServers, MapServers, open data portals, CSV files, GeoJSON, GeoPackage, WMS/WFS, OGC API sources, PMTiles, and local files.

The transferable lesson is restraint. Civic tools often begin as small fixes and slowly become the bloated systems they were meant to escape. This prototype explicitly refuses features such as user accounts, hosted catalogs, editing tools, print composition, analytics dashboards, and permanent databases. Those refusals are not omissions. They are part of the architecture. The shell is meant to help people understand and hand off an operating picture, not become another operating picture that someone has to maintain forever.

Attendees will leave with three reusable ideas: first, map sprawl is a maintenance and trust problem, not just a visualization problem; second, the handoff artifact between technical and decision-holding roles should be designed as deliberately as the map itself; and third, open-source geospatial tools are especially valuable when they help agencies inspect, simplify, and reuse what they already have.

This is a working prototype with a broader thesis: the next innovation in civic GIS may not be another map. It may be a small, inspectable shell that helps agencies understand which maps, feeds, and layers should still exist.