Our Geoportal did exactly what BTAA-GIN needed—until the job got bigger. Its Ruby on Rails and Apache Solr-centered architecture gave users a great way to search aggregated geospatial metadata, but projects such as the BTAA Geodata Collection and our Urban Base Layers effort pushed us far beyond discovery alone. We now curate municipal datasets from across the country, host and track web-optimized assets, enrich metadata, support durable access, manage curation workflows, and report on rapidly growing collections. We no longer needed just a better Geoportal; we needed a platform.

The big shift? We stopped asking the Geoportal to do everything. Instead, we built the BTAA Geospatial API as a shared foundation, turning metadata into infrastructure that can power many tools and experiences. The Geoportal remains an important front door, but now it is just one client among many. Rather than simply replacing one website with another, we opened the platform up—organizing it around reusable resources, shared services, and many new ways to discover, access, and work with geospatial data.

Under the hood, the platform is less of a monolith and more of an ensemble cast. FastAPI, PostgreSQL/PostGIS, Elasticsearch, React, SQLAlchemy, Celery, and Redis each get a job they are good at, while OpenGeoMetadata Aardvark keeps the metadata speaking a common language. Harvesting and normalization pipelines wrangle records from OpenGeoMetadata repositories, legacy BTAA systems, bridge services, fixtures, and other upstream sources. PostgreSQL preserves the canonical records; Elasticsearch reshapes them for speedy search and faceting. Because storage, indexing, background jobs, and presentation are no longer tangled together, we can tune, replace, or improve one part without sending the whole platform into existential crisis.

Keyword search is only the opening act. The API also serves up resources, facets, maps, citations, downloads, metadata, analytics, and administrative tools. An Open Geospatial Consortium API facade gives standards-minded clients a familiar way in, while the platform delivers everything from downloadable files and geospatial web services to Cloud Optimized GeoTIFFs, PMTiles, IIIF resources, thumbnails, and other hosted assets. Behind the scenes, multiple aggressive L1 and L2 caching layers keep generated maps, icons, previews, representations, and responses moving quickly.

We will demonstrate how this foundation changes spatial discovery in the new BTAA Geoportal. Rather than treating the map as a secondary preview, the interface and UX can begin with gazetteer-scoped results and spatial footprints. Users can discover resources from a place, not only from place names embedded in text. The H3 global grid system summaries reveal geographic distribution and collection density, making the map a very active part of search.

And then the API escapes the Geoportal. The same foundation can power our QGIS plugin (beta), command-line tools, dashboards, reports, maintenance automation, partner integrations, chat-based discovery, and Model Context Protocol tools for agent-facing search and retrieval. Whether users live in a browser, a desktop GIS, a terminal, or an AI client, the catalog can meet them there.

Attendees will leave with a field guide for spotting when a once-helpful catalog has become a very polite bottleneck. We will share how to separate source-of-truth metadata from discovery indexes, design APIs that speak human, GIS, script, and robot, and modernize a geospatial platform without launching the whole stack into the sun. The bigger lesson: a small academic library development team does not need an army—or a magical budget—to support discovery, access, stewardship, automation, and whatever comes next. Sometimes you just need one shared API.